使用 kubeadm 进行证书管理

特征状态： Kubernetes v1.15 [stable]

kubeadm生成的客户端证书在 1 年后过期。本页介绍如何使用 kubeadm 管理证书续订。它还涵盖了与 kubeadm 证书管理相关的其他任务。

在你开始之前

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

使用自定义证书

默认情况下，kubeadm 会生成集群运行所需的所有证书。您可以通过提供自己的证书来覆盖此行为。

为此，您必须将它们放在 --cert-dir标志或certificatesDirkubeadm 的字段指定的任何目录中ClusterConfiguration。默认情况下这是/etc/kubernetes/pki.

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

外部 CA 模式

也可以只提供ca.crt文件而不 提供ca.key文件（这仅适用于根 CA 文件，不适用于其他证书对）。如果所有其他证书和 kubeconfig 文件都已到位，kubeadm 会识别这种情况并激活“外部 CA”模式。kubeadm 将在磁盘上没有 CA 密钥的情况下继续。

相反，独立运行控制器管理器--controllers=csrsigner并指向 CA 证书和密钥。

PKI 证书和要求包括有关设置集群以使用外部 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

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

此外，如果证书是外部管理的，kubeadm 会通知用户；在这种情况下，用户应该注意手动/使用其他工具管理证书更新。

警告： kubeadm无法管理由外部 CA 签名的证书。注意： kubelet.conf不包含在上面的列表中，因为 kubeadm 将 kubelet 配置为 使用/var/lib/kubelet/pki. 要修复过期的 kubelet 客户端证书，请参阅 Kubelet 客户端证书轮换失败。警告：

在使用 .创建的节点上kubeadm init，在 kubeadm 版本 1.17 之前，存在一个 错误，您必须手动修改kubelet.conf. 完成后kubeadm init，您应该更新kubelet.conf以指向旋转的 kubelet 客户端证书，方法是将client-certificate-data和替换client-key-data为：

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如果您对证书续订有更复杂的要求，您可以通过传递tokubeadm upgrade apply或 to 来退出默认行为kubeadm upgrade node。

警告：在 kubeadm 版本 1.17 之前，存在一个错误，其中--certificate-renewal默认 值为 命令。在这种情况下，您应该明确设置. falsekubeadm upgrade node--certificate-renewal=true

手动更新证书

您可以随时使用该kubeadm certs renew命令手动更新您的证书。

此命令使用 CA（或前端代理 CA）证书和存储在/etc/kubernetes/pki.

运行命令后，您应该重新启动控制平面 Pod。这是必需的，因为当前并非所有组件和证书都支持动态证书重新加载。 静态Pod 由本地 kubelet 管理，而不是由 API Server 管理，因此无法使用 kubectl 删除和重启它们。要重新启动静态 Pod，您可以暂时从中删除其清单文件/etc/kubernetes/manifests/ 并等待 20 秒（请参阅KubeletConfiguration structfileCheckFrequency中的值。如果 Pod 不再位于清单目录中，kubelet 将终止该 Pod。然后您可以将文件移回并在之后再过一段时间，kubelet 将重新创建 Pod，并且可以完成组件的证书更新。fileCheckFrequency

警告：如果您正在运行 HA 集群，则需要在所有控制平面节点上执行此命令。注意： certs renew使用现有证书作为属性（Common Name、Organization、SAN 等）的权威来源，而不是 kubeadm-config ConfigMap。强烈建议使它们保持同步。

kubeadm certs renew提供以下选项：

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

• --csr-only可用于通过生成证书签名请求来使用外部 CA 更新证书（无需实际更新证书）；有关更多信息，请参见下一段。

• 也可以更新单个证书而不是全部。

使用 Kubernetes 证书 API 续订证书

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

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

设置签名者

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

创建证书签名请求 (CSR)

请参阅创建 CertificateSigningRequest以使用 Kubernetes API 创建 CSR。

使用外部 CA 续订证书

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

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

创建证书签名请求 (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）。

证书颁发机构 (CA) 轮换

Kubeadm 不支持开箱即用的 CA 证书轮换或替换。

有关手动轮换或更换 CA 的更多信息，请参阅手动轮换 CA 证书。

启用签名的 kubelet 服务证书

默认情况下，kubeadm 部署的 kubelet 服务证书是自签名的。这意味着无法使用 TLS 保护从指标服务器等外部服务 到 kubelet 的连接。

要在新的 kubeadm 集群中配置 kubelet 以获取正确签名的服务证书，您必须将以下最小配置传递给kubeadm init：

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

如果您已经创建了集群，则必须通过执行以下操作对其进行调整：

• 在命名空间中查找并编辑kubelet-config-1.23ConfigMap kube-system。在那个 ConfigMap 中，kubeletkey 有一个 KubeletConfiguration 文档作为它的值。编辑 KubeletConfiguration 文档以设置serverTLSBootstrap: true.

• 在每个节点上，添加serverTLSBootstrap: true字段/var/lib/kubelet/config.yaml 并重新启动 kubeletsystemctl restart kubelet

该字段将通过从APIserverTLSBootstrap: true请求它们来启用 kubelet 服务证书的引导。certificates.k8s.io一个已知的限制是这些证书的 CSR（证书签名请求）不能被 kube-controller-manager - 中的默认签名者自动批准 kubernetes.io/kubelet-serving。这将需要用户或第三方控制者采取行动。

可以使用以下方式查看这些 CSR：

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration 
--- apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration 
serverTLSBootstrap: true

要批准它们，您可以执行以下操作：

kubectl certificate approve <CSR-name>

默认情况下，这些服务证书将在一年后过期。Kubeadm 将该 KubeletConfiguration字段设置rotateCertificates为true，这意味着在即将到期时，将为服务证书创建一组新的 CSR，并且必须获得批准才能完成轮换。要了解更多信息，请参阅 证书轮换。

如果您正在寻找自动批准这些 CSR 的解决方案，建议您联系您的云提供商并询问他们是否有使用带外机制验证节点身份的 CSR 签名者。

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

可以使用第三方自定义控制器：

• kubelet-csr-approver

这样的控制器不是安全机制，除非它不仅验证 CSR 中的 CommonName，而且验证请求的 IP 和域名。这将防止有权访问 kubelet 客户端证书的恶意行为者创建 CSR，请求为任何 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.

可用于的示例配置文件--config：

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 get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}"

以下示例将生成一个 kubeconfig 文件，该文件的凭据有效期为 24 小时，适用于johndoe属于该appdevs组的新用户：

kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h

以下示例将生成一个 kubeconfig 文件，其管理员凭据有效期为 1 周：

kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h

此页面上的项目是指提供 Kubernetes 所需功能的第三方产品或项目。Kubernetes 项目作者不对这些第三方产品或项目负责。有关更多详细信息，请参阅CNCF 网站指南。

在提出添加额外第三方链接的更改之前，您应该阅读内容指南。