使用启动引导令牌（Bootstrap Tokens）认证

    启动引导令牌被定义成一个特定类型的 secrets(bootstrap.kubernetes.io/token)，并存在于 kube-system 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。 控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。在节点发现的过程中 Kubernetes 会使用特殊的 ConfigMap 对象。 控制器管理器中的 BootstrapSigner 控制器也会使用启动引导令牌为这类对象生成签名信息。

    目前，启动引导令牌处于 alpha 阶段，但是预期也不会有大的突破性变化。

    启动引导令牌使用 abcdef.0123456789abcdef 的形式。 更加规范地说，它们必须符合正则表达式 [a-z0-9]{6}\.[a-z0-9]{16}。

    令牌的第一部分是 “Token ID” ，它是公共信息。用于引用某个令牌，并确保不会泄露认证所使用的秘密信息。 第二部分是“令牌秘密（Token Secret）”，它应该被共享给收信的第三方。

    所有与启动引导令牌相关的特性在 Kubernetes v1.6 版本中默认都是禁用的。

    你可以在 API 服务器上通过 --enable-bootstrap-token-auth 参数启用启动引导令牌。 你可以设置控制管理器的 --controllers 参数来启用启动引导令牌相关的控制器，例如 --controllers=*,tokencleaner,bootstrapsigner 。 在使用 kubeadm 时，这是自动完成的。

    每个合法的令牌背后对应着 kube-system 命名空间中的某个 Secret 对象。 你可以从 这里 找到完整设计文档。

    这是 secret 看起来的样子。注意，base64(string) 表示应该通过 base64 对值进行编码。 这里使用的是未解码的版本以便于阅读。

    secret 的类型必须是 bootstrap.kubernetes.io/token ，而且名字必须是 。 description 是人类可读的描述，而不应该是机器可读的信息。令牌 ID 和 Secret 是包含在数据字典中的。

    usage-bootstrap-* 成员表示这个 secret 的用途。启用时，值必须设置为 true。

    usage-bootstrap-authentication 表示令牌可以用于 API 服务器的认证。认证器会以 system:bootstrap:<Token ID> 认证。它被包含在 system:bootstrappers 组中。 命名和组是故意受限制的，以防止用户在启动引导后再使用这些令牌。

    usage-bootstrap-signing 表示令牌应该被用于 cluster-info ConfigMap 的签名，就像下面描述的那样。

    你可以使用 kubeadm 工具管理正在运行集群的令牌。它会从 kubeadm 创建的集群（/etc/kubernetes/admin.conf） 自动抓取默认管理员密码。你可以通过参数 --kubeconfig 对下面命令指定一个另外的 kubeconfig 文件抓取密码。

    • 列举了令牌，同时显示了它们的过期时间和用途。
    • kubeadm token create 创建一个新令牌。
      • --description 设置新令牌的描述。
      • --ttl duration 设置令牌从“现在”起到过期时间的差值。 默认是 0 ，也就是不过期。
    • kubeadm token delete <token id>|<token id>.<token secret> 删除令牌。 令牌可以只用 ID 来确认，也可以用整个令牌的值。如果只用 ID 的情况下，密文不匹配的令牌也会被删除。

    除了认证之外，令牌可以用于签名 ConfigMap。这在集群启动过程的早期，在客户端信任 API 服务器之前被使用。 被签名的 ConfigMap 可以通过共享令牌被认证。

    被签名的 ConfigMap 是 cluster-info，存在于 kube-public 命名空间中。 典型的工作流中，客户端在未经认证和忽略 TLS 报错的状态下读取这个 ConfigMap。 通过 ConfigMap 中嵌入的签名校验 ConfigMap 的载荷。

    ConfigMap 会是这个样子的：

    ConfigMap 的 kubeconfig 成员是一个填好了集群信息的配置文件。 这里主要交换的信息是 certificate-authority-data。在将来可能会有扩展。

    签名是一个 JWS 签名，使用了 “detached” 模式。为了检验签名，用户应该按照 JWS 规则 （base64 编码而忽略结尾的 =）对 kubeconfig 的载荷进行编码。完成编码的载荷会被通过插入 JWS 并存在于两个点的中间 ，用于形成一个完整的 JWS。可以使用令牌的完整信息（比如 07401b.f395accd246ae52d）作为共享密钥， 通过 方式 (HMAC-SHA256) 对 JWS 进行校验。 用户 必须 确保使用了 HS256。