Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第10章 クラウドプロバイダーの認証情報の設定変更

サポートされる構成では、OpenShift Container Platform がクラウドプロバイダーに対して認証する方法を変更できます。

クラスターが使用するクラウド認証情報ストラテジーを決定するには、Cloud Credential Operator モードの決定 を参照してください。

組織によっては、クラスターを認証するサービスキーをローテーションする必要があります。Cloud Credential Operator (CCO) ユーティリティー (ccoctl) を使用すると、次のクラウドプロバイダーにインストールされているクラスターのキーを更新できます。

10.1.1. AWS OIDC のバインドされたサービスアカウント署名者鍵のローテーション
リンクのコピー

Amazon Web Services (AWS) 上の OpenShift Container Platform クラスターの Cloud Credential Operator (CCO) が STS を使用して手動モードで動作するように設定されている場合は、バインドされたサービスアカウント署名者鍵をローテーションできます。

キーをローテーションするには、クラスター上の既存のキーを削除します。これにより、Kubernetes API サーバーによって新しいキーが作成されます。このプロセス中の認証失敗を減らすために、新しい公開鍵を既存の発行者ファイルにすぐに追加する必要があります。クラスターが認証に新しいキーを使用した後は、残っているキーを削除できます。

重要

OIDC のバインドされたサービスアカウント署名者キーをローテーションするプロセスは、システムの中断を引き起こし、かなりの時間がかかります。いくつかのステップには時間的な制約があります。続行する前に、次の考慮事項を確認してください。

  • 次の手順を読み、必ず時間の要件を理解してご承知おきください。正確な所要時間は個々のクラスターによって異なりますが、少なくとも 1 時間かかる可能性があります。
  • 認証失敗のリスクを軽減するために、時間的な制約があるステップを理解し、準備しておく必要があります。
  • このプロセス中に、すべてのサービスアカウントを更新し、クラスター上のすべての Pod を再起動する必要があります。これらのアクションはワークロードの停止を伴います。この影響を軽減するには、これらのサービスを一時的に停止し、クラスターの準備ができたときに再デプロイすることができます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift CLI (oc) にアクセスできる。

  • ccoctl ユーティリティーで使用できるように、次の権限を持つ AWS アカウントを作成した。

    • s3:GetObject
    • s3:PutObject
    • s3:PutObjectTagging
    • パブリック CloudFront ディストリビューション URL を介して IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに OIDC 設定を保存するクラスターの場合、ccoctl ユーティリティーを実行する AWS アカウントに cloudfront:ListDistributions 権限が必要です。
  • ccoctl ユーティリティーを設定した。

  • クラスターが安定した状態にある。次のコマンドを実行すると、クラスターが安定していることを確認できます。 

    $ oc adm wait-for-stable-cluster --minimum-stable-period=5s
    Copy to Clipboard Toggle word wrap

手順

  1. 次の環境変数を設定します。 

    INFRA_ID=$(oc get infrastructures cluster -o jsonpath='{.status.infrastructureName}')
