TLS 引导

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

引导这些组件（尤其是需要证书才能安全地与 kube-apiserver 通信的工作节点）的正常过程可能很困难，因为它通常超出了 Kubernetes 的范围，需要大量额外工作。这反过来又会使初始化或扩展集群变得困难。

为了简化此过程，从 1.4 版本开始，Kubernetes 引入了证书请求和签名 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，将令牌限定到一个组可以提供很大的灵活性。例如，您可以在完成节点配置后禁用特定引导组的访问权限。

引导令牌

引导令牌在 此处 有详细说明。这些令牌存储为 Kubernetes 集群中的秘密，然后颁发给各个 kubelet。您可以为整个集群使用单个令牌，也可以为每个工作节点颁发一个令牌。

该过程分为两个步骤

1. 使用令牌 ID、秘密和范围创建 Kubernetes 秘密。
2. 将令牌颁发给 kubelet

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

创建秘密的详细信息可以在 此处 找到。

如果您想使用引导令牌，则必须使用以下标志在 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 unit 文件中）以启用令牌文件。有关更多详细信息，请参阅此处的文档。

授权 kubelet 创建 CSR

现在，引导节点已认证为system:bootstrappers组的一部分，它需要授权创建证书签名请求 (CSR) 以及在完成后检索它。幸运的是，Kubernetes 附带了一个具有这些（且仅这些）权限的ClusterRole，即system:node-bootstrapper。

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

# 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 的证书请求并对这些请求进行身份验证，但控制器管理器负责颁发实际的已签名证书。

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

为了使控制器管理器能够签署证书，它需要以下内容

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

访问密钥和证书

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

由于这些已签名证书将反过来由 kubelet 用于向 kube-apiserver 进行身份验证，因此重要的是，在此阶段提供给控制器管理器的 CA 也必须被 kube-apiserver 信任以进行身份验证。这通过标志--client-ca-file=FILENAME（例如，--client-ca-file=/var/lib/kubernetes/ca.pem）提供给 kube-apiserver，如 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，您需要告诉控制器管理器批准它们是可以接受的。这是通过向正确的组授予 RBAC 权限来完成的。

有两组不同的权限

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

要启用 kubelet 请求和接收新证书，请创建一个将引导节点所属的组system:bootstrappers绑定到授予其权限的ClusterRole的ClusterRoleBinding，即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 续订其自己的客户端证书，请创建一个将完全运行的节点所属的组system:nodes绑定到授予其权限的ClusterRole的ClusterRoleBinding，即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

csrapproving 控制器作为kube-controller-manager的一部分提供，默认情况下已启用。该控制器使用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 实现了用于启用其客户端和/或服务证书轮换的功能。请注意，服务证书的轮换是beta功能，需要 kubelet 上的RotateKubeletServerCertificate功能标志（默认情况下已启用）。

您可以通过在现有凭据过期时创建新的 CSR 来配置 kubelet 以轮换其客户端证书。要启用此功能，请使用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 和其他特定于节点的服务不作为独立进程运行，而是作为kube-system命名空间中的 daemonset 运行。由于它将在集群内，因此您可以为其提供具有适当权限的服务帐户以执行其活动。这可能是配置此类服务的简便方法。

kubectl 批准

CSR 可以通过控制器管理器内置的批准流程之外的方式进行批准。

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