使用引导令牌进行认证

引导令牌是一种简单的持有者令牌，旨在用于创建新集群或将新节点加入现有集群。它旨在支持 kubeadm，但对于希望在不使用 kubeadm 的情况下启动集群的用户，它也可以在其他上下文中使用。它还设计用于通过 RBAC 策略与 kubelet TLS Bootstrapping 系统协同工作。

引导令牌概述

引导令牌使用特定类型的 Secret（bootstrap.kubernetes.io/token）来定义，这些 Secret 位于 kube-system 命名空间中。然后，API Server 中的 Bootstrap Authenticator 读取这些 Secret。 Controller Manager 中的 TokenCleaner 控制器负责移除过期令牌。令牌还用于通过 BootstrapSigner 控制器为在“发现”过程中使用的特定 ConfigMap 创建签名。

令牌格式

引导令牌的格式为 abcdef.0123456789abcdef。更正式地说，它们必须匹配正则表达式 [a-z0-9]{6}\.[a-z0-9]{16}。

令牌的第一部分是“令牌 ID”，被视为公开信息。在引用令牌但不泄露用于认证的秘密部分时会使用它。第二部分是“令牌秘密”，仅应与受信任方共享。

启用引导令牌认证

可以在 API Server 上使用以下标志启用引导令牌认证器

--enable-bootstrap-token-auth

启用后，引导令牌可以用作持有者令牌凭据，用于对 API Server 进行认证请求。

Authorization: Bearer 07401b.f395accd246ae52d

令牌以用户名 system:bootstrap:<token id> 进行认证，并且是 system:bootstrappers 组的成员。可以在令牌的 Secret 中指定额外的组。

通过在 Controller Manager 上启用 tokencleaner 控制器，可以自动删除过期令牌。

--controllers=*,tokencleaner

引导令牌 Secret 格式

每个有效令牌都由 kube-system 命名空间中的一个 secret 支持。你可以在此处找到完整的技术设计文档。

以下是 secret 的样子。

apiVersion: v1
kind: Secret
metadata:
  # Name MUST be of form "bootstrap-token-<token id>"
  name: bootstrap-token-07401b
  namespace: kube-system

# Type MUST be 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
  # Human readable description. Optional.
  description: "The default bootstrap token generated by 'kubeadm init'."

  # Token ID and secret. Required.
  token-id: 07401b
  token-secret: f395accd246ae52d

  # Expiration. Optional.
  expiration: 2017-03-10T03:22:11Z

  # Allowed usages.
  usage-bootstrap-authentication: "true"
  usage-bootstrap-signing: "true"

  # Extra groups to authenticate the token as. Must start with "system:bootstrappers:"
  auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress

secret 的类型必须是 bootstrap.kubernetes.io/token，名称必须是 bootstrap-token-<token id>。它还必须存在于 kube-system 命名空间中。

usage-bootstrap-* 成员表示此 secret 的预期用途。必须将值设置为 true 才能启用。

• usage-bootstrap-authentication 表示此令牌可以用作持有者令牌对 API Server 进行认证。
• usage-bootstrap-signing 表示此令牌可用于签名 cluster-info ConfigMap，如下所述。

expiration 字段控制令牌的过期时间。过期令牌在用于认证时会被拒绝，在 ConfigMap 签名过程中会被忽略。过期值使用 RFC3339 编码为绝对 UTC 时间。启用 tokencleaner 控制器可以自动删除过期令牌。

使用 kubeadm 管理令牌

你可以使用 kubeadm 工具管理运行中集群上的令牌。有关详细信息，请参阅kubeadm token 文档。

ConfigMap 签名

除了认证之外，令牌还可以用于签名 ConfigMap。这在客户端信任 API Server 之前，集群引导过程的早期阶段中使用。签名的 ConfigMap 可以通过共享令牌进行认证。

通过在 Controller Manager 上启用 bootstrapsigner 控制器来启用 ConfigMap 签名。

--controllers=*,bootstrapsigner

被签名的 ConfigMap 是位于 kube-public 命名空间中的 cluster-info。典型流程是客户端在未认证且忽略 TLS 错误的情况下读取此 ConfigMap。然后，通过查看嵌入在 ConfigMap 中的签名来验证 ConfigMap 的负载。

ConfigMap 可能看起来像这样

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-info
  namespace: kube-public
data:
  jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
  kubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: <really long certificate data>
        server: https://10.138.0.2:6443
      name: ""
    contexts: []
    current-context: ""
    kind: Config
    preferences: {}
    users: []    

ConfigMap 的 kubeconfig 成员是一个只填充了集群信息的配置文件。此处传达的关键信息是 certificate-authority-data。将来可能会进行扩展。

签名是使用“分离”模式的 JWS 签名。为了验证签名，用户应根据 JWS 规则（进行 base64 编码，同时丢弃任何末尾的 =）对 kubeconfig 负载进行编码。然后，将该编码后的负载插入到两个点之间，以形成一个完整的 JWS。你可以使用 HS256 方案 (HMAC-SHA256)，并使用完整令牌（例如 07401b.f395accd246ae52d）作为共享秘密来验证 JWS。用户**必须**验证是否使用了 HS256。

有关更多信息，请参阅kubeadm 实现细节部分。