使用 kubeadm 进行证书管理

FEATURE STATE: Kubernetes v1.15 [stable]

由 kubeadm 生成的客户端证书在 1 年后到期。 本页说明如何使用 kubeadm 管理证书续订。

准备开始

你应该熟悉 Kubernetes 中的 PKI 证书和要求。

使用自定义的证书

默认情况下, kubeadm 会生成运行一个集群所需的全部证书。 你可以通过提供你自己的证书来改变这个行为策略。

如果要这样做, 你必须将证书文件放置在通过 --cert-dir 命令行参数或者 kubeadm 配置中的 CertificatesDir 配置项指明的目录中。默认的值是 /etc/kubernetes/pki。

如果在运行 kubeadm init 之前存在给定的证书和私钥对，kubeadm 将不会重写它们。 例如，这意味着您可以将现有的 CA 复制到 /etc/kubernetes/pki/ca.crt 和 /etc/kubernetes/pki/ca.key 中，而 kubeadm 将使用此 CA 对其余证书进行签名。

外部 CA 模式

只提供了 ca.crt 文件但是不提供 ca.key 文件也是可以的 （这只对 CA 根证书可用，其它证书不可用）。 如果所有的其它证书和 kubeconfig 文件已就绪，kubeadm 检测到满足以上条件就会激活 “外部 CA” 模式。kubeadm 将会在没有 CA 密钥文件的情况下继续执行。

否则, kubeadm 将独立运行 controller-manager，附加一个 --controllers=csrsigner 的参数，并且指明 CA 证书和密钥。

PKI 证书和要求包括集群使用外部 CA 的设置指南。

检查证书是否过期

你可以使用 check-expiration 子命令来检查证书何时过期

  1. kubeadm certs check-expiration

输出类似于以下内容：

  1. CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
  2. admin.conf                 Dec 30, 2020 23:36 UTC   364d                                    no
  3. apiserver                  Dec 30, 2020 23:36 UTC   364d            ca                      no
  4. apiserver-etcd-client      Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
  5. apiserver-kubelet-client   Dec 30, 2020 23:36 UTC   364d            ca                      no
  6. controller-manager.conf    Dec 30, 2020 23:36 UTC   364d                                    no
  7. etcd-healthcheck-client    Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
  8. etcd-peer                  Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
  9. etcd-server                Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
  10. front-proxy-client         Dec 30, 2020 23:36 UTC   364d            front-proxy-ca          no
  11. scheduler.conf             Dec 30, 2020 23:36 UTC   364d                                    no
  13. CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
  14. ca                      Dec 28, 2029 23:36 UTC   9y              no
  15. etcd-ca                 Dec 28, 2029 23:36 UTC   9y              no
  16. front-proxy-ca          Dec 28, 2029 23:36 UTC   9y              no

该命令显示 /etc/kubernetes/pki 文件夹中的客户端证书以及 kubeadm（admin.conf, controller-manager.conf 和 scheduler.conf） 使用的 KUBECONFIG 文件中嵌入的客户端证书的到期时间/剩余时间。

另外， kubeadm 会通知用户证书是否由外部管理； 在这种情况下，用户应该小心的手动/使用其他工具来管理证书更新。

警告： kubeadm 不能管理由外部 CA 签名的证书

说明： 上面的列表中没有包含 kubelet.conf，因为 kubeadm 将 kubelet 配置为 自动更新证书。 轮换的证书位于目录 /var/lib/kubelet/pki。 要修复过期的 kubelet 客户端证书，请参阅 kubelet 客户端证书轮换失败。

警告：

在通过 kubeadm init 创建的节点上，在 kubeadm 1.17 版本之前有一个 缺陷，该缺陷 使得你必须手动修改 kubelet.conf 文件的内容。 kubeadm init 操作结束之后，你必须更新 kubelet.conf 文件 将 client-certificate-data 和 client-key-data 改为如下所示的内容 以便使用轮换后的 kubelet 客户端证书：

  1. client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
  2. client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

自动更新证书

kubeadm 会在控制面 升级 的时候更新所有证书。

这个功能旨在解决最简单的用例；如果你对此类证书的更新没有特殊要求， 并且定期执行 Kubernetes 版本升级（每次升级之间的间隔时间少于 1 年）， 则 kubeadm 将确保你的集群保持最新状态并保持合理的安全性。

说明： 最佳的做法是经常升级集群以确保安全。

如果你对证书更新有更复杂的需求，则可通过将 --certificate-renewal=false 传递给 kubeadm upgrade apply 或者 kubeadm upgrade node，从而选择不采用默认行为。

警告： kubeadm 在 1.17 版本之前有一个缺陷， 该缺陷导致 kubeadm update node 执行时 --certificate-renewal 的默认值被设置为 false。 在这种情况下，你需要显式地设置 --certificate-renewal=true。

手动更新证书

你能随时通过 kubeadm certs renew 命令手动更新你的证书。

此命令用 CA （或者 front-proxy-CA ）证书和存储在 /etc/kubernetes/pki 中的密钥执行更新。

警告： 如果你运行了一个 HA 集群，这个命令需要在所有控制面板节点上执行。

说明： certs renew 使用现有的证书作为属性 (Common Name、Organization、SAN 等) 的权威来源， 而不是 kubeadm-config ConfigMap 。强烈建议使它们保持同步。

kubeadm certs renew提供以下选项：

Kubernetes 证书通常在一年后到期。

  • --csr-only 可用于经过一个外部 CA 生成的证书签名请求来更新证书（无需实际替换更新证书）； 更多信息请参见下节。
  • 可以更新单个证书而不是全部证书。

用 Kubernetes 证书 API 更新证书

本节提供有关如何使用 Kubernetes 证书 API 执行手动证书更新的更多详细信息。

注意： 这些是针对需要将其组织的证书基础结构集成到 kubeadm 构建的集群中的用户的高级主题。 如果默认的 kubeadm 配置满足了你的需求，则应让 kubeadm 管理证书。

设置一个签名者（Signer）

Kubernetes 证书颁发机构不是开箱即用。 你可以配置外部签名者，例如 cert-manager， 也可以使用内置签名者。 内置签名者是 kube-controller-manager 的一部分。 要激活内置签名者，请传递 --cluster-signing-cert-file 和 --cluster-signing-key-file 参数。

如果你正在创建一个新的集群，你可以使用 kubeadm 的 配置文件。

  1. apiVersion: kubeadm.k8s.io/v1beta2
  2. kind: ClusterConfiguration
  3. controllerManager:
  4.   extraArgs:
  5.     cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
  6.     cluster-signing-key-file: /etc/kubernetes/pki/ca.key

创建证书签名请求 (CSR)

有关使用 Kubernetes API 创建 CSR 的信息， 请参见创建 CertificateSigningRequest。

通过外部 CA 更新证书

本节提供有关如何使用外部 CA 执行手动更新证书的更多详细信息。

为了更好的与外部 CA 集成，kubeadm 还可以生成证书签名请求（CSR）。 CSR 表示向 CA 请求客户的签名证书。 在 kubeadm 术语中，通常由磁盘 CA 签名的任何证书都可以作为 CSR 生成。但是，CA 不能作为 CSR 生成。

创建证书签名请求 (CSR)

你可以通过 kubeadm certs renew --csr-only 命令创建证书签名请求。

CSR 和随附的私钥都在输出中给出。 你可以传入一个带有 --csr-dir 的目录，将 CRS 输出到指定位置。 如果未指定 --csr-dir ，则使用默认证书目录（/etc/kubernetes/pki）。

证书可以通过 kubeadm certs renew --csr-only 来续订。 和 kubeadm init 一样，可以使用 --csr-dir 标志指定一个输出目录。

CSR 签署证书后，必须将证书和私钥复制到 PKI 目录（默认情况下为 /etc/kubernetes/pki）。

CSR 中包含一个证书的名字，域和 IP，但是未指定用法。 颁发证书时，CA 有责任指定正确的证书用法

使用首选方法对证书签名后，必须将证书和私钥复制到 PKI 目录（默认为 /etc/kubernetes/pki ）。

证书机构（CA）轮换

kubeadm 并不直接支持对 CA 证书的轮换或者替换。

关于手动轮换或者置换 CA 的更多信息，可参阅 手动轮换 CA 证书。

启用已签名的 kubelet 服务证书

默认情况下，kubeadm 所部署的 kubelet 服务证书是自签名（Self-Signed））。 这意味着从 metrics-server 这类外部服务发起向 kubelet 的链接时无法使用 TLS 来完成保护。

要在新的 kubeadm 集群中配置 kubelet 以使用被正确签名的服务证书， 你必须向 kubeadm init 传递如下最小配置数据：

  1. apiVersion: kubeadm.k8s.io/v1beta2
  2. kind: ClusterConfiguration
  3. ---
  4. apiVersion: kubelet.config.k8s.io/v1beta1
  5. kind: KubeletConfiguration
  6. serverTLSBootstrap: true

如果你已经创建了集群，你必须通过执行下面的操作来完成适配：

  • 找到 kube-system 名字空间中名为 kubelet-config-1.22 的 ConfigMap 并编辑之。 在该 ConfigMap 中，kubelet 键下面有一个 KubeletConfiguration 文档作为其取值。编辑该 KubeletConfiguration 文档以设置 serverTLSBootstrap: true。
  • 在每个节点上，在 /var/lib/kubelet/config.yaml 文件中添加 serverTLSBootstrap: true 字段，并使用 systemctl restart kubelet 来重启 kubelet。

字段 serverTLSBootstrap 将允许启动引导 kubelet 的服务证书，方式 是从 certificates.k8s.io API 处读取。这种方式的一种局限在于这些 证书的 CSR（证书签名请求）不能被 kube-controller-manager 中默认的 签名组件 kubernetes.io/kubelet-serving 批准。需要用户或者第三方控制器来执行此操作。

可以使用下面的命令来查看 CSR：

  1. kubectl get csr
  1. NAME        AGE     SIGNERNAME                        REQUESTOR                      CONDITION
  2. csr-9wvgt   112s    kubernetes.io/kubelet-serving     system:node:worker-1           Pending
  3. csr-lz97v   1m58s   kubernetes.io/kubelet-serving     system:node:control-plane-1    Pending

你可以执行下面的操作来批准这些请求：

  1. kubectl certificate approve <CSR-名称>

默认情况下，这些服务证书上会在一年后过期。 kubeadm 将 KubeletConfiguration 的 rotateCertificates 字段设置为 true；这意味着证书快要过期时，会生成一组针对服务证书的新的 CSR，而 这些 CSR 也要被批准才能完成证书轮换。 要进一步了解这里的细节，可参阅 证书轮换 文档。

如果你在寻找一种能够自动批准这些 CSR 的解决方案，建议你与你的云提供商 联系，询问他们是否有 CSR 签名组件，用来以带外（out-of-band）的方式检查 节点的标识符。

注意： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。

也可以使用第三方定制的控制器：

除非既能够验证 CSR 中的 CommonName，也能检查请求的 IP 和域名， 这类控制器还算不得安全的机制。 只有完成彻底的检查，才有可能避免有恶意的、能够访问 kubelet 客户端证书的第三方 为任何 IP 或域名请求服务证书。

最后修改 July 25, 2021 at 3:32 PM PST : [zh] docs: update old command and sync (73a030236)