TLS 启动引导

启动引导这些组件的正常过程，尤其是需要证书来与 kube-apiserver 安全通信的工作节点， 可能会是一个具有挑战性的过程，因为这一过程通常不受 Kubernetes 控制，需要不少额外工作。 这也使得初始化或者扩缩一个集群的操作变得具有挑战性。

为了简化这一过程，从 1.4 版本开始，Kubernetes 引入了一个证书请求和签名 API。 该提案可在这里看到。

本文档描述节点初始化的过程，如何为 kubelet 配置 TLS 客户端证书启动引导， 以及其背后的工作原理。

当工作节点启动时，kubelet 执行以下操作：

1. 寻找自己的 文件
2. 检索 API 服务器的 URL 和凭据，通常是来自 kubeconfig 文件中的 TLS 密钥和已签名证书
3. 尝试使用这些凭据来与 API 服务器通信

假定 kube-apiserver 成功地认证了 kubelet 的凭据数据，它会将 kubelet 视为一个合法的节点并开始将 Pod 分派给该节点。

注意，签名的过程依赖于：

• kubeconfig 中包含密钥和本地主机的证书
• 证书被 kube-apiserver 所信任的一个证书机构（CA）所签名

负责部署和管理集群的人有以下责任：

1. 创建 CA 密钥和证书
2. 将 CA 证书发布到 kube-apiserver 运行所在的控制平面节点上
3. 为每个 kubelet 创建密钥和证书；强烈建议为每个 kubelet 使用独一无二的、 CN 取值与众不同的密钥和证书
4. 使用 CA 密钥对 kubelet 证书签名
5. 将 kubelet 密钥和签名的证书发布到 kubelet 运行所在的特定节点上

本文中描述的 TLS 启动引导过程有意简化甚至完全自动化上述过程， 尤其是第三步之后的操作，因为这些步骤是初始化或者扩缩集群时最常见的操作。

在启动引导初始化过程中，会发生以下事情：

1. kubelet 启动
2. kubelet 看到自己没有对应的 kubeconfig 文件
3. kubelet 搜索并发现 bootstrap-kubeconfig 文件
4. kubelet 读取该启动引导文件，从中获得 API 服务器的 URL 和用途有限的一个“令牌（Token）”
5. kubelet 建立与 API 服务器的连接，使用上述令牌执行身份认证
6. kubelet 现在拥有受限制的凭据来创建和取回证书签名请求（CSR）
7. kubelet 为自己创建一个 CSR，并将其 signerName 设置为 kubernetes.io/kube-apiserver-client-kubelet
8. CSR 被以如下两种方式之一批复：

• 如果配置了，kube-controller-manager 会自动批复该 CSR
• 如果配置了，一个外部进程，或者是人，使用 Kubernetes API 或者使用 kubectl 来批复该 CSR

1. kubelet 所需要的证书被创建

2. 证书被发放给 kubelet

3. kubelet 取回该证书
4. kubelet 创建一个合适的 kubeconfig，其中包含密钥和已签名的证书
5. kubelet 开始正常操作
6. 更新的证书被批复并发放；取决于配置，这一过程可能是自动的或者手动完成

本文的其余部分描述配置 TLS 启动引导的必要步骤及其局限性。

配置

要配置 TLS 启动引导及可选的自动批复，你必须配置以下组件的选项：

• kube-apiserver
• kube-controller-manager
• kubelet
• 集群内的资源：ClusterRoleBinding 以及可能需要的 ClusterRole

此外，你需要有 Kubernetes 证书机构（Certificate Authority，CA）。

就像在没有 TLS 启动引导支持的情况下，你会需要证书机构（CA）密钥和证书。 这些数据会被用来对 kubelet 证书进行签名。 如前所述，将证书机构密钥和证书发布到控制平面节点是你的责任。

就本文而言，我们假定这些数据被发布到控制平面节点上的 /var/lib/kubernetes/ca.pem（证书）和 /var/lib/kubernetes/ca-key.pem（密钥）文件中。 我们将这两个文件称作“Kubernetes CA 证书和密钥”。 所有 Kubernetes 组件（kubelet、kube-apiserver、kube-controller-manager） 都使用这些凭据，并假定这里的密钥和证书都是 PEM 编码的。

kube-apiserver 配置

启用 TLS 启动引导对 kube-apiserver 有若干要求：

• 能够识别对客户端证书进行签名的 CA
• 能够对启动引导的 kubelet 执行身份认证，并将其置入 system:bootstrappers 组
• 能够对启动引导的 kubelet 执行鉴权操作，允许其创建证书签名请求（CSR）

识别客户证书

