使用启动引导令牌(Bootstrap Tokens)认证

    启动引导令牌是一种简单的持有者令牌(Bearer Token),这种令牌是在新建集群 或者在现有集群中添加新节点时使用的。 它被设计成能够支持 kubeadm, 但是也可以被用在其他的案例中以便用户在不使用 kubeadm 的情况下启动集群。 它也被设计成可以通过 RBAC 策略,结合 系统进行工作。

    启动引导令牌被定义成一个特定类型的 Secret (bootstrap.kubernetes.io/token), 并存在于 kube-system 名字空间中。 这些 Secret 会被 API 服务器上的启动引导认证组件(Bootstrap Authenticator)读取。 控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。 这些令牌也被用来在节点发现的过程中会使用的一个特殊的 ConfigMap 对象。 BootstrapSigner 控制器也会使用这一 ConfigMap。

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

    令牌的第一部分是 “Token ID”,它是一种公开信息,用于引用令牌并确保不会 泄露认证所使用的秘密信息。 第二部分是”令牌秘密(Token Secret)”,它应该被共享给受信的第三方。

    启动引导令牌认证组件可以通过 API 服务器上的如下标志启用:

    启动引导令牌被启用后,可以作为持有者令牌的凭据,用于 API 服务器请求的身份认证。

    令牌认证为用户名 system:bootstrap:<token id> 并且是组 system:bootstrappers 的成员。额外的组信息可以通过令牌的 Secret 来设置。

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

    这是 Secret 看起来的样子。

    Secret 的类型必须是 bootstrap.kubernetes.io/token,而且名字必须是 bootstrap-token-<token id>。 令牌必须存在于 kube-system 名字空间中。

    usage-bootstrap-* 成员表明这个 Secret 的用途。启用时,值必须设置为 true

    • usage-bootstrap-authentication 表示令牌可以作为持有者令牌用于 API 服务器的身份认证。
    • usage-bootstrap-signing 表示令牌可被用于 cluster-info ConfigMap 的签名, 就像下面描述的那样。

    字段控制令牌的失效期。过期的令牌在用于身份认证时会被拒绝,在用于 ConfigMap 签名时会被忽略。 过期时间值是遵循 RFC3339 进行编码的 UTC 时间。 启用 TokenCleaner 控制器会自动删除过期的令牌。

    你可以使用 kubeadm 工具管理运行中集群上的令牌。 参见 以了解详细信息。

    除了身份认证,令牌还可以用于签名 ConfigMap。 这一用法发生在集群启动过程的早期,在客户端信任 API 服务器之前。 被签名的 ConfigMap 可以被共享令牌完成身份认证。

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

    ConfigMap 会是这个样子的:

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

    签名是一个使用 “detached” 模式生成的 JWS 签名。 为了检验签名,用户应该按照 JWS 规则(base64 编码且丢掉结尾的 =)对 kubeconfig 的载荷进行编码。完成编码的载荷会被插入到两个句点中间,形成完整的 JWS。你可以使用完整的令牌(比如 )作为共享密钥, 通过 HS256 方式 (HMAC-SHA256) 对 JWS 进行校验。 用户 必须 确保使用了 HS256。

    参考 kubeadm 实现细节 了解更多信息。