CLUSTER_NAME=${INFRA_ID%-*}
    1
    Copy to Clipboard Toggle word wrap
    1 1
    この値は、インストール時に install-config.yaml ファイルの metadata.name フィールドで指定したクラスターの名前と一致する必要があります。
    注記

    実際のクラスターはこの例と異なる場合があります。また、リソース名が同じようにクラスター名に基づくものではない可能性があります。実際のクラスターに対応する正しいリソース名を必ず指定してください。

    • OIDC 設定をパブリック S3 バケットに保存する AWS クラスターの場合は、次の環境変数を設定します。 

      AWS_BUCKET=$(oc get authentication cluster -o jsonpath={'.spec.serviceAccountIssuer'} | awk -F'://' '{print$2}' |awk -F'.' '{print$1}')
      Copy to Clipboard Toggle word wrap

    • パブリック CloudFront ディストリビューション URL を介して IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに OIDC 設定を保存する AWS クラスターの場合は、次の手順を実行します。

      1. 次のコマンドを実行して、パブリック CloudFront ディストリビューション URL を抽出します。 

        $ basename $(oc get authentication cluster -o jsonpath={'.spec.serviceAccountIssuer'} )
        Copy to Clipboard Toggle word wrap

        出力例

        <subdomain>.cloudfront.net
        Copy to Clipboard Toggle word wrap

        <subdomain> は英数字の文字列です。

      2. 次のコマンドを実行して、プライベート S3 バケット名を確認します。 

        $ aws cloudfront list-distributions --query "DistributionList.Items[].{DomainName: DomainName, OriginDomainName: Origins.Items[0].DomainName}[?contains(DomainName, '<subdomain>.cloudfront.net')]"
        Copy to Clipboard Toggle word wrap

        出力例

        [
    {
        "DomainName": "<subdomain>.cloudfront.net",
        "OriginDomainName": "<s3_bucket>.s3.us-east-2.amazonaws.com"
    }
]
        Copy to Clipboard Toggle word wrap

        <s3_bucket> はクラスターのプライベート S3 バケット名です。

      3. 次の環境変数を設定します。 

        AWS_BUCKET=$<s3_bucket>
        Copy to Clipboard Toggle word wrap

        <s3_bucket> はクラスターのプライベート S3 バケット名です。

  2. 次のコマンドを実行して、使用する一時ディレクトリーを作成し、環境変数を割り当てます。 

    $ TEMPDIR=$(mktemp -d)
    Copy to Clipboard Toggle word wrap

  3. Kubernetes API サーバーが新しいバインドされたサービスアカウント署名鍵を作成するように、次のバインドされたサービスアカウント署名鍵を削除します。

    重要

    このステップを完了すると、Kubernetes API サーバーが新しい鍵のロールアウトを開始します。認証失敗のリスクを減らすために、残りのステップをできるだけ早く完了してください。残りのステップにより、ワークロードの中断が発生する可能性があります。

    準備ができたら、以下のコマンドを実行して、次のバインドされたサービスアカウント署名鍵を削除します。 

    $ oc delete secrets/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、Kubernetes API サーバーが作成したサービスアカウント署名鍵シークレットから公開鍵をダウンロードします。 

    $ oc get secret/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator \
  -ojsonpath='{ .data.service-account\.pub }' | base64 \
  -d > ${TEMPDIR}/serviceaccount-signer.public
    Copy to Clipboard Toggle word wrap

  5. 公開鍵を使用して次のコマンドを実行し、keys.json ファイルを作成します。 

    $ ccoctl aws create-identity-provider \
  --dry-run \
    1 
    
  --output-dir ${TEMPDIR} \
  --name fake \
    2 
    
  --region us-east-1
    3
    Copy to Clipboard Toggle word wrap
    1
    --dry-run オプションは、API 呼び出しを行わずに、新しい keys.json ファイルを含むファイルをディスクに出力します。
    2
    --dry-run オプションは API 呼び出しを行わないため、一部のパラメーターには実際の値は必要ありません。
    3
    us-east-1 などの有効な AWS リージョンを指定します。この値は、クラスターが存在するリージョンと一致する必要はありません。

  6. 次のコマンドを実行して、keys.json ファイルの名前を変更します。 

    $ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json
    Copy to Clipboard Toggle word wrap

    <number> は環境に応じて異なる 2 桁の数値です。

  7. 次のコマンドを実行して、クラウドプロバイダーから既存の keys.json ファイルをダウンロードします。 

    $ aws s3api get-object \
  --bucket ${AWS_BUCKET} \
  --key keys.json ${TEMPDIR}/jwks.current.json
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行して、2 つの keys.json ファイルを結合します。 

    $ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json
    Copy to Clipboard Toggle word wrap

  9. ローテーション中に古い鍵と新しい鍵の認証を有効にするために、次のコマンドを実行して、結合された keys.json ファイルをクラウドプロバイダーにアップロードします。 

    $ aws s3api put-object \
  --bucket ${AWS_BUCKET} \
  --tagging "openshift.io/cloud-credential-operator/${CLUSTER_NAME}=owned" \
  --key keys.json \
  --body ${TEMPDIR}/jwks.combined.json
    Copy to Clipboard Toggle word wrap

  10. Kubernetes API サーバーが更新され、新しい鍵が使用されるまで待ちます。次のコマンドを実行すると、更新の進行状況を監視できます。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap

    このプロセスには 15 分以上かかる場合があります。次の出力は、プロセスが完了したことを示します。 

    All clusteroperators are stable
    Copy to Clipboard Toggle word wrap

  11. クラスター上のすべての Pod が新しい鍵を使用するように、Pod を再起動する必要があります。

    重要

    このステップにより、複数のノードにわたる高可用性が設定されているサービスのアップタイムが維持されます。しかし、高可用性が設定されていないサービスのダウンタイムが発生する可能性があります。

    次のコマンドを実行して、クラスター内のすべての Pod を再起動します。 

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master
    Copy to Clipboard Toggle word wrap

  12. 次のコマンドを実行して、再起動と更新のプロセスを監視します。 

    $ oc adm wait-for-node-reboot nodes --all
    Copy to Clipboard Toggle word wrap

    このプロセスには 15 分以上かかる場合があります。次の出力は、プロセスが完了したことを示します。 

    All nodes rebooted
    Copy to Clipboard Toggle word wrap

  13. 次のコマンドを実行して更新の進行状況を監視します。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap

    このプロセスには 15 分以上かかる場合があります。次の出力は、プロセスが完了したことを示します。 

    All clusteroperators are stable
    Copy to Clipboard Toggle word wrap

  14. 次のコマンドを実行して、結合された keys.json ファイルを、クラウドプロバイダー上の更新された keys.json ファイルに置き換えます。 

    $ aws s3api put-object \
  --bucket ${AWS_BUCKET} \
  --tagging "openshift.io/cloud-credential-operator/${CLUSTER_NAME}=owned" \
  --key keys.json \
  --body ${TEMPDIR}/jwks.new.json
    Copy to Clipboard Toggle word wrap