对于所有客户端证书的认证操作而言，这是很常见的。 如果还没有设置，要为 kube-apiserver 命令添加 --client-ca-file=FILENAME 标志来启用客户端证书认证，在标志中引用一个包含用来签名的证书的证书机构包， 例如：--client-ca-file=/var/lib/kubernetes/ca.pem。

为了让启动引导的 kubelet 能够连接到 kube-apiserver 并请求证书， 它必须首先在服务器上认证自身身份。你可以使用任何一种能够对 kubelet 执行身份认证的身份认证组件。

尽管所有身份认证策略都可以用来对 kubelet 的初始启动凭据来执行认证， 出于容易准备的因素，建议使用如下两个身份认证组件：

2. 令牌认证文件

启动引导令牌是一种对 kubelet 进行身份认证的方法，相对简单且容易管理， 且不需要在启动 kube-apiserver 时设置额外的标志。

无论选择哪种方法，这里的需求是 kubelet 能够被身份认证为某个具有如下权限的用户：

1. 创建和读取 CSR
2. 在启用了自动批复时，能够在请求节点客户端证书时得到自动批复

使用启动引导令牌执行身份认证的 kubelet 会被认证为 system:bootstrappers 组中的用户。这是使用启动引导令牌的一种标准方法。

启动引导令牌

启动引导令牌的细节在这里 详述。启动引导令牌在 Kubernetes 集群中存储为 Secret 对象，被发放给各个 kubelet。 你可以在整个集群中使用同一个令牌，也可以为每个节点发放单独的令牌。

这一过程有两个方面：

1. 基于令牌 ID、机密数据和范畴信息创建 Kubernetes Secret
2. 将令牌发放给 kubelet

从 kubelet 的角度，所有令牌看起来都很像，没有特别的含义。 从 kube-apiserver 服务器的角度，启动引导令牌是很特殊的。 根据其 type、namespace 和 name，kube-apiserver 能够将其认作特殊的令牌， 并授予携带该令牌的任何人特殊的启动引导权限，换言之，将其视为 system:bootstrappers 组的成员。这就满足了 TLS 启动引导的基本需求。

关于创建 Secret 的进一步细节可访问。

如果你希望使用启动引导令牌，你必须在 kube-apiserver 上使用下面的标志启用之：

令牌认证文件

kube-apiserver 能够将令牌视作身份认证依据。 这些令牌可以是任意数据，但必须表示为基于某安全的随机数生成器而得到的至少 128 位混沌数据。这里的随机数生成器可以是现代 Linux 系统上的 /dev/urandom。生成令牌的方式有很多种。例如：

head -c 16 /dev/urandom | od -An -t x | tr -d ' '

上面的命令会生成类似于 02b50b05283e98dd0fd71db496ef01e8 这样的令牌。

令牌文件看起来是下面的例子这样，其中前面三个值可以是任何值， 用引号括起来的组名称则只能用例子中给的值。

02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"

向 kube-apiserver 添加 --token-auth-file=FILENAME 标志（或许这要对 systemd 的单元文件作修改）以启用令牌文件。有关进一步细节的文档， 可参见。

授权 kubelet 创建 CSR

现在启动引导节点被 身份认证 为 system:bootstrapping 组的成员， 它需要被 授权 创建证书签名请求（CSR）并在证书被签名之后将其取回。 幸运的是，Kubernetes 提供了一个 ClusterRole，其中精确地封装了这些许可， system:node-bootstrapper。

为了实现这一点，你只需要创建 ClusterRoleBinding，将 system:bootstrappers 组绑定到集群角色 system:node-bootstrapper。

# 允许启动引导节点创建 CSR
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: create-csrs-for-bootstrapping
subjects:
- kind: Group
  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:node-bootstrapper
  apiGroup: rbac.authorization.k8s.io

API 服务器从 kubelet 收到证书请求并对这些请求执行身份认证， 但真正负责发放签名证书的是控制器管理器（controller-manager）。

控制器管理器通过一个证书发放的控制回路来执行此操作。该操作的执行方式是使用磁盘上的文件用 cfssl 本地签名组件来完成。 目前，所发放的所有证书都有一年的有效期，并设定了默认的一组密钥用法。

为了让控制器管理器对证书签名，它需要：

• 能够访问你之前所创建并分发的 “Kubernetes CA 密钥和证书”
• 启用 CSR 签名

如前所述，你需要创建一个 Kubernetes CA 密钥和证书，并将其发布到控制平面节点。 这些数据会被控制器管理器来对 kubelet 证书进行签名。

