TLS 引导

在 Kubernetes 集群中，工作节点上的组件（kubelet 和 kube-proxy）需要与 Kubernetes 控制平面组件（特别是 kube-apiserver）进行通信。为了确保通信的私密性、不被干扰，并确保集群中的每个组件都与另一个受信任的组件通信，我们强烈建议在节点上使用客户端 TLS 证书。

引导这些组件的正常过程，特别是需要证书才能安全地与 kube-apiserver 通信的工作节点，可能是一个具有挑战性的过程，因为它通常超出 Kubernetes 的范围，需要大量的额外工作。这反过来又会使集群的初始化或扩缩变得困难。

为了简化此过程，Kubernetes 从 1.4 版开始引入了证书请求和签名 API。该提案可以在此处找到。

本文档描述了节点初始化过程、如何为 kubelet 设置 TLS 客户端证书引导以及其工作原理。

初始化过程

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

1. 查找其 kubeconfig 文件
2. 从 kubeconfig 文件中检索 API 服务器的 URL 和凭据，通常是 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 引导旨在简化、部分甚至完全自动化步骤 3 及之后的步骤，因为这些步骤在初始化或扩缩集群时最常见。

引导初始化

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

1. kubelet 启动
2. kubelet 发现它没有 kubeconfig 文件
3. kubelet 搜索并找到 bootstrap-kubeconfig 文件
4. kubelet 读取其引导文件，检索 API 服务器的 URL 和一个有限用途的“令牌”
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
9. 为 kubelet 创建证书
10. 证书颁发给 kubelet
11. kubelet 检索证书
12. kubelet 使用密钥和签名证书创建一个适当的 kubeconfig
13. kubelet 开始正常运行
14. 可选：如果已配置，kubelet 会在其接近过期时自动请求续订证书
15. 续订的证书根据配置自动或手动批准和颁发。

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

配置

要配置 TLS 引导和可选的自动批准，您必须在以下组件上配置选项：

• kube-apiserver
• kube-controller-manager
• kubelet
• 集群内资源：ClusterRoleBinding 和可能的 ClusterRole

此外，您还需要 Kubernetes 证书颁发机构 (CA)。

证书颁发机构