10.1.2. GCP OIDC のバインドされたサービスアカウント署名者鍵のローテーション
リンクのコピー

Google Cloud Platform (GCP) 上の OpenShift Container Platform クラスターの Cloud Credential Operator (CCO) が GCP Workload Identity を使用して手動モードで動作するように設定されている場合は、バインドされたサービスアカウント署名者鍵をローテーションできます。

キーをローテーションするには、クラスター上の既存のキーを削除します。これにより、Kubernetes API サーバーによって新しいキーが作成されます。このプロセス中の認証失敗を減らすために、新しい公開鍵を既存の発行者ファイルにすぐに追加する必要があります。クラスターが認証に新しいキーを使用した後は、残っているキーを削除できます。

重要

OIDC のバインドされたサービスアカウント署名者キーをローテーションするプロセスは、システムの中断を引き起こし、かなりの時間がかかります。いくつかのステップには時間的な制約があります。続行する前に、次の考慮事項を確認してください。

  • 次の手順を読み、必ず時間の要件を理解してご承知おきください。正確な所要時間は個々のクラスターによって異なりますが、少なくとも 1 時間かかる可能性があります。
  • 認証失敗のリスクを軽減するために、時間的な制約があるステップを理解し、準備しておく必要があります。
  • このプロセス中に、すべてのサービスアカウントを更新し、クラスター上のすべての Pod を再起動する必要があります。これらのアクションはワークロードの停止を伴います。この影響を軽減するには、これらのサービスを一時的に停止し、クラスターの準備ができたときに再デプロイすることができます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift CLI (oc) にアクセスできる。

  • ccoctl ユーティリティーが使用する GCP アカウントに、次のいずれかの認証方法を追加した。

    • IAM Workload Identity Pool Admin ロール

    • 次の詳細な権限:

      • storage.objects.create
      • storage.objects.delete
  • ccoctl ユーティリティーを設定した。

  • クラスターが安定した状態にある。次のコマンドを実行すると、クラスターが安定していることを確認できます。 

    $ oc adm wait-for-stable-cluster --minimum-stable-period=5s
    Copy to Clipboard Toggle word wrap

手順

  1. 次の環境変数を設定します。 

    CURRENT_ISSUER=$(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}')
