第 10 章 更改云供应商凭证配置

流程

1. 配置以下环境变量：

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

   1

   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}')

   • 对于将 OIDC 配置存储在 IAM 身份提供程序通过公共 CloudFront 发布 URL 访问的专用 S3 存储桶中的 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 服务器创建的服务帐户签名密钥 secret 下载公钥：

   $ 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. 运行以下命令，使用公钥创建一个 key.json 文件：

   $ ccoctl aws create-identity-provider \
     --dry-run \

   1

   
     --output-dir ${TEMPDIR} \
     --public-key-file=${TEMPDIR}/serviceaccount-signer.public \

   2

   
     --name fake \

   3

   
     --region us-east-1 

   4

   1

   --dry-run 选项会将文件（包括新 keys.json 文件）输出到磁盘，而不会发出 API 调用。

   2

   指定您在上一步中下载的公钥的路径。

   3

   因为 -dry-run 选项不会发出任何 API 调用，所以有些参数并不需要实际值。

   4

   指定任何有效的 AWS 区域，如 us-east-1。这个值不需要与集群所在的区域匹配。

6. 运行以下命令来重命名 keys.json 文件：

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

   其中 <number> 是一个两位数字的值，具体因您的环境而异。

7. 运行以下命令，从云供应商下载现有的 key.json 文件：

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

8. 运行以下命令组合两个 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：

    $ 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 服务器创建的服务帐户签名密钥 secret 下载公钥：

   $ 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. 运行以下命令，使用公钥创建一个 key.json 文件：

   $ ccoctl gcp create-workload-identity-provider \
     --dry-run \

   1

   
     --output-dir=${TEMPDIR} \
     --public-key-file=${TEMPDIR}/serviceaccount-signer.public \

   2

   
     --name fake \

   3

   
     --project fake \
     --workload-identity-pool fake

   1

   --dry-run 选项会将文件（包括新 keys.json 文件）输出到磁盘，而不会发出 API 调用。

   2

   指定您在上一步中下载的公钥的路径。

   3

   因为 -dry-run 选项不会发出任何 API 调用，所以有些参数并不需要实际值。

6. 运行以下命令来重命名 keys.json 文件：

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

   其中 <number> 是一个两位数字的值，具体因您的环境而异。

7. 运行以下命令，从云供应商下载现有的 key.json 文件：

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

8. 运行以下命令组合两个 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：

    $ 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 服务器创建的服务帐户签名密钥 secret 下载公钥：

   $ 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. 运行以下命令，使用公钥创建一个 key.json 文件：

   $ ccoctl aws create-identity-provider \

   1

   
     --dry-run \

   2

   
     --output-dir ${TEMPDIR} \
     --public-key-file=${TEMPDIR}/serviceaccount-signer.public \

   3

   
     --name fake \

   4

   
     --region us-east-1 

   5

   1

   ccoctl azure 命令没有包括 --dry-run 选项。要使用 -dry-run 选项，需要为 Azure 集群指定 aws。

   2

   --dry-run 选项会将文件（包括新 keys.json 文件）输出到磁盘，而不会发出 API 调用。

   3

   指定您在上一步中下载的公钥的路径。

   4

   因为 -dry-run 选项不会发出任何 API 调用，所以有些参数并不需要实际值。

   5

   指定任何有效的 AWS 区域，如 us-east-1。这个值不需要与集群所在的区域匹配。

6. 运行以下命令来重命名 keys.json 文件：

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

   其中 <number> 是一个两位数字的值，具体因您的环境而异。

7. 运行以下命令，从云供应商下载现有的 key.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. 运行以下命令组合两个 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：

    $ 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