手动轮换 CA 证书

此页面展示了如何手动轮换证书颁发机构 (CA) 证书。

开始之前

您需要拥有一个 Kubernetes 集群，并且 kubectl 命令行工具必须配置为与您的集群通信。建议在至少有两个节点的集群上运行本教程，这些节点不充当控制平面主机。如果您还没有集群，可以使用 minikube 创建一个，或者可以使用以下 Kubernetes 游乐场之一

• Killercoda
• 使用 Kubernetes

• 有关 Kubernetes 中身份验证的更多信息，请参阅 身份验证。
• 有关 CA 证书最佳实践的更多信息，请参阅 单根 CA。

手动轮换 CA 证书

1. 将新的 CA 证书和私钥（例如：ca.crt、ca.key、front-proxy-ca.crt 和 front-proxy-ca.key）分发到 Kubernetes 证书目录中的所有控制平面节点。

2. 更新 kube-controller-manager 的 --root-ca-file 标志以包含旧 CA 和新 CA，然后重新启动 kube-controller-manager。

   从现在开始创建的任何 ServiceAccount 都将获得包含旧 CA 和新 CA 的 Secret。

   注意

   kube-controller-manager 标志 --client-ca-file 和 --cluster-signing-cert-file 指定的文件不能是 CA 捆绑包。如果这些标志和 --root-ca-file 指向同一个 ca.crt 文件，该文件现在是一个捆绑包（包含旧 CA 和新 CA），您将遇到错误。要解决此问题，您可以将新 CA 复制到单独的文件中，并将标志 --client-ca-file 和 --cluster-signing-cert-file 指向该副本。一旦 ca.crt 不再是捆绑包，您就可以将问题标志恢复为指向 ca.crt 并删除副本。

   问题 1350 用于 kubeadm 跟踪 kube-controller-manager 无法接受 CA 捆绑包的错误。

3. 等待控制器管理器在服务帐户 Secret 中更新 ca.crt 以包含旧 CA 和新 CA 证书。

   如果在 API 服务器使用新 CA 之前启动了任何 Pod，则新 Pod 将获得此更新，并将信任旧 CA 和新 CA。

4. 重新启动使用集群内配置的所有 Pod（例如：kube-proxy、CoreDNS 等），以便它们可以使用来自链接到 ServiceAccount 的 Secret 的更新的证书颁发机构数据。

   • 确保 CoreDNS、kube-proxy 和其他使用集群内配置的 Pod 按预期工作。

5. 将旧 CA 和新 CA 附加到 kube-apiserver 配置中 --client-ca-file 和 --kubelet-certificate-authority 标志对应的文件。

6. 将旧 CA 和新 CA 附加到 kube-scheduler 配置中 --client-ca-file 标志对应的文件。

7. 通过分别替换 client-certificate-data 和 client-key-data 的内容来更新用户帐户的证书。

   有关为单个用户帐户创建证书的信息，请参阅 为用户帐户配置证书。

   此外，使用 Base64 编码的旧 CA 和新 CA 证书数据分别更新 kubeconfig 文件中的 certificate-authority-data 部分。

8. 更新 Cloud Controller Manager 的 --root-ca-file 标志以包含旧 CA 和新 CA，然后重新启动 cloud-controller-manager。

   注意

   如果您的集群没有 cloud-controller-manager，您可以跳过此步骤。

9. 以滚动方式执行以下步骤。

   1. 重新启动任何其他 聚合 API 服务器 或 Webhook 处理程序以信任新的 CA 证书。

   2. 通过更新 kubelet 配置中 clientCAFile 对应的文件以及 kubelet.conf 中的 certificate-authority-data 以在所有节点上使用旧 CA 和新 CA 来重新启动 kubelet。

      如果您的 kubelet 没有使用客户端证书轮换，请更新所有节点上 kubelet.conf 中的 client-certificate-data 和 client-key-data 以及通常位于 /var/lib/kubelet/pki 中的 kubelet 客户端证书文件。

   3. 使用由新 CA 签名的证书（apiserver.crt、apiserver-kubelet-client.crt 和 front-proxy-client.crt）重新启动 API 服务器。您可以使用现有的私钥或新的私钥。如果您更改了私钥，请在 Kubernetes 证书目录中更新这些私钥。

      由于集群中的 Pod 信任旧 CA 和新 CA，因此在 Pod 的 Kubernetes 客户端重新连接到新的 API 服务器后，将短暂断开连接。新的 API 服务器使用由新 CA 签名的证书。

      • 重新启动 kube-scheduler 以使用和信任新的 CA。
      • 确保控制平面组件日志中没有 TLS 错误。

      注意

        To generate certificates and private keys for your cluster using the `openssl` command line tool,
        see [Certificates (`openssl`)](/docs/tasks/administer-cluster/certificates/#openssl).
        You can also use [`cfssl`](/docs/tasks/administer-cluster/certificates/#cfssl).
      

   4. 为任何 DaemonSet 和 Deployment 添加注释以以更安全的方式滚动方式触发 Pod 替换。

   for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
       for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
           kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
       done
       for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
           kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
       done
   done
   

   注意

     To limit the number of concurrent disruptions that your application experiences,
     see [configure pod disruption budget](/docs/tasks/run-application/configure-pdb/).
   

    Depending on how you use StatefulSets you may also need to perform similar rolling replacement.
   

10. 如果您的集群使用引导令牌加入节点，请使用新的 CA 更新 kube-public 命名空间中的 ConfigMap cluster-info。

    base64_encoded_ca="$(base64 -w0 /etc/kubernetes/pki/ca.crt)"
    
    kubectl get cm/cluster-info --namespace kube-public -o yaml | \
        /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}/" | \
        kubectl apply -f -
    

11. 验证集群功能。

    1. 检查控制平面组件、kubelet 和 kube-proxy 的日志。确保这些组件没有报告任何 TLS 错误；有关更多详细信息，请参阅 查看日志。

    2. 验证来自任何聚合 API 服务器和使用集群内配置的 Pod 的日志。

12. 一旦成功验证了集群功能

    1. 更新所有服务帐户令牌以仅包含新的 CA 证书。

       • 所有使用集群内 kubeconfig 的 Pod 最终都需要重新启动以获取新的 Secret，这样就不会有 Pod 依赖于旧的集群 CA。

    2. 通过从 kubeconfig 文件和 --client-ca-file、--root-ca-file 标志对应的文件中删除旧 CA 来重新启动控制平面组件。

    3. 在每个节点上，通过从 clientCAFile 标志对应的文件和 kubelet kubeconfig 文件中删除旧 CA 来重新启动 kubelet。您应该以滚动更新的方式执行此操作。

       如果您的集群允许您进行此更改，您也可以通过替换节点而不是重新配置节点来进行滚动更新。