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，并将签名者名称设置为 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 能够接受令牌作为身份验证。这些令牌是任意的，但应代表至少 128 位熵，这些熵来自安全随机数生成器（例如，大多数现代 Linux 系统上的 /dev/urandom）。您可以通过多种方式生成令牌。例如

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。

为此，您只需创建一个 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 本地签名者的形式。目前，所有颁发的证书都具有 1 年有效期和默认的一组密钥用途。

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

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

访问密钥和证书

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

由于这些签署的证书将被 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 请求和接收新的证书，请创建一个 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

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。