cfssl命令详解
https://www.cnblogs.com/even160941/p/16890124.html#3%E7%94%9F%E6%88%90ca%E8%AF%81%E4%B9%A6
https://v1-23.docs.kubernetes.io/zh/docs/setup/best-practices/certificates/#all-certificatesYou are viewing documentation for Kubernetes version: v1.23
Kubernetes v1.23 documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.
PKI 证书和要求
Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果你是使用 kubeadm 安装的 Kubernetes， 则会自动生成集群所需的证书。你还可以生成自己的证书。 例如，不将私钥存储在 API 服务器上，可以让私钥更加安全。此页面说明了集群必需的证书。
集群是如何使用证书的
Kubernetes 需要 PKI 才能执行以下操作：
- Kubelet 的客户端证书，用于 API 服务器身份验证
- API 服务器端点的证书
- 集群管理员的客户端证书，用于 API 服务器身份认证
- API 服务器的客户端证书，用于和 Kubelet 的会话
- API 服务器的客户端证书，用于和 etcd 的会话
- 控制器管理器的客户端证书/kubeconfig，用于和 API 服务器的会话
- 调度器的客户端证书/kubeconfig，用于和 API 服务器的会话
- 前端代理 的客户端及服务端证书
Note: 只有当你运行 kube-proxy 并要支持 扩展 API 服务器 时，才需要 front-proxy 证书
etcd 还实现了双向 TLS 来对客户端和对其他对等节点进行身份验证。
证书存放的位置
如果你是通过 kubeadm 安装的 Kubernetes，所有证书都存放在 /etc/kubernetes/pki 目录下。本文所有相关的路径都是基于该路径的相对路径。
手动配置证书
如果你不想通过 kubeadm 生成这些必需的证书，你可以通过下面两种方式之一来手动创建他们。
单根 CA
你可以创建一个单根 CA，由管理员控制器它。该根 CA 可以创建多个中间 CA，并将所有进一步的创建委托给 Kubernetes。
需要这些 CA：
| 路径 | 默认 CN | 描述 |
|---|---|---|
| ca.crt,key | kubernetes-ca | Kubernetes 通用 CA |
| etcd/ca.crt,key | etcd-ca | 与 etcd 相关的所有功能 |
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | 用于 前端代理 |
上面的 CA 之外，还需要获取用于服务账户管理的密钥对，也就是 sa.key 和 sa.pub。
所有的证书
如果你不想将 CA 的私钥拷贝至你的集群中，你也可以自己生成全部的证书。
需要这些证书：
| 默认 CN | 父级 CA | O (位于 Subject 中) | 类型 | 主机 (SAN) |
|---|---|---|---|---|
| kube-etcd | etcd-ca | server, client | localhost, 127.0.0.1 | |
| kube-etcd-peer | etcd-ca | server, client | <hostname>, <Host_IP>, localhost, 127.0.0.1 | |
| kube-etcd-healthcheck-client | etcd-ca | client | ||
| kube-apiserver-etcd-client | etcd-ca | system:masters | client | |
| kube-apiserver | kubernetes-ca | server | <hostname>, <Host_IP>, <advertise_IP>, [1] | |
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | client |
[1]: 用来连接到集群的不同 IP 或 DNS 名 （就像 kubeadm 为负载均衡所使用的固定 IP 或 DNS 名，kubernetes、kubernetes.default、kubernetes.default.svc、 kubernetes.default.svc.cluster、kubernetes.default.svc.cluster.local）。
其中，kind 对应一种或多种类型的 x509 密钥用途：
| kind | 密钥用途 |
|---|---|
| server | 数字签名、密钥加密、服务端认证 |
| client | 数字签名、密钥加密、客户端认证 |
Note:
上面列出的 Hosts/SAN 是推荐的配置方式；如果需要特殊安装，则可以在所有服务器证书上添加其他 SAN。
Note:
对于 kubeadm 用户：
- 不使用私钥，将证书复制到集群 CA 的方案，在 kubeadm 文档中将这种方案称为外部 CA。
- 如果将以上列表与 kubeadm 生成的 PKI 进行比较，你会注意到，如果使用外部 etcd，则不会生成
kube-etcd、kube-etcd-peer和kube-etcd-healthcheck-client证书。
证书路径
证书应放置在建议的路径中（以便 kubeadm使用）。无论使用什么位置，都应使用给定的参数指定路径。
| 默认 CN | 建议的密钥路径 | 建议的证书路径 | 命令 | 密钥参数 | 证书参数 |
|---|---|---|---|---|---|
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | --etcd-cafile | |
| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | --client-ca-file | |
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file |
| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file |
| kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | --requestheader-client-ca-file | |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | --requestheader-client-ca-file | |
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | --trusted-ca-file, --peer-trusted-ca-file | |
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
| etcd-ca | etcd/ca.crt | etcdctl | --cacert | ||
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |
注意事项同样适用于服务帐户密钥对：
| 私钥路径 | 公钥路径 | 命令 | 参数 |
|---|---|---|---|
| sa.key | kube-controller-manager | --service-account-private-key-file | |
| sa.pub | kube-apiserver | --service-account-key-file |
为用户帐户配置证书
你必须手动配置以下管理员帐户和服务帐户：
| 文件名 | 凭据名称 | 默认 CN | O (位于 Subject 中) |
|---|---|---|---|
| admin.conf | default-admin | kubernetes-admin | system:masters |
| kubelet.conf | default-auth | system:node:<nodeName> （参阅注释） | system:nodes |
| controller-manager.conf | default-controller-manager | system:kube-controller-manager | |
| scheduler.conf | default-scheduler | system:kube-scheduler |
Note: kubelet.conf 中 <nodeName> 的值 必须 与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。 有关更多详细信息，请阅读节点授权。
-
对于每个配置，请都使用给定的 CN 和 O 生成 x509 证书/密钥偶对。
-
为每个配置运行下面的
kubectl命令：
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system
这些文件用途如下：
| 文件名 | 命令 | 说明 |
|---|---|---|
| admin.conf | kubectl | 配置集群的管理员 |
| kubelet.conf | kubelet | 集群中的每个节点都需要一份 |
| controller-manager.conf | kube-controller-manager | 必需添加到 manifests/kube-controller-manager.yaml 清单中 |
| scheduler.conf | kube-scheduler | 必需添加到 manifests/kube-scheduler.yaml 清单中 |
https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#create-certificate-signing-requests-csr-1使用 kubeadm 进行证书管理
特性状态： Kubernetes v1.15 [stable]
由 kubeadm 生成的客户端证书在 1 年后到期。 本页说明如何使用 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 证书和密钥。
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
该命令显示 /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 客户端证书：
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 中的密钥执行更新。
执行完此命令之后你需要重启控制面 Pods。因为动态证书重载目前还不被所有组件和证书支持，所有这项操作是必须的。 静态 Pods 是被本地 kubelet 而不是 API Server 管理， 所以 kubectl 不能用来删除或重启他们。 要重启静态 Pod 你可以临时将清单文件从 /etc/kubernetes/manifests/ 移除并等待 20 秒 （参考 KubeletConfiguration 结构 中的fileCheckFrequency 值）。 如果 Pod 不在清单目录里，kubelet 将会终止它。 在另一个 fileCheckFrequency 周期之后你可以将文件移回去，为了组件可以完成 kubelet 将重新创建 Pod 和证书更新。
警告：
如果你运行了一个 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 的配置文件。
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)
有关使用 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 的目录，将 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 服务证书是自签名（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.26的 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）的方式检查 节点的标识符。
说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。
也可以使用第三方定制的控制器：
除非既能够验证 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 --validity-period 168h
本页面中的条目引用了第三方产品或项目，这些产品（项目）提供了 Kubernetes 所需的功能。Kubernetes 项目的开发人员不对这些第三方产品（项目）负责。请参阅CNCF 网站指南了解更多细节。
在提交更改建议，向本页添加新的第三方链接之前，你应该先阅读内容指南。
反馈
Kubernetes 中的证书工作机制
https://baijiahao.baidu.com/s?id=1709354401388871458&wfr=spider&for=pc
Kubernetes 中的证书工作机制
接触 Kubernetes 以来，我经常看到 Kubernetes 在不同的地方使用了证书（Certificate)，在 Kubernetes 安装和组件启动参数中也需要配置大量证书相关的参数。但是 Kubernetes 的文档在解释这些证书的工作机制方面做得并不是太好。经过大量的相关阅读和分析工作后，我基本弄清楚了 Kubernetes 中证书的使用方式。在本文中，我将试图以一种比官方文档更容易理解的方式来说明 Kubernetes 证书相关的工作机制，如果你也存在这方面的疑惑，希望这篇文章对你有所帮助。
Kubernetes 组件的认证方式
首先让我们来看一下 Kubernetes 中的组件：在 Kubernetes 中包含多个以独立进程形式运行的组件，这些组件之间通过 HTTP/gRPC 相互通信，以协同完成集群中应用的部署和管理工作。
从图中可以看到，Kubernetes 控制平面中包含了 etcd，kube-api-server，kube-scheduler，kube-controller-manager 等组件，这些组件会相互进行远程调用，例如 kube-api-server 会调用 etcd 接口存储数据，kube-controller-manager 会调用 kube-api-server 接口查询集群中的对象状态；同时，kube-api-server 也会和在工作节点上的 kubelet 和 kube-proxy 进行通信，以在工作节点上部署和管理应用。
以上这些组件之间的相互调用都是通过网络进行的。在进行网络通信时，通信双方需要验证对方的身份，以避免恶意第三方伪造身份窃取信息或者对系统进行攻击。为了相互验证对方的身份，通信双方中的任何一方都需要做下面两件事情：
-
向对方提供标明自己身份的一个证书
-
验证对方提供的身份证书是否合法，是否伪造的？
在 Kubernetes 中使用了数字证书来提供身份证明，我们可以把数字证书简单理解为我们在日常生活中使用的“身份证”，上面标注了证书拥有者的身份信息，例如名称，所属组织机构等。为了保证证书的权威性，会采用一个通信双方都信任的 CA（证书机构，Certificate Authority）来颁发证书。这就类似于现实生活中颁发“身份证”的政府机构。数字证书中最重要的内容实际上是证书拥有者的公钥，该公钥代表了用户的身份。
在 Kubernetes 的组件之间进行通信时，数字证书的验证是在协议层面通过 TLS 完成的，除了需要在建立通信时提供相关的证书和密钥外，在应用层面并不需要进行特殊处理。采用 TLS 进行验证有两种方式：
-
服务器单向认证：只需要服务器端提供证书，客户端通过服务器端证书验证服务的身份，但服务器并不验证客户端的身份。这种情况一般适用于对 Internet 开放的服务，例如搜索引擎网站，任何客户端都可以连接到服务器上进行访问，但客户端需要验证服务器的身份，以避免连接到伪造的恶意服务器。
-
双向 TLS 认证：除了客户端需要验证服务器的证书，服务器也要通过客户端证书验证客户端的身份。这种情况下服务器提供的是敏感信息，只允许特定身份的客户端访问。
在 Kubernetes 中，各个组件提供的接口中包含了集群的内部信息。如果这些接口被非法访问，将影响集群的安全，因此组件之间的通信需要采用双向 TLS 认证。即客户端和服务器端都需要验证对方的身份信息。在两个组件进行双向认证时，会涉及到下面这些证书相关的文件：
-
服务器端证书：服务器用于证明自身身份的数字证书，里面主要包含了服务器端的公钥以及服务器的身份信息。
-
服务器端私钥：服务器端证书中包含的公钥所对应的私钥。公钥和私钥是成对使用的，在进行 TLS 验证时，服务器使用该私钥来向客户端证明自己是服务器端证书的拥有者。
-
客户端证书：客户端用于证明自身身份的数字证书，里面主要包含了客户端的公钥以及客户端的身份信息。
-
客户端私钥：客户端证书中包含的公钥所对应的私钥，同理，客户端使用该私钥来向服务器端证明自己是客户端证书的拥有者。
-
服务器端 CA 根证书：签发服务器端证书的 CA 根证书，客户端使用该 CA 根证书来验证服务器端证书的合法性。
-
客户端 CA 根证书：签发客户端证书的 CA 根证书，服务器端使用该 CA 根证书来验证客户端证书的合法性。
如果你需要了解更多关于 TLS 认证的原理，可以阅读一下 medium 上的原文。
Kubernetes 中使用到的CA和证书
Kubernetes 中使用了大量的证书，本文不会试图覆盖到所有可能使用到的证书，但会讨论到主要的证书。理解了这些证书的使用方法和原理后，也能很快理解其他可能遇到的证书文件。下图标识出了在 kubernetes 中主要使用到的证书和其使用的位置：
Kubernetes 中使用到的主要证书
上图中使用序号对证书进行了标注。图中的箭头表明了组件的调用方向，箭头所指方向为服务提供方，另一头为服务调用方。为了实现 TLS 双向认证，服务提供方需要使用一个服务器证书，服务调用方则需要提供一个客户端证书，并且双方都需要使用一个 CA 证书来验证对方提供的证书。为了简明起见，上图中只标注了证书使用方提供的证书，并没有标注证书的验证方验证使用的 CA 证书。图中标注的这些证书的作用分别如下：
-
etcd 集群中各个节点之间相互通信使用的证书。由于一个 etcd 节点既为其他节点提供服务，又需要作为客户端访问其他节点，因此该证书同时用作服务器证书和客户端证书。
-
etcd 集群向外提供服务使用的证书。该证书是服务器证书。
-
kube-apiserver 作为客户端访问 etcd 使用的证书。该证书是客户端证书。
-
kube-apiserver 对外提供服务使用的证书。该证书是服务器证书。
-
kube-controller-manager 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
-
kube-scheduler 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
-
kube-proxy 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
-
kubelet 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
-
管理员用户通过 kubectl 访问 kube-apiserver 使用的证书，该证书是客户端证书。
-
kubelet 对外提供服务使用的证书。该证书是服务器证书。
-
kube-apiserver 作为客户端访问 kubelet 采用的证书。该证书是客户端证书。
-
kube-controller-manager 用于生成和验证 service-account token 的证书。该证书并不会像其他证书一样用于身份认证，而是将证书中的公钥/私钥对用于 service account token 的生成和验证。kube-controller-manager 会用该证书的私钥来生成 service account token，然后以 secret 的方式加载到 pod 中。pod 中的应用可以使用该 token 来访问 kube-apiserver， kube-apiserver 会使用该证书中的公钥来验证请求中的 token。我们将在文中稍后部分详细介绍该证书的使用方法。
通过这张图，对证书机制比较了解的读者可能已经看出，我们其实可以使用多个不同的 CA 来颁发这些证书。只要在通信的组件中正确配置用于验证对方证书的 CA 根证书，就可以使用不同的 CA 来颁发不同用途的证书。但我们一般建议采用统一的 CA 来颁发 kubernetes 集群中的所有证书，这是因为采用一个集群根 CA 的方式比采用多个 CA 的方式更容易管理，可以避免多个CA 导致的复杂的证书配置、更新等问题，减少由于证书配置错误导致的集群故障。
Kubernetes 中的证书配置
前面我们介绍了 Kubernetes 集群中主要使用到的证书。下面我们分别看一下如何将这些证书及其对应的私钥和 CA 根证书需要配置到 Kubernetes 中各个组件中，以供各个组件进行使用。这里假设使用一个集群根 CA 来颁发所有相关证书，因此涉及到 CA 的配置对应的证书文件名都是相同的。
etcd 证书配置
需要在 etcd 的启动命令行中配置以下证书相关参数：
-
etcd 对外提供服务的服务器证书及私钥。
-
etcd 节点之间相互进行认证的 peer 证书、私钥以及验证 peer 的 CA。
-
etcd 验证访问其服务的客户端的 CA。
/usr/local/bin/etcd \\ --cert-file=/etc/etcd/kube-etcd.pem \\ # 对外提供服务的服务器证书 --key-file=/etc/etcd/kube-etcd-key.pem \\ # 服务器证书对应的私钥 --peer-cert-file=/etc/etcd/kube-etcd-peer.pem \\ # peer 证书，用于 etcd 节点之间的相互访问 --peer-key-file=/etc/etcd/kube-etcd-peer-key.pem \\ # peer 证书对应的私钥 --trusted-ca-file=/etc/etcd/cluster-root-ca.pem \\ # 用于验证访问 etcd 服务器的客户端证书的 CA 根证书 --peer-trusted-ca-file=/etc/etcd/cluster-root-ca.pem\\ # 用于验证 peer 证书的 CA 根证书 ...
kube-apiserver 证书配置
需要在 kube-apiserver 中配置以下证书相关参数：
-
kube-apiserver 对外提供服务的服务器证书及私钥。
-
kube-apiserver 访问 etcd 所需的客户端证书及私钥。
-
kube-apiserver 访问 kubelet 所需的客户端证书及私钥。
-
验证访问其服务的客户端的 CA。
-
验证 etcd 服务器证书的 CA 根证书。
-
验证 service account token 的公钥。
/usr/local/bin/kube-apiserver \\ --tls-cert-file=/var/lib/kubernetes/kube-apiserver.pem \\ # 用于对外提供服务的服务器证书 --tls-private-key-file=/var/lib/kubernetes/kube-apiserver-key.pem \\ --etcd-certfile=/var/lib/kubernetes/kube-apiserver-etcd-client.pem \\ # 用于访问 etcd 的客户端证书 --etcd-keyfile=/var/lib/kubernetes/kube-apiserver-etcd-client-key.pem \\ # 用于访问 etcd 的客户端证书的私钥 --kubelet-client-certificate=/var/lib/kubernetes/kube-apiserver-kubelet-client.pem \\ # 用于访问 kubelet 的客户端证书 --kubelet-client-key=/var/lib/kubernetes/kube-apiserver-kubelet-client-key.pem \\ # 用于访问 kubelet 的客户端证书的私钥 --client-ca-file=/var/lib/kubernetes/cluster-root-ca.pem \\ # 用于验证访问 kube-apiserver 的客户端的证书的 CA 根证书 --etcd-cafile=/var/lib/kubernetes/cluster-root-ca.pem \\ # 用于验证 etcd 服务器证书的 CA 根证书 --kubelet-certificate-authority=/var/lib/kubernetes/cluster-root-ca.pem \\ # 用于验证 kubelet 服务器证书的 CA 根证书 --service-account-key-file=/var/lib/kubernetes/service-account.pem \\ # 用于验证 service account token 的公钥 ...
采用 kubeconfig 访问 kube-apiserver
Kubernetes 中的各个组件，包括kube-controller-mananger、kube-scheduler、kube-proxy、kubelet等，采用一个kubeconfig 文件中配置的信息来访问 kube-apiserver。该文件中包含了 kube-apiserver 的地址，验证 kube-apiserver 服务器证书的 CA 证书，自己的客户端证书和私钥等访问信息。
在一个使用 minikube 安装的集群中，生成的 kubeconfig 配置文件如下所示，这四个文件分别为 admin 用户， kube-controller-mananger、kubelet 和 kube-scheduler 的kubeconfig配置文件。
$ ls /etc/kubernetes/ admin.conf controller-manager.conf kubelet.conf scheduler.conf
我们打开 controller-manager.conf 来看一下，为了节约篇幅，这里没有写出证书和私钥的完整内容。
apiVersion: v1
clusters:
- cluster:
# 用于验证 kube-apiserver 服务器证书的 CA 根证书
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0tLS0tCg==
server: https://localhost:8443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: system:kube-controller-manager
name: system:kube-controller-manager@kubernetes
current-context: system:kube-controller-
kind: Config
preferences: {}
users:
- name: system:kube-controller-manager
user:
# 用于访问 kube-apiserver 的客户端证书
client-certificate-data: LS0tLS1CRUdJTiXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXQ0FURS0tLS0tCg==
# 客户端证书对应的私钥
client-key-data: LS0tLS1CRUdXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXtFWS0tLS0tCg==
可以看到，访问 kube-apiserver 所需要的相关证书内容已经被采用 base64 编码写入了文件中。其他几个文件中的内容也是类似的，只是配置的用户名和客户端证书有所不同。
在启动这些组件时，需要在参数中指出 kubeconfig 文件的路径，例如 kube-controller-manager 的启动命令如下。
/usr/local/bin/kube-controller-manager \\ --kubeconfig=/etc/kubernetes/controller-manager.conf # 下面几个证书和访问 kube-apiserver 无关，我们会在后面介绍到 --cluster-signing-cert-file=/var/lib/kubernetes/cluster-root-ca.pem # 用于签发证书的 CA 根证书 --cluster-signing-key-file=/var/lib/kubernetes/cluster-root-ca-key.pem # 用于签发证书的 CA 根证书的私钥 --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem # 用于对 service account token 进行签名的私钥 ...
Service Account 证书
Kubernetes 中有两类用户，一类为 user account，一类为 service account。 service account 主要被 pod 用于访问 kube-apiserver。 在为一个 pod 指定了 service account 后，kubernetes 会为该 service account 生成一个 JWT token，并使用 secret 将该 service account token 加载到 pod 上。pod 中的应用可以使用 service account token 来访问 api server。service account 证书被用于生成和验证 service account token。该证书的用法和前面介绍的其他证书不同，因为实际上使用的是其公钥和私钥，而并不需要对证书进行验证。
我们可以看到 service account 证书的公钥和私钥分别被配置到了 kube-apiserver 和 kube-controller-manager 的命令行参数中，如下所示：
/usr/local/bin/kube-apiserver \\ --service-account-key-file=/var/lib/kubernetes/service-account.pem \\ ... /usr/local/bin/kube-controller-manager \\ --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem # 用于对 service account token 进行签名的私钥 ...
下图展示了 kubernetes 中生成、使用和验证 service account token 的过程。
认证方法：客户端证书还是 token ？
我们可以看到，Kubernetes 提供了两种客户端认证的方法，控制面组件采用的是客户端数字证书;而在集群中部署的应用则采用了 service account token 的方式。为什么 Kubernetes 不为 service account 也生成一个证书，并采用该证书进行身份认证呢？ 实际上 Istio 就是这样做的，Istio 会自动为每个 service account 生成一个证书，并使用该证书来在 pod 中的应用之间建立双向 tls 认证。我没有找到 Kubernetes 这个设计决策的相关说明，如果你知道原因或对此有自己的见解，欢迎联系我进行探讨。
Kubernetes 证书签发
Kubernetes 提供了一个 certificates.k8s.io API，可以使用配置的 CA 根证书来签发用户证书。该 API 由 kube-controller-manager 实现，其签发证书使用的根证书在下面的命令行中进行配置。我们希望 Kubernetes 采用集群根 CA 来签发用户证书，因此在 kube-controller-manager 的命令行参数中将相关参数配置为了集群根 CA。
/usr/local/bin/kube-controller-manager \\ --cluster-signing-cert-file=/var/lib/kubernetes/cluster-root-ca.pem # 用于签发证书的 CA 根证书 --cluster-signing-key-file=/var/lib/kubernetes/cluster-root-ca-key.pem # 用于签发证书的 CA 根证书的私钥 ...
使用 TLS bootstrapping 简化 Kubelet 证书制作
在安装 Kubernetes 时，我们需要为每一个工作节点上的 Kubelet 分别生成一个证书。由于工作节点可能很多，手动生成 Kubelet 证书的过程会比较繁琐。为了解决这个问题，Kubernetes 提供了 TLS bootstrapping 的方式来简化 Kubelet 证书的生成过程。其原理是预先提供一个 bootstrapping token，kubelet 通过该 kubelet 调用 kube-apiserver 的证书签发 API 来生成 自己需要的证书。要启用该功能，需要在 kube-apiserver 中启用 --enable-bootstrap-token-auth ，并创建一个 kubelet 访问 kube-apiserver 使用的 bootstrap token secret。如果使用 kubeadmin 安装，可以使用 kubeadm token create命令来创建 token。
采用TLS bootstrapping 生成证书的流程如下：
-
调用 kube-apiserver 生成一个 bootstrap token。
-
将该 bootstrap token 写入到一个 kubeconfig 文件中，作为 kubelet 调用 kube-apiserver 的客户端验证方式。
-
通过
--bootstrap-kubeconfig启动参数将 bootstrap token 传递给 kubelet 进程。 -
Kubelet 采用bootstrap token 调用 kube-apiserver API，生成自己所需的服务器和客户端证书。
-
证书生成后，Kubelet 采用生成的证书和 kube-apiserver 进行通信，并删除本地的 kubeconfig 文件，以避免 bootstrap token 泄漏风险。
小结
Kubernetes 中使用了大量的证书来确保集群的安全，弄清楚这些证书的用途和配置方法将有助于我们深入理解 kubernetes 的安装过程和组件的配置。本文是笔者在学习 过程中整理的 Kubernetes 集群中主要使用到的证书，由于笔者对 Kubernetes 的理解有限，文章中难免存在部分错误，欢迎指正。
354
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