由于这些被签名的证书反过来会被 kubelet 用来在 kube-apiserver 执行普通的 kubelet 身份认证，很重要的一点是为控制器管理器所提供的 CA 也被 kube-apiserver 信任用来执行身份认证。CA 密钥和证书是通过 kube-apiserver 的标志 --client-ca-file=FILENAME（例如，--client-ca-file=/var/lib/kubernetes/ca.pem）， 来设定的，正如 kube-apiserver 配置节所述。

要将 Kubernetes CA 密钥和证书提供给 kube-controller-manager，可使用以下标志：

例如：

--cluster-signing-cert-file="/var/lib/kubernetes/ca.pem" --cluster-signing-key-file="/var/lib/kubernetes/ca-key.pem"

所签名的证书的合法期限可以通过下面的标志来配置：

批复

为了对 CSR 进行批复，你需要告诉控制器管理器批复这些 CSR 是可接受的。 这是通过将 RBAC 访问权限授予正确的组来实现的。

许可权限有两组：

• nodeclient：如果节点在为节点创建新的证书，则该节点还没有证书。 该节点使用前文所列的令牌之一来执行身份认证，因此是组 system:bootstrappers 组的成员。
• selfnodeclient：如果节点在对证书执行续期操作，则该节点已经拥有一个证书。 节点持续使用现有的证书将自己认证为 system:nodes 组的成员。

要允许 kubelet 请求并接收新的证书，可以创建一个 ClusterRoleBinding 将启动引导节点所处的组 system:bootstrappers 绑定到为其赋予访问权限的 ClusterRole system:certificates.k8s.io:certificatesigningrequests:nodeclient：

# 批复 "system:bootstrappers" 组的所有 CSR
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-csrs-for-group
subjects:
- kind: Group
  name: system:bootstrappers
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
  apiGroup: rbac.authorization.k8s.io

要允许 kubelet 对其客户端证书执行续期操作，可以创建一个 ClusterRoleBinding 将正常工作的节点所处的组 system:nodes 绑定到为其授予访问许可的 ClusterRole system:certificates.k8s.io:certificatesigningrequests:selfnodeclient：

kubelet 配置

最后，当控制平面节点被正确配置并且所有必要的身份认证和鉴权机制都就绪时， 我们可以配置 kubelet。

kubelet 需要以下配置来执行启动引导：

• 一个用来存储所生成的密钥和证书的路径（可选，可以使用默认配置）
• 一个用来指向尚不存在的 kubeconfig 文件的路径；kubelet 会将启动引导配置文件放到这个位置
• 一个指向启动引导 kubeconfig 文件的路径，用来提供 API 服务器的 URL 和启动引导凭据， 例如，启动引导令牌
• 可选的：轮换证书的指令

启动引导 kubeconfig 文件应该放在一个 kubelet 可访问的路径下，例如 /var/lib/kubelet/bootstrap-kubeconfig。

其格式与普通的 kubeconfig 文件完全相同。实例文件可能看起来像这样：

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /var/lib/kubernetes/ca.pem
    server: https://my.server.example.com:6443
  name: bootstrap
contexts:
- context:
    cluster: bootstrap
    user: kubelet-bootstrap
  name: bootstrap
current-context: bootstrap
preferences: {}
users:
  user:
    token: 07401b.f395accd246ae52d

需要额外注意的一些因素有：

• certificate-authority：指向 CA 文件的路径，用来对 kube-apiserver 所出示的服务器证书进行验证
• server：用来访问 kube-apiserver 的 URL
• token：要使用的令牌

令牌的格式并不重要，只要它与 kube-apiserver 的期望匹配即可。 在上面的例子中，我们使用的是启动引导令牌。 如前所述，任何合法的身份认证方法都可以使用，不限于令牌。

因为启动引导 kubeconfig 文件是一个标准的 kubeconfig 文件，你可以使用 kubectl 来生成该文件。要生成上面的示例文件：

kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-cluster bootstrap --server='https://my.server.example.com:6443' --certificate-authority=/var/lib/kubernetes/ca.pem
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-credentials kubelet-bootstrap --token=07401b.f395accd246ae52d
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-context bootstrap --user=kubelet-bootstrap --cluster=bootstrap
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig use-context bootstrap

要指示 kubelet 使用启动引导 kubeconfig 文件，可以使用下面的 kubelet 标志：

--bootstrap-kubeconfig="/var/lib/kubelet/bootstrap-kubeconfig" --kubeconfig="/var/lib/kubelet/kubeconfig"

