使用 Bootstrap Token 进行身份验证

Bootstrap Token 是一种简单的 Bearer Token，旨在用于创建新集群或将新节点加入现有集群。它最初是为 kubeadm 构建的，但也可以用于其他上下文，供希望在没有 kubeadm 的情况下启动集群的用户使用。它还构建为通过 RBAC 策略与 kubelet TLS Bootstrapping 系统一起工作。

Bootstrap Token 概述

Bootstrap Token 使用特定类型 (bootstrap.kubernetes.io/token) 的 Secret 定义，这些 Secret 位于 kube-system 命名空间中。然后，API Server 中的 Bootstrap Authenticator 读取这些 Secret。过期的 Token 会被 Controller Manager 中的 TokenCleaner Controller 删除。这些 Token 还用于为 BootstrapSigner Controller 中的 ConfigMap 创建签名，用于“发现”过程。

Token 格式

Bootstrap Token 采用 abcdef.0123456789abcdef 的形式。更正式地说，它们必须匹配正则表达式 [a-z0-9]{6}\.[a-z0-9]{16}。

Token 的第一部分是“Token ID”，被认为是公共信息。在不泄露用于身份验证的 Secret 部分的情况下引用 Token 时使用它。第二部分是“Token Secret”，应仅与受信任方共享。

启用 Bootstrap Token 身份验证

可以使用 API 服务器上的以下标志启用 Bootstrap Token 身份验证器

--enable-bootstrap-token-auth

启用后，可以将 Bootstrap Token 作为 Bearer Token 凭据用于对 API 服务器进行身份验证。

Authorization: Bearer 07401b.f395accd246ae52d

Token 身份验证为用户名 system:bootstrap:<token id>，并且是 system:bootstrappers 组的成员。可以在 Token 的 Secret 中指定其他组。

可以通过在 Controller Manager 上启用 tokencleaner Controller 来自动删除过期的 Token。

--controllers=*,tokencleaner

Bootstrap Token Secret 格式

每个有效的 Token 都有一个位于 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 指示可以使用 Token 作为 Bearer Token 对 API 服务器进行身份验证。
• usage-bootstrap-signing 指示可以使用 Token 签署如下所述的 cluster-info ConfigMap。

expiration 字段控制 Token 的过期时间。在用于身份验证时，过期的 Token 会被拒绝，并在 ConfigMap 签名期间被忽略。过期值编码为绝对 UTC 时间，使用 RFC3339。启用 tokencleaner Controller 以自动删除过期的 Token。

使用 kubeadm 管理 Token

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

ConfigMap 签名

除了身份验证之外，还可以使用 Token 签署 ConfigMap。这在集群引导过程的早期使用，在客户端信任 API 服务器之前。共享 Token 可以对 ConfigMap 进行身份验证。

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

--controllers=*,bootstrapsigner

签名的 ConfigMap 是 kube-public 命名空间中的 cluster-info。典型的流程是客户端在未经验证的情况下读取此 ConfigMap 并忽略 TLS 错误。然后，它通过查看嵌入在 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 规则对 kubeconfig 有效负载进行编码（base64 编码，同时丢弃任何尾随的 =）。然后，将该编码的有效负载插入到 2 个点之间以形成完整的 JWS。可以使用 HS256 方案（HMAC-SHA256）使用完整的 Token（例如，07401b.f395accd246ae52d）作为共享密钥来验证 JWS。用户必须验证是否使用了 HS256。

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