与非引导方式一样，您将需要一个证书颁发机构 (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 配置

kube-apiserver 启用 TLS 引导有几个要求：

• 识别签署客户端证书的 CA
• 将引导 kubelet 认证到 system:bootstrappers 组
• 授权引导 kubelet 创建证书签名请求 (CSR)

识别客户端证书

这对于所有客户端证书身份验证都是正常的。如果尚未设置，请将 --client-ca-file=FILENAME 标志添加到 kube-apiserver 命令以启用客户端证书身份验证，引用包含签名证书的证书颁发机构包，例如 --client-ca-file=/var/lib/kubernetes/ca.pem。

初始引导身份验证

为了让引导 kubelet 连接到 kube-apiserver 并请求证书，它必须首先向服务器进行身份验证。您可以使用任何可以认证 kubelet 的身份验证器。

虽然任何身份验证策略都可以用于 kubelet 的初始引导凭据，但建议使用以下两种身份验证器以简化配置。

1. 引导令牌
2. 令牌认证文件

使用引导令牌是一种更简单、更易于管理的 kubelet 身份验证方法，并且在启动 kube-apiserver 时不需要任何额外的标志。

无论您选择哪种方法，要求是 kubelet 能够以具有以下权利的用户身份进行身份验证：

1. 创建和检索 CSR
2. 如果启用了自动批准，则自动批准请求节点客户端证书。

使用引导令牌进行身份验证的 kubelet 以 system:bootstrappers 组中的用户身份进行身份验证，这是使用的标准方法。

随着此功能的成熟，您应该确保令牌绑定到基于角色的访问控制 (RBAC) 策略，该策略严格限制请求（使用引导令牌）仅限于与证书配置相关的客户端请求。有了 RBAC，将令牌范围限定到某个组可以提供很大的灵活性。例如，在完成节点配置后，您可以禁用特定引导组的访问权限。

引导令牌

引导令牌的详细信息可在此处获取。这些令牌作为 secret 存储在 Kubernetes 集群中，然后颁发给单个 kubelet。您可以为一个完整的集群使用一个令牌，或者为每个工作节点颁发一个令牌。

这个过程分为两部分：

1. 创建包含令牌 ID、secret 和范围的 Kubernetes secret。
2. 将令牌颁发给 kubelet

从 kubelet 的角度来看，一个令牌与其他令牌没有特殊意义。然而，从 kube-apiserver 的角度来看，引导令牌是特殊的。由于其 type、namespace 和 name，kube-apiserver 将其识别为特殊令牌，并授予使用该令牌进行身份验证的任何人特殊引导权限，特别是将他们视为 system:bootstrappers 组的成员。这满足了 TLS 引导的基本要求。

创建 secret 的详细信息可在此处获取。

如果您想使用引导令牌，则必须使用以下标志在 kube-apiserver 上启用它：

--enable-bootstrap-token-auth=true

令牌认证文件

kube-apiserver 能够接受令牌作为身份验证。这些令牌是任意的，但应至少包含从安全随机数生成器（例如大多数现代 Linux 系统上的 /dev/urandom）派生的 128 位熵。您可以通过多种方式生成令牌。例如：

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

这将生成看起来像 02b50b05283e98dd0fd71db496ef01e8 的令牌。

令牌文件应如下例所示，其中前三个值可以是任意的，引用的组名应如图所示：

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

将 --token-auth-file=FILENAME 标志添加到 kube-apiserver 命令（可能在您的 systemd 单元文件中）以启用令牌文件。有关更多详细信息，请参阅此处的文档。

授权 kubelet 创建 CSR

既然引导节点已作为 system:bootstrappers 组的一部分进行身份验证，它还需要被授权创建证书签名请求 (CSR) 并在完成后检索它。幸运的是，Kubernetes 附带了一个 ClusterRole，它精确地拥有这些（并且仅有这些）权限：system:node-bootstrapper。

为此，您只需创建一个 ClusterRoleBinding，将 system:bootstrappers 组绑定到集群角色 system:node-bootstrapper。

# enable bootstrapping nodes to create 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

kube-controller-manager 配置

虽然 apiserver 接收来自 kubelet 的证书请求并验证这些请求，但 controller-manager 负责颁发实际的签名证书。

controller-manager 通过证书颁发控制循环执行此功能。这采用 cfssl 本地签名者的形式，使用磁盘上的资产。目前，所有颁发的证书都具有一年有效期和一组默认的密钥用途。

为了让 controller-manager 签署证书，它需要以下内容：

• 访问您创建和分发的“Kubernetes CA 密钥和证书”
• 启用 CSR 签名

访问密钥和证书

如前所述，您需要创建 Kubernetes CA 密钥和证书，并将其分发到控制平面节点。这些将由 controller-manager 用于签署 kubelet 证书。

由于这些签名证书将反过来被 kubelet 用作常规 kubelet 向 kube-apiserver 进行身份验证，因此在此阶段提供给 controller-manager 的 CA 必须也受 kube-apiserver 信任以进行身份验证。这通过标志 --client-ca-file=FILENAME 提供给 kube-apiserver（例如，--client-ca-file=/var/lib/kubernetes/ca.pem），如 kube-apiserver 配置部分所述。

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

--cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key"

例如

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

签名证书的有效期可以通过标志配置：

--cluster-signing-duration

批准

为了批准 CSR，您需要告诉 controller-manager 它可以接受批准它们。这是通过授予 RBAC 权限给正确的组来完成的。

权限分为两组：

• nodeclient：如果一个节点正在为节点创建新证书，那么它还没有证书。它使用上面列出的令牌之一进行身份验证，因此属于 system:bootstrappers 组。
• selfnodeclient：如果一个节点正在续订其证书，那么它已经拥有一个证书（根据定义），它会不断使用该证书作为 system:nodes 组的一部分进行身份验证。

要使 kubelet 能够请求并接收新证书，请创建一个 ClusterRoleBinding，将引导节点所属的组 system:bootstrappers 绑定到授予其权限的 ClusterRole，即 system:certificates.k8s.io:certificatesigningrequests:nodeclient

# Approve all CSRs for the group "system:bootstrappers"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-csrs-for-group
subjects:
- kind: Group
  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
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

# Approve renewal CSRs for the group "system:nodes"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: auto-approve-renewals-for-nodes
subjects:
- kind: Group
  name: system:nodes
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
  apiGroup: rbac.authorization.k8s.io

作为 kube-controller-manager 的一部分提供的 csrapproving 控制器默认启用。该控制器使用 SubjectAccessReview API 来确定给定用户是否被授权请求 CSR，然后根据授权结果进行批准。为了防止与其他审批者发生冲突，内置审批者不会明确拒绝 CSR。它只忽略未经授权的请求。该控制器还会作为垃圾回收的一部分清除过期证书。

kubelet 配置

最后，在控制平面节点正确设置并所有必要的身份验证和授权到位后，我们可以配置 kubelet。

kubelet 需要以下配置才能进行引导：

• 用于存储它生成的密钥和证书的路径（可选，可以使用默认值）
• 尚未存在的 kubeconfig 文件的路径；它将在此处放置引导配置文件
• 引导 kubeconfig 文件的路径，用于提供服务器的 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:
- name: kubelet-bootstrap
  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 也可以使用服务证书。kubelet 本身暴露了一个 HTTPS 端点以实现某些功能。为了保护这些，kubelet 可以执行以下操作之一：

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

TLS 引导提供的客户端证书默认只用于 client auth 签名，因此不能用作服务证书或 server auth。

但是，您可以通过证书轮换至少部分启用其服务器证书。

证书轮换

Kubernetes v1.8 及更高版本的 kubelet 实现了启用其客户端和/或服务证书轮换的功能。请注意，服务证书的轮换是测试版功能，并且需要在 kubelet 上使用 RotateKubeletServerCertificate 功能标志（默认启用）。

您可以配置 kubelet，使其在现有凭据过期时通过创建新的 CSR 来轮换其客户端证书。要启用此功能，请使用 kubelet 配置文件的 rotateCertificates 字段或向 kubelet 传递以下命令行参数（已弃用）

--rotate-certificates

启用 RotateKubeletServerCertificate 会导致 kubelet 在引导其客户端凭据后既请求服务证书，又轮换该证书。要启用此行为，请使用 kubelet 配置文件的 serverTLSBootstrap 字段或向 kubelet 传递以下命令行参数（已弃用）

--rotate-server-certificates

其他身份验证组件

本文档中描述的所有 TLS 引导都与 kubelet 相关。然而，其他组件可能需要直接与 kube-apiserver 通信。值得注意的是 kube-proxy，它是 Kubernetes 节点组件的一部分，运行在每个节点上，但也可能包括其他组件，例如监控或网络。

像 kubelet 一样，这些其他组件也需要一种向 kube-apiserver 进行身份验证的方法。您有几种生成这些凭据的选项：

• 旧方法：以您在 TLS 引导之前为 kubelet 所做的方式创建和分发证书
• DaemonSet：由于 kubelet 本身加载在每个节点上，并且足以启动基础服务，因此您可以将 kube-proxy 和其他特定于节点的服务作为 DaemonSet 而不是独立进程运行在 kube-system 命名空间中。由于它将在集群内，您可以为其提供适当的服务帐户和执行其活动的相应权限。这可能是配置此类服务的最简单方法。

kubectl 批准

CSR 可以在控制器管理器内置的审批流程之外获得批准。

签名控制器不会立即签署所有证书请求。相反，它会等到它们被具有适当权限的用户标记为“已批准”状态。此流程旨在允许由外部审批控制器或核心控制器管理器中实现的审批控制器处理自动批准。但是，集群管理员也可以使用 kubectl 手动批准证书请求。管理员可以使用 kubectl get csr 列出 CSR，并使用 kubectl describe csr <name> 详细描述一个 CSR。管理员可以使用 kubectl certificate approve <name> 和 kubectl certificate deny <name> 批准或拒绝 CSR。