GCP_BUCKET=$(echo ${CURRENT_ISSUER} | cut -d "/" -f4)
    Copy to Clipboard Toggle word wrap
    注記

    実際のクラスターはこの例と異なる場合があります。また、リソース名が同じようにクラスター名に基づくものではない可能性があります。実際のクラスターに対応する正しいリソース名を必ず指定してください。

  2. 次のコマンドを実行して、使用する一時ディレクトリーを作成し、環境変数を割り当てます。 

    $ TEMPDIR=$(mktemp -d)
    Copy to Clipboard Toggle word wrap

  3. Kubernetes API サーバーが新しいバインドされたサービスアカウント署名鍵を作成するように、次のバインドされたサービスアカウント署名鍵を削除します。

    重要

    このステップを完了すると、Kubernetes API サーバーが新しい鍵のロールアウトを開始します。認証失敗のリスクを減らすために、残りのステップをできるだけ早く完了してください。残りのステップにより、ワークロードの中断が発生する可能性があります。

    準備ができたら、以下のコマンドを実行して、次のバインドされたサービスアカウント署名鍵を削除します。 

    $ oc delete secrets/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、Kubernetes API サーバーが作成したサービスアカウント署名鍵シークレットから公開鍵をダウンロードします。 

    $ oc get secret/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator \
  -ojsonpath='{ .data.service-account\.pub }' | base64 \
  -d > ${TEMPDIR}/serviceaccount-signer.public
    Copy to Clipboard Toggle word wrap

  5. 公開鍵を使用して次のコマンドを実行し、keys.json ファイルを作成します。 

    $ ccoctl gcp create-workload-identity-provider \
  --dry-run \
    1 
    
  --output-dir=${TEMPDIR} \
  --name fake \
    2 
    
  --project fake \
  --workload-identity-pool fake
    Copy to Clipboard Toggle word wrap
    1
    --dry-run オプションは、API 呼び出しを行わずに、新しい keys.json ファイルを含むファイルをディスクに出力します。
    2
    --dry-run オプションは API 呼び出しを行わないため、一部のパラメーターには実際の値は必要ありません。

  6. 次のコマンドを実行して、keys.json ファイルの名前を変更します。 

    $ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json
    Copy to Clipboard Toggle word wrap

    <number> は環境に応じて異なる 2 桁の数値です。

  7. 次のコマンドを実行して、クラウドプロバイダーから既存の keys.json ファイルをダウンロードします。 

    $ gcloud storage cp gs://${GCP_BUCKET}/keys.json ${TEMPDIR}/jwks.current.json
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行して、2 つの keys.json ファイルを結合します。 

    $ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json
    Copy to Clipboard Toggle word wrap

  9. ローテーション中に古い鍵と新しい鍵の認証を有効にするために、次のコマンドを実行して、結合された keys.json ファイルをクラウドプロバイダーにアップロードします。 

    $ gcloud storage cp ${TEMPDIR}/jwks.combined.json gs://${GCP_BUCKET}/keys.json
    Copy to Clipboard Toggle word wrap

  10. Kubernetes API サーバーが更新され、新しい鍵が使用されるまで待ちます。次のコマンドを実行すると、更新の進行状況を監視できます。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap

    このプロセスには 15 分以上かかる場合があります。次の出力は、プロセスが完了したことを示します。 

    All clusteroperators are stable
    Copy to Clipboard Toggle word wrap

  11. クラスター上のすべての Pod が新しい鍵を使用するように、Pod を再起動する必要があります。

    重要

    このステップにより、複数のノードにわたる高可用性が設定されているサービスのアップタイムが維持されます。しかし、高可用性が設定されていないサービスのダウンタイムが発生する可能性があります。

    次のコマンドを実行して、クラスター内のすべての Pod を再起動します。 

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master
    Copy to Clipboard Toggle word wrap

  12. 次のコマンドを実行して、再起動と更新のプロセスを監視します。 

    $ oc adm wait-for-node-reboot nodes --all
    Copy to Clipboard Toggle word wrap

    このプロセスには 15 分以上かかる場合があります。次の出力は、プロセスが完了したことを示します。 

    All nodes rebooted
    Copy to Clipboard Toggle word wrap

  13. 次のコマンドを実行して更新の進行状況を監視します。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap

    このプロセスには 15 分以上かかる場合があります。次の出力は、プロセスが完了したことを示します。 

    All clusteroperators are stable
    Copy to Clipboard Toggle word wrap

  14. 次のコマンドを実行して、結合された keys.json ファイルを、クラウドプロバイダー上の更新された keys.json ファイルに置き換えます。 

    $ gcloud storage cp ${TEMPDIR}/jwks.new.json gs://${GCP_BUCKET}/keys.json
    Copy to Clipboard Toggle word wrap

10.1.3. Azure OIDC のバインドされたサービスアカウント署名者鍵のローテーション
リンクのコピー

Microsoft Azure 上の OpenShift Container Platform クラスターの Cloud Credential Operator (CCO) が Microsoft Entra Workload ID を使用して手動モードで動作するように設定されている場合は、バインドされたサービスアカウント署名者鍵をローテーションできます。

キーをローテーションするには、クラスター上の既存のキーを削除します。これにより、Kubernetes API サーバーによって新しいキーが作成されます。このプロセス中の認証失敗を減らすために、新しい公開鍵を既存の発行者ファイルにすぐに追加する必要があります。クラスターが認証に新しいキーを使用した後は、残っているキーを削除できます。

重要

OIDC のバインドされたサービスアカウント署名者キーをローテーションするプロセスは、システムの中断を引き起こし、かなりの時間がかかります。いくつかのステップには時間的な制約があります。続行する前に、次の考慮事項を確認してください。

  • 次の手順を読み、必ず時間の要件を理解してご承知おきください。正確な所要時間は個々のクラスターによって異なりますが、少なくとも 1 時間かかる可能性があります。
  • 認証失敗のリスクを軽減するために、時間的な制約があるステップを理解し、準備しておく必要があります。
  • このプロセス中に、すべてのサービスアカウントを更新し、クラスター上のすべての Pod を再起動する必要があります。これらのアクションはワークロードの停止を伴います。この影響を軽減するには、これらのサービスを一時的に停止し、クラスターの準備ができたときに再デプロイすることができます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift CLI (oc) にアクセスできる。

  • ccoctl ユーティリティーで使用できるように、次の権限を持つグローバル Azure アカウントを作成した。

    • Microsoft.Storage/storageAccounts/listkeys/action
    • Microsoft.Storage/storageAccounts/read
    • Microsoft.Storage/storageAccounts/write
    • Microsoft.Storage/storageAccounts/blobServices/containers/read
    • Microsoft.Storage/storageAccounts/blobServices/containers/write
  • ccoctl ユーティリティーを設定した。

  • クラスターが安定した状態にある。次のコマンドを実行すると、クラスターが安定していることを確認できます。 

    $ oc adm wait-for-stable-cluster --minimum-stable-period=5s
    Copy to Clipboard Toggle word wrap

手順

  1. 次の環境変数を設定します。 

    CURRENT_ISSUER=$(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}')
AZURE_STORAGE_ACCOUNT=$(echo ${CURRENT_ISSUER} | cut -d "/" -f3 | cut -d "." -f1)
AZURE_STORAGE_CONTAINER=$(echo ${CURRENT_ISSUER} | cut -d "/" -f4)
    Copy to Clipboard Toggle word wrap
    注記

    実際のクラスターはこの例と異なる場合があります。また、リソース名が同じようにクラスター名に基づくものではない可能性があります。実際のクラスターに対応する正しいリソース名を必ず指定してください。

  2. 次のコマンドを実行して、使用する一時ディレクトリーを作成し、環境変数を割り当てます。 

    $ TEMPDIR=$(mktemp -d)
    Copy to Clipboard Toggle word wrap

  3. Kubernetes API サーバーが新しいバインドされたサービスアカウント署名鍵を作成するように、次のバインドされたサービスアカウント署名鍵を削除します。

    重要

    このステップを完了すると、Kubernetes API サーバーが新しい鍵のロールアウトを開始します。認証失敗のリスクを減らすために、残りのステップをできるだけ早く完了してください。残りのステップにより、ワークロードの中断が発生する可能性があります。

    準備ができたら、以下のコマンドを実行して、次のバインドされたサービスアカウント署名鍵を削除します。 

    $ oc delete secrets/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、Kubernetes API サーバーが作成したサービスアカウント署名鍵シークレットから公開鍵をダウンロードします。 

    $ oc get secret/next-bound-service-account-signing-key \
  -n openshift-kube-apiserver-operator \
  -ojsonpath='{ .data.service-account\.pub }' | base64 \
  -d > ${TEMPDIR}/serviceaccount-signer.public
    Copy to Clipboard Toggle word wrap

  5. 公開鍵を使用して次のコマンドを実行し、keys.json ファイルを作成します。 

    $ ccoctl aws create-identity-provider \
    1 
    
  --dry-run \
    2 
    
  --output-dir ${TEMPDIR} \
  --name fake \
    3 
    
  --region us-east-1
    4
    Copy to Clipboard Toggle word wrap
    1
    ccoctl azure コマンドには --dry-run オプションが含まれていません。--dry-run オプションを使用するには、Azure クラスターの場合も aws を指定する必要があります。
    2
    --dry-run オプションは、API 呼び出しを行わずに、新しい keys.json ファイルを含むファイルをディスクに出力します。
    3
    --dry-run オプションは API 呼び出しを行わないため、一部のパラメーターには実際の値は必要ありません。
    4
    us-east-1 などの有効な AWS リージョンを指定します。この値は、クラスターが存在するリージョンと一致する必要はありません。

  6. 次のコマンドを実行して、keys.json ファイルの名前を変更します。 

    $ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json
    Copy to Clipboard Toggle word wrap

    <number> は環境に応じて異なる 2 桁の数値です。

  7. 次のコマンドを実行して、クラウドプロバイダーから既存の keys.json ファイルをダウンロードします。 

    $ az storage blob download \
  --container-name ${AZURE_STORAGE_CONTAINER} \
  --account-name ${AZURE_STORAGE_ACCOUNT} \
  --name 'openid/v1/jwks' \
  -f ${TEMPDIR}/jwks.current.json
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行して、2 つの keys.json ファイルを結合します。 

    $ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json
    Copy to Clipboard Toggle word wrap

  9. ローテーション中に古い鍵と新しい鍵の認証を有効にするために、次のコマンドを実行して、結合された keys.json ファイルをクラウドプロバイダーにアップロードします。 

    $ az storage blob upload \
  --overwrite \
  --account-name ${AZURE_STORAGE_ACCOUNT} \
  --container-name ${AZURE_STORAGE_CONTAINER} \
  --name 'openid/v1/jwks' \
  -f ${TEMPDIR}/jwks.combined.json
    Copy to Clipboard Toggle word wrap

  10. Kubernetes API サーバーが更新され、新しい鍵が使用されるまで待ちます。次のコマンドを実行すると、更新の進行状況を監視できます。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap

    このプロセスには 15 分以上かかる場合があります。次の出力は、プロセスが完了したことを示します。 

    All clusteroperators are stable
    Copy to Clipboard Toggle word wrap

  11. クラスター上のすべての Pod が新しい鍵を使用するように、Pod を再起動する必要があります。

    重要

    このステップにより、複数のノードにわたる高可用性が設定されているサービスのアップタイムが維持されます。しかし、高可用性が設定されていないサービスのダウンタイムが発生する可能性があります。

    次のコマンドを実行して、クラスター内のすべての Pod を再起動します。 

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master
    Copy to Clipboard Toggle word wrap

  12. 次のコマンドを実行して、再起動と更新のプロセスを監視します。 

    $ oc adm wait-for-node-reboot nodes --all
    Copy to Clipboard Toggle word wrap

    このプロセスには 15 分以上かかる場合があります。次の出力は、プロセスが完了したことを示します。 

    All nodes rebooted
    Copy to Clipboard Toggle word wrap

  13. 次のコマンドを実行して更新の進行状況を監視します。 

    $ oc adm wait-for-stable-cluster
    Copy to Clipboard Toggle word wrap

    このプロセスには 15 分以上かかる場合があります。次の出力は、プロセスが完了したことを示します。 

    All clusteroperators are stable
    Copy to Clipboard Toggle word wrap

  14. 次のコマンドを実行して、結合された keys.json ファイルを、クラウドプロバイダー上の更新された keys.json ファイルに置き換えます。 

    $ az storage blob upload \
  --overwrite \
  --account-name ${AZURE_STORAGE_ACCOUNT} \
  --container-name ${AZURE_STORAGE_CONTAINER} \
  --name 'openid/v1/jwks' \
  -f ${TEMPDIR}/jwks.new.json
    Copy to Clipboard Toggle word wrap

10.1.4. IBM Cloud 認証情報のローテーション
リンクのコピー

既存のサービス ID の API キーをローテーションし、対応するシークレットを更新できます。

前提条件

  • ccoctl ユーティリティーを設定した。
  • インストールされているライブ OpenShift Container Platform クラスターに既存のサービス ID がある。

手順

  • ccoctl ユーティリティーを使用してサービス ID の API キーをローテーションし、次のコマンドを実行してシークレットを更新します。 

    $ ccoctl <provider_name> refresh-keys \
    1 
    
    --kubeconfig <openshift_kubeconfig_file> \
    2 
    
    --credentials-requests-dir <path_to_credential_requests_directory> \
    3 
    
    --name <name>
    4
    Copy to Clipboard Toggle word wrap
    1
    プロバイダーの名前。例: ibmcloud または powervs。
    2
    クラスターに関連付けられている kubeconfig ファイル。たとえば、<installation_directory>/auth/kubeconfig です。
    3
    認証情報の要求が保存されるディレクトリー。
    4
    OpenShift Container Platform クラスターの名前。
    注記

    クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat