Kubernetes证书管理涉及对集群中各种证书的生成、分发、轮换和撤销等工作。在证书管理过程中，kubeadm 是一个常用工具，它可以自动为一个新创建的 Kubernetes 集群生成和管理证书。
由 kubeadm 生成的客户端证书将在一年后到期。本教程将介绍如何使用 kubeadm 管理证书续订，并包含其他与 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 证书和密钥。
三、检查证书是否过期
可以使用 check-expiration 子命令来检查证书何时过期
kubeadm certs check-expiration
输出类似于以下内容：
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Dec 30, 2020 23:36 UTC 364d no apiserver Dec 30, 2020 23:36 UTC 364d ca no apiserver-etcd-client Dec 30, 2020 23:36 UTC 364d etcd-ca no apiserver-kubelet-client Dec 30, 2020 23:36 UTC 364d ca no controller-manager.conf Dec 30, 2020 23:36 UTC 364d no etcd-healthcheck-client Dec 30, 2020 23:36 UTC 364d etcd-ca no etcd-peer Dec 30, 2020 23:36 UTC 364d etcd-ca no etcd-server Dec 30, 2020 23:36 UTC 364d etcd-ca no front-proxy-client Dec 30, 2020 23:36 UTC 364d front-proxy-ca no scheduler.conf Dec 30, 2020 23:36 UTC 364d no CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED ca Dec 28, 2029 23:36 UTC 9y no etcd-ca Dec 28, 2029 23:36 UTC 9y no 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。
在通过 kubeadm init 创建的节点上，在 kubeadm 1.17 版本之前有一个缺陷， 该缺陷使得必须手动修改 kubelet.conf 文件的内容。 kubeadm init 操作结束之后，必须更新 kubelet.conf 文件将 client-certificate-data 和 client-key-data 改为如下所示的内容以便使用轮换后的 kubelet 客户端证书：
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem 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 中的密钥执行更新。
执行完此命令之后需要重启控制面 Pod。因为动态证书重载目前还不被所有组件和证书支持，所有这项操作是必须的。 静态 Pod 是被本地 kubelet 而不是 API 服务器管理，所以 kubectl 不能用来删除或重启他们。 要重启静态 Pod 可以临时将清单文件从 /etc/kubernetes/manifests/ 移除并等待 20 秒 。如果 Pod 不在清单目录里，kubelet 将会终止它。 在另一个 fileCheckFrequency 周期之后可以将文件移回去，kubelet 可以完成 Pod 的重建，而组件的证书更新操作也得以完成。
注意：
- 如果运行了一个 HA 集群，这个命令需要在所有控制面板节点上执行。
- certs renew 使用现有的证书作为属性（Common Name、Organization、SAN 等）的权威来源， 而不是 kubeadm-config ConfigMap。强烈建议使它们保持同步。
kubeadm certs renew 可以更新任何特定的证书，或者使用子命令 all 更新所有的证书，如下所示：
kubeadm certs renew all
使用 kubeadm 构建的集群通常会将 admin.conf 证书复制到 $HOME/.kube/config 中。 在这样的系统中，为了在更新 admin.conf 后更新 $HOME/.kube/config 的内容， 必须运行以下命令：
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config
六、Kubernetes API更新证书
这些是针对需要将其组织的证书基础结构集成到 kubeadm 构建的集群中的用户的高级主题。 如果默认的 kubeadm 配置满足了需求，则应让 kubeadm 管理证书。
设置一个签名者（Signer）：
Kubernetes 证书颁发机构不是开箱即用。可以配置外部签名者，例如 cert-manager， 也可以使用内置签名者。内置签名者是 kube-controller-manager 的一部分。
要激活内置签名者，请传递 –cluster-signing-cert-file 和 –cluster-signing-key-file 参数。如果正在创建一个新的集群，可以使用 kubeadm 的配置文件。
apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration controllerManager: extraArgs: cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt cluster-signing-key-file: /etc/kubernetes/pki/ca.key
七、通过外部CA更新证书
为了更好的与外部 CA 集成，kubeadm 还可以生成证书签名请求（CSR）。 CSR 表示向 CA 请求客户的签名证书。 在 kubeadm 术语中，通常由磁盘 CA 签名的任何证书都可以作为 CSR 生成。但是，CA 不能作为 CSR 生成。
1、创建证书签名请求 (CSR)
可以通过 kubeadm certs renew –csr-only 命令创建证书签名请求。CSR 和随附的私钥都在输出中给出。 可以传入一个带有 –csr-dir 的目录，将 CSR 输出到指定位置。 如果未指定 –csr-dir，则使用默认证书目录（/etc/kubernetes/pki）。
证书可以通过 kubeadm certs renew –csr-only 来续订。 和 kubeadm init 一样，可以使用 –csr-dir 标志指定一个输出目录。
- CSR 中包含一个证书的名字，域和 IP，但是未指定用法。 颁发证书时，CA 有责任指定正确的证书用法；
- 在 openssl 中，这是通过 openssl ca 命令 来完成的；
- 在 cfssl 中，这是通过 在配置文件中指定用法 来完成的。
使用首选方法对证书签名后，必须将证书和私钥复制到 PKI 目录（默认为 /etc/kubernetes/pki）。
八、启用已签名kubelet证书
默认情况下，kubeadm 所部署的 kubelet 服务证书是自签名（Self-Signed）。 这意味着从 metrics-server 这类外部服务发起向 kubelet 的链接时无法使用 TLS 来完成保护。
要在新的 kubeadm 集群中配置 kubelet 以使用被正确签名的服务证书， 必须向 kubeadm init 传递如下最小配置数据：
apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration --- apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration serverTLSBootstrap: true
如果已经创建了集群，必须通过执行下面的操作来完成适配：
- 找到 kube-system 名字空间中名为 kubelet-config-1.28 的 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：
kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION csr-9wvgt 112s kubernetes.io/kubelet-serving system:node:worker-1 Pending csr-lz97v 1m58s kubernetes.io/kubelet-serving system:node:control-plane-1 Pending
可以执行下面的操作来批准这些请求：
kubectl certificate approve <CSR-名称>
默认情况下，这些服务证书会在一年后过期。 kubeadm 将 KubeletConfiguration 的 rotateCertificates 字段设置为 true；这意味着证书快要过期时，会生成一组针对服务证书的新的 CSR，而这些 CSR 也要被批准才能完成证书轮换。要进一步了解这里的细节， 可参阅证书轮换文档。
如果在寻找一种能够自动批准这些 CSR 的解决方案，建议与云提供商 联系，询问他们是否有 CSR 签名组件，用来以带外（out-of-band）的方式检查 节点的标识符。
也可以使用第三方定制的控制器：
kubelet-csr-approver
除非既能够验证 CSR 中的 CommonName，也能检查请求的 IP 和域名， 这类控制器还算不得安全的机制。 只有完成彻底的检查，才有可能避免有恶意的、能够访问 kubelet 客户端证书的第三方为任何 IP 或域名请求服务证书。
九、为其他用户生成kubeconfig文件
在集群创建过程中，kubeadm 对 admin.conf 中的证书进行签名时，将其配置为 Subject: O = system:masters, CN = kubernetes-admin。 system:masters 是一个例外的超级用户组，可以绕过鉴权层（例如 RBAC）。 建议不要将 admin.conf 文件与任何人共享。
要使用 kubeadm kubeconfig user 命令为其他用户生成 kubeconfig 文件，这个命令支持命令行参数和 kubeadm 配置结构。 以上命令会将 kubeconfig 打印到终端上，也可以使用 kubeadm kubeconfig user … > somefile.conf 输出到一个文件中。
如下 kubeadm 可以在 –config 后加的配置文件示例：
# example.yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration # kubernetes 将作为 kubeconfig 中集群名称 clusterName: "kubernetes" # some-dns-address:6443 将作为集群 kubeconfig 文件中服务地址（IP 或者 DNS 名称） controlPlaneEndpoint: "some-dns-address:6443" # 从本地挂载集群的 CA 秘钥和 CA 证书 certificatesDir: "/etc/kubernetes/pki"
确保这些设置与所需的目标集群设置相匹配。可以使用以下命令查看现有集群的设置：
kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}"
以下示例将为在 appdevs 组的 johndoe 用户创建一个有效期为 24 小时的 kubeconfig 文件：
kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h
以下示例将为管理员创建一个有效期有一周的 kubeconfig 文件：
kubeadm kubeconfig user --config example.yaml --client-name admin --