在启动 kubelet 时，如果 --kubeconfig 标志所指定的文件并不存在，会使用通过标志 --bootstrap-kubeconfig 所指定的启动引导 kubeconfig 配置来向 API 服务器请求客户端证书。 在证书请求被批复并被 kubelet 收回时，一个引用所生成的密钥和所获得证书的 kubeconfig 文件会被写入到通过 --kubeconfig 所指定的文件路径下。 证书和密钥文件会被放到 --cert-dir 所指定的目录中。

前文所述的内容都与 kubelet 客户端证书相关，尤其是 kubelet 用来向 kube-apiserver 认证自身身份的证书。

kubelet 也可以使用 服务（Serving） 证书。kubelet 自身向外提供一个 HTTPS 末端， 包含若干功能特性。要保证这些末端的安全性，kubelet 可以执行以下操作之一：

• 使用通过 --tls-private-key-file 和 --tls-cert-file 所设置的密钥和证书
• 如果没有提供密钥和证书，则创建自签名的密钥和证书
• 通过 CSR API 从集群服务器请求服务证书

TLS 启动引导所提供的客户端证书默认被签名为仅用于 client auth（客户端认证）， 因此不能作为提供服务的证书，或者 server auth。

不过，你可以启用服务器证书，至少可以部分地通过证书轮换来实现这点。

证书轮换

Kubernetes v1.8 和更高版本的 kubelet 实现了对客户端证书与/或服务证书进行轮换 这一 Beta 特性。这一特性通过 kubelet 对应的 RotateKubeletClientCertificate 和 RotateKubeletServerCertificate 特性门控标志来控制，并且是默认启用的。

RotateKubeletClientCertificate 会导致 kubelet 在其现有凭据即将过期时通过创建新的 CSR 来轮换其客户端证书。要启用此功能特性，可将下面的标志传递给 kubelet：

RotateKubeletServerCertificate 会让 kubelet 在启动引导其客户端凭据之后请求一个服务证书 且 对该服务证书执行轮换操作。要启用此功能特性，将下面的标志传递给 kubelet：

--rotate-server-certificates

说明：

出于安全原因，Kubernetes 核心中所实现的 CSR 批复控制器并不会自动批复节点的服务证书。 要使用 RotateKubeletServerCertificate 功能特性， 集群运维人员需要运行一个定制的控制器或者手动批复服务证书的请求。

对 kubelet 服务证书的批复过程因集群部署而异，通常应该仅批复如下 CSR：

1. 由节点发出的请求（确保 spec.username 字段形式为 system:node:<nodeName> 且 spec.groups 包含 system:nodes）
2. 请求中包含服务证书用法（确保 spec.usages 中包含 server auth，可选地也可包含 digital signature 和 key encipherment，且不包含其它用法）
3. 仅包含隶属于请求节点的 IP 和 DNS 的 subjectAltNames，没有 URI 和 Email 形式的 subjectAltNames（解析 spec.request 中的 x509 证书签名请求可以检查 subjectAltNames）

本文所描述的所有 TLS 启动引导内容都与 kubelet 相关。不过，其它组件也可能需要直接与 kube-apiserver 直接通信。容易想到的是 kube-proxy，同样隶属于 Kubernetes 的节点组件并且运行在所有节点之上，不过也可能包含一些其它负责监控或者联网的组件。

与 kubelet 类似，这些其它组件也需要一种向 kube-apiserver 认证身份的方法。 你可以用几种方法来生成这类凭据：

• 较老的方式：和 kubelet 在 TLS 启动引导之前所做的一样，用类似的方式创建和分发证书。
• DaemonSet：由于 kubelet 自身被加载到所有节点之上，并且有足够能力来启动基本服务， 你可以运行将 kube-proxy 和其它特定节点的服务作为 kube-system 名字空间中的 DaemonSet 来执行，而不是独立的进程。由于 DaemonSet 位于集群内部， 你可以为其指派一个合适的服务账户，使之具有适当的访问权限来完成其使命。 这也许是配置此类服务的最简单的方法。

kubectl 批复

CSRs 可以在控制器管理其内置的批复工作流之外被批复。

签名控制器并不会立即对所有证书请求执行签名操作。相反， 它会等待这些请求被某具有适当特权的用户标记为 “Approved（已批准）”状态。 这一流程有意允许由外部批复控制器来自动执行的批复， 或者由控制器管理器内置的批复控制器来自动批复。 不过，集群管理员也可以使用 kubectl 来手动批准证书请求。 管理员可以通过 kubectl get csr 来列举所有的 CSR，使用 kubectl descsribe csr <name> 来描述某个 CSR 的细节。 管理员可以使用 kubectl certificate approve <name 来批准某 CSR，或者 kubectl certificate deny <name> 来拒绝某 CSR。