学习 Kubernetes 基础知识

参考

Kubernetes v1.13 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击 最新版本。

Edit This Page

使用 Bootstrap Token 进行鉴权

Bootstrap token 是一种简单的 bearer token，用于创建新集群或将新节点连接到现有集群。它被用来支持 kubeadm，但是对于那些希望在没有 kubeadm 的情况下创建集群的用户，也可以在其他环境中使用。它也可以通过 RBAC 策略用于 Kubelet TLS Bootstrapping 系统。

Bootstrap Token 概览

Bootstrap Token 在 kube-system 命名空间中使用特定类型 (bootstrap.kubernetes.io/token) 的 secret 来定义。 然后，这些 Secret 被 API Server 中的 Bootstrap Authenticator 读取。过期的 token 被 Controller Manager 中的 TokenCleaner 控制器移除。 这些 Token 也被 BootstrapSigner 控制器在一个”发现”的过程中用来为特定的 ConfigMap 创建签名。

FEATURE STATE: Kubernetes v1.13 beta
该功能目前处于 beta 状态，意味着：

  • 版本名称包含 beta （例如 v2beta3）。
  • 代码经过了充分测试，启用该功能被认为是安全的。默认情况下被启用。
  • 对整体功能的支持在未来不会被移除，尽管细节上可能会做更改。
  • 在后续的 beta 或稳定版本中，对象的模式、语义可能以不兼容的方式发生变化。当这种情况发生时，我们将提供迁移到下一个版本的说明。这可能需要删除、编辑和重建 API 对象，编辑过程可能需要一些思考。这可能导致依赖该功能的应用程序停机一段时间。
  • 建议仅在非业务关键场景使用该功能，因为在后续版本中可能会发生不兼容的更改。如果您有多个可以独立升级的集群，那么您可能可以放松这个限制。
  • 请尝试使用我们的 beta 版功能，并给出反馈！在它们退出 beta 测试阶段之后，我们将很难去做更多的更改。

Token 格式

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

Token 的第一部分是 “Token ID” 并且被认为是公共信息。这部分会在引用一个 token 但是不想泄露那些用于鉴权的私密部分时被用到。第二部分则是 “Token Secret”，应该仅与受信任方共享。

启用 Bootstrap Token 鉴权

Bootstrap Token authenticator 可以通过在 API server 上添加下列标志来启用。

--enable-bootstrap-token-auth

被启用时，Bootstrap Token 可以被用来作为针对 API server 鉴权请求的 bearer token 凭据。

Authorization: Bearer 07401b.f395accd246ae52d

Token 鉴权信息为：用户名 system:bootstrap:<token id> 且在 system:bootstrappers 组内。我们也可以在 token 的 Secret 中指定其它组信息。

过期的 token 可以通过启用 controller manager 中的 tokencleaner 控制器来自动删除。

--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 时才会启用。

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

使用 kubeadm 管理 token

您可以在集群中使用 kubeadm 工具来管理 token。查阅 kubeadm token 文档 获取更多信息。

ConfigMap 签名

除了身份验证之外，token 还可用于对 ConfigMap 进行签名。 这个用于在客户端和 API Server 互信之前，在集群引导过程的前期使用。 签名的 ConfigMap 可以通过共享 token 进行身份鉴权。

通过启用 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 规则加密 kubeconfig的信息（base64 编码，同时丢弃任何的 =）。 然后将使用该编码的信息插入 2 个点之间来形成整个 JWS。 您可以使用 HS256 方案（HMAC-SHA256）验证 JWS，并使用完整令牌（例如 07401b.f395accd246ae52d）作为共享密钥。 用户 必须 验证 HS256 是否被使用。

Warning:

注意: 拥有 bootstrapping token 任何一方都可以为该 token 创建有效签名。 当使用 ConfigMap 签名时，不建议许多客户端共享相同的 token，因为受入侵的客户端可能会作为中间人为其它客户端来引导 TLS 信任。

参阅 kubeadm 安全模型 获取更多信息。

反馈