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

手順

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

   INFRA_ID=$(oc get infrastructures cluster -o jsonpath='{.status.infrastructureName}')
   CLUSTER_NAME=${INFRA_ID%-*}

   各項目の説明:

   CLUSTER_NAME

   この値は、インストール時に 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}')

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

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

        $ basename $(oc get authentication cluster -o jsonpath={'.spec.serviceAccountIssuer'} )

        出力例

        <subdomain>.cloudfront.net

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

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

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

        出力例

        [
            {
                "DomainName": "<subdomain>.cloudfront.net",
                "OriginDomainName": "<s3_bucket>.s3.us-east-2.amazonaws.com"
            }
        ]

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

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

        AWS_BUCKET=$<s3_bucket>

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

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

   $ TEMPDIR=$(mktemp -d)

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

   重要

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

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

   $ oc delete secrets/next-bound-service-account-signing-key \
     -n openshift-kube-apiserver-operator

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

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

   $ ccoctl aws create-identity-provider \
     --dry-run \
     --output-dir ${TEMPDIR} \
     --public-key-file=${TEMPDIR}/serviceaccount-signer.public \
     --name fake \
     --region us-east-1

   各項目の説明:

   --dry-run

   ドライランモードは、API 呼び出しを行わずに、新しい keys.json ファイルを含むファイルをディスクに出力します。

   --public-key-file

   前のステップでダウンロードした公開鍵へのパス。

   --name

   一部のパラメーターには実際の値は必要ありません。これは、その -dry-run オプションで API 呼び出しが行われないためです。

   --region

   有効な AWS リージョン（例： us-east-1 ）。この値は、クラスターが存在するリージョンと一致する必要はありません。

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

   $ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json

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

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

   $ aws s3api get-object \
     --bucket ${AWS_BUCKET} \
     --key keys.json ${TEMPDIR}/jwks.current.json

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

   $ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json

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

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

    $ oc adm wait-for-stable-cluster

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

    All clusteroperators are stable

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

    重要

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

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

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master

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

    $ oc adm wait-for-node-reboot nodes --all

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

    All nodes rebooted

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

    $ oc adm wait-for-stable-cluster

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

    All clusteroperators are stable

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

手順

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

   CURRENT_ISSUER=$(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}')
   GCP_BUCKET=$(echo ${CURRENT_ISSUER} | cut -d "/" -f4)

   注記

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

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

   $ TEMPDIR=$(mktemp -d)

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

   重要

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

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

   $ oc delete secrets/next-bound-service-account-signing-key \
     -n openshift-kube-apiserver-operator

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

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

   $ ccoctl gcp create-workload-identity-provider \
     --dry-run \
     --output-dir=${TEMPDIR} \
     --public-key-file=${TEMPDIR}/serviceaccount-signer.public \
     --name fake \
     --project fake \
     --workload-identity-pool fake

   各項目の説明:

   --dry-run

   ドライランモードは、API 呼び出しを行わずに、新しい keys.json ファイルを含むファイルをディスクに出力します。

   --public-key-file

   前のステップでダウンロードした公開鍵へのパス。

   --name

   一部のパラメーターには実際の値は必要ありません。これは、その -dry-run オプションで API 呼び出しが行われないためです。

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

   $ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json

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

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

   $ gcloud storage cp gs://${GCP_BUCKET}/keys.json ${TEMPDIR}/jwks.current.json

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

   $ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json

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

   $ gcloud storage cp ${TEMPDIR}/jwks.combined.json gs://${GCP_BUCKET}/keys.json

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

    $ oc adm wait-for-stable-cluster

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

    All clusteroperators are stable

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

    重要

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

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

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master

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

    $ oc adm wait-for-node-reboot nodes --all

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

    All nodes rebooted

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

    $ oc adm wait-for-stable-cluster

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

    All clusteroperators are stable

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

    $ gcloud storage cp ${TEMPDIR}/jwks.new.json gs://${GCP_BUCKET}/keys.json

手順

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)

   注記

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

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

   $ TEMPDIR=$(mktemp -d)

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

   重要

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

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

   $ oc delete secrets/next-bound-service-account-signing-key \
     -n openshift-kube-apiserver-operator

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

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

   $ ccoctl aws create-identity-provider \
     --dry-run \
     --output-dir ${TEMPDIR} \
     --public-key-file=${TEMPDIR}/serviceaccount-signer.public \
     --name fake \
     --region us-east-1

   各項目の説明:

   ccoctl aws

   このコマンドには a -dry-run オプションは含まれません。--dry-run オプションを使用するには、Azure クラスターの場合も aws を指定する必要があります。

   --dry-run

   ドライランモードは、API 呼び出しを行わずに、新しい keys.json ファイルを含むファイルをディスクに出力します。

   --public-key-file

   前のステップでダウンロードした公開鍵へのパス。

   --name

   一部のパラメーターには実際の値は必要ありません。これは、その -dry-run オプションで API 呼び出しが行われないためです。

   --region

   有効な AWS リージョン（例： us-east-1 ）。この値は、クラスターが存在するリージョンと一致する必要はありません。

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

   $ cp ${TEMPDIR}/<number>-keys.json ${TEMPDIR}/jwks.new.json

   <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

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

   $ jq -s '{ keys: map(.keys[])}' ${TEMPDIR}/jwks.current.json ${TEMPDIR}/jwks.new.json > ${TEMPDIR}/jwks.combined.json

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

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

    $ oc adm wait-for-stable-cluster

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

    All clusteroperators are stable

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

    重要

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

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

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master

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

    $ oc adm wait-for-node-reboot nodes --all

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

    All nodes rebooted

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

    $ oc adm wait-for-stable-cluster

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

    All clusteroperators are stable

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