zh-trans content/en/docs/reference/access-authn-authz/bootstrap-tokens.md (#11151)

* Create bootstrap-tokens.md * Update bootstrap-tokens.md 英文改放在中文前面 * Update bootstrap-tokens.md * Update bootstrap-tokens.md * Update bootstrap-tokens.md * Update bootstrap-tokens.md * Update bootstrap-tokens.md
2018-11-22 17:24:43 +08:00
parent fa5524005b
commit 2a763c35bc
1 changed files with 296 additions and 0 deletions
@@ -0,0 +1,296 @@
+---
+reviewers:
+- jbeda
+title: 使用 Bootstrap Token 进行鉴权
+content_template: templates/concept
+weight: 20
+---
+<!-- 
+---
+reviewers:
+- jbeda
+title: Authenticating with Bootstrap Tokens
+content_template: templates/concept
+weight: 20
+--- 
+-->
+
+{{% capture overview %}}
+<!-- 
+Bootstrap tokens are a simple bearer token that is meant to be used when
+creating new clusters or joining new nodes to an existing cluster.  It was built
+to support [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), but can be used in other contexts
+for users that wish to start clusters without `kubeadm`. It is also built to
+work, via RBAC policy, with the [Kubelet TLS
+Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system. 
+-->
+Bootstrap token 是一种简单的 bearer token，用于创建新集群或将新节点连接到现有集群。它被用来支持 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)，但是对于那些希望在没有 `kubeadm` 的情况下创建集群的用户，也可以在其他环境中使用。它也可以通过 RBAC 策略用于 [Kubelet TLS
+Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 系统。
+{{% /capture %}}
+
+{{% capture body %}}
+<!-- 
+## Bootstrap Tokens Overview 
+-->
+## Bootstrap Token 概览
+
+<!-- 
+Bootstrap Tokens are defined with a specific type
+(`bootstrap.kubernetes.io/token`) of secrets that lives in the `kube-system`
+namespace.  These Secrets are then read by the Bootstrap Authenticator in the
+API Server.  Expired tokens are removed with the TokenCleaner controller in the
+Controller Manager.  The tokens are also used to create a signature for a
+specific ConfigMap used in a "discovery" process through a BootstrapSigner
+controller. 
+-->
+Bootstrap Token 在 `kube-system` 命名空间中使用特定类型 (`bootstrap.kubernetes.io/token`) 的 secret 来定义。
+然后，这些 Secret 被 API Server 中的 Bootstrap Authenticator 读取。过期的 token 被 Controller Manager 中的 TokenCleaner 控制器移除。
+这些 Token 也被 BootstrapSigner 控制器在一个"发现"的过程中用来为特定的 ConfigMap 创建签名。 
+
+{{< feature-state state="beta" >}}
+
+<!-- 
+## Token Format 
+-->
+## Token 格式
+
+<!-- 
+Bootstrap Tokens take the form of `abcdef.0123456789abcdef`.  More formally,
+they must match the regular expression `[a-z0-9]{6}\.[a-z0-9]{16}`. 
+-->
+Bootstrap Token 采用 `abcdef.0123456789abcdef` 的形式。为了更加正式，它们必须匹配正则表达式 `[a-z0-9]{6}\.[a-z0-9]{16}`。
+
+<!--
+The first part of the token is the "Token ID" and is considered public
+information.  It is used when referring to a token without leaking the secret
+part used for authentication. The second part is the "Token Secret" and should
+only be shared with trusted parties.
+-->
+Token 的第一部分是 "Token ID" 并且被认为是公共信息。这部分会在引用一个 token 但是不想泄露那些用于鉴权的私密部分时被用到。第二部分则是 "Token Secret"，应该仅与受信任方共享。
+
+<!-- 
+## Enabling Bootstrap Token Authentication
+-->
+## 启用 Bootstrap Token 鉴权
+
+<!-- 
+The Bootstrap Token authenticator can be enabled using the following flag on the
+API server: 
+-->
+Bootstrap Token authenticator 可以通过在 API server 上添加下列标志来启用。
+
+```
+--enable-bootstrap-token-auth
+```
+
+<!-- 
+When enabled, bootstrapping tokens can be used as bearer token credentials to
+authenticate requests against the API server. 
+-->
+被启用时，Bootstrap Token 可以被用来作为针对 API server 鉴权请求的 bearer token 凭据。
+
+```http
+Authorization: Bearer 07401b.f395accd246ae52d
+```
+
+<!-- 
+Tokens authenticate as the username `system:bootstrap:<token id>` and are members
+of the group `system:bootstrappers`.  Additional groups may be specified in the
+token's Secret. 
+-->
+Token 鉴权信息为：用户名 `system:bootstrap:<token id>` 且在 `system:bootstrappers` 组内。我们也可以在 token 的 Secret 中指定其它组信息。
+
+<!-- Expired tokens can be deleted automatically by enabling the `tokencleaner`
+controller on the controller manager. -->
+过期的 token 可以通过启用 controller manager 中的 `tokencleaner` 控制器来自动删除。
+
+```
+--controllers=*,tokencleaner
+```
+
+<!-- 
+## Bootstrap Token Secret Format 
+-->
+## Bootstrap Token Secret 格式
+
+<!-- 
+Each valid token is backed by a secret in the `kube-system` namespace.  You can
+find the full design doc
+[here](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md). 
+-->
+每个有效的 token 都对应着 `kube-system` 命名空间中的一个 secret。您可以从 [这里](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md) 获得整个的设计文档。
+
+<!-- 
+Here is what the secret looks like. 
+-->
+Secret 样例如下所示。
+
+```yaml
+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
+```
+
+<!-- 
+The type of the secret must be `bootstrap.kubernetes.io/token` and the name must
+be `bootstrap-token-<token id>`.  It must also exist in the `kube-system`
+namespace. 
+-->
+Secret 的类型必须是 `bootstrap.kubernetes.io/token` 并且名字的格式必须是 `bootstrap-token-<token id>`。它必须被放在 `kube-system` 命名空间中。
+
+<!-- 
+The `usage-bootstrap-*` members indicate what this secret is intended to be used
+for.  A value must be set to `true` to be enabled. 
+-->
+`usage-bootstrap-*` 的成员指出了这个 secret 的作用。值被设定为 `true` 时才会启用。
+
+<!-- * `usage-bootstrap-authentication` indicates that the token can be used to
+authenticate to the API server as a bearer token. -->
+* `usage-bootstrap-authentication` 表示这个 token 可以被用来作为针对 API server 鉴权请求的 bearer token 凭据。
+<!-- * `usage-bootstrap-signing` indicates that the token may be used to sign the
+`cluster-info` ConfigMap as described below. -->
+* `usage-bootstrap-signing` 表示这个 token 可以被用来对 `cluster-info` ConfigMap 通过下述方式来签名。
+
+<!-- 
+The `expiration` field controls the expiry of the token.  Expired tokens are
+rejected when used for authentication and ignored during ConfigMap signing. 
+The expiry value is encoded as an absolute UTC time using RFC3339.  Enable the
+`tokencleaner` controller to automatically delete expired tokens. 
+-->
+`expiration` 字段控制 token 的到期。过期的 token 会在用于身份验证时被拒绝，在 ConfigMap 签名时被忽略。
+使用 RFC3339 将过期时间编码为绝对 UTC 时间。启用 `tokencleaner` 控制器来自动删除过期的 token。
+
+<!-- 
+## Token Management with kubeadm 
+-->
+## 使用 kubeadm 管理 token
+
+<!-- 
+You can use the `kubeadm` tool to manage tokens on a running cluster. See the
+[kubeadm token docs](/docs/reference/setup-tools/kubeadm/kubeadm-token/) for details. 
+-->
+您可以在集群中使用 `kubeadm` 工具来管理 token。查阅 [kubeadm token 文档](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 获取更多信息。
+
+<!-- 
+## ConfigMap Signing 
+-->
+## ConfigMap 签名
+
+<!-- 
+In addition to authentication, the tokens can be used to sign a ConfigMap.  This
+is used early in a cluster bootstrap process before the client trusts the API
+server.  The signed ConfigMap can be authenticated by the shared token. 
+-->
+除了身份验证之外，token 还可用于对 ConfigMap 进行签名。
+这个用于在客户端和 API Server 互信之前，在集群引导过程的前期使用。
+签名的 ConfigMap 可以通过共享 token 进行身份鉴权。
+
+<!-- 
+Enable ConfigMap signing by enabling the `bootstrapsigner` controller on the
+Controller Manager. 
+-->
+通过启用 Controller Manager 中的 `bootstrapsigner` 控制器来启用 ConfigMap 签名选项。
+
+```
+--controllers=*,bootstrapsigner
+```
+
+<!-- 
+The ConfigMap that is signed is `cluster-info` in the `kube-public` namespace.
+The typical flow is that a client reads this ConfigMap while unauthenticated and
+ignoring TLS errors.  It then validates the payload of the ConfigMap by looking
+at a signature embedded in the ConfigMap. 
+-->
+被签名的 ConfigMap 作为 `kube-public` 命名空间中的 `cluster-info` 存在。
+典型的流程是客户端在未经身份验证和忽略 TLS 错误时读取此 ConfigMap。
+然后通过嵌入 ConfigMap 中的签名来校验 ConfigMap。
+
+<!-- 
+The ConfigMap may look like this: 
+-->
+ConfigMap 样例如下所示:
+
+```yaml
+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: []
+```
+
+<!-- 
+The `kubeconfig` member of the ConfigMap is a config file with just the cluster
+information filled out.  The key thing being communicated here is the
+`certificate-authority-data`.  This may be expanded in the future. 
+-->
+ConfigMap 的 `kubeconfig` 成员是一个配置文件，里面只填写了集群信息。
+在通信过程中的关键是 `certificate-authority-data`。这部分可能在将来会扩展。
+
+<!-- 
+The signature is a JWS signature using the "detached" mode.  To validate the
+signature, the user should encode the `kubeconfig` payload according to JWS
+rules (base64 encoded while discarding any trailing `=`).  That encoded payload
+is then used to form a whole JWS by inserting it between the 2 dots.  You can
+verify the JWS using the `HS256` scheme (HMAC-SHA256) with the full token (e.g.
+`07401b.f395accd246ae52d`) as the shared secret.  Users _must_ verify that HS256
+is used. 
+-->
+签名是使用“分离”模式的 JWS 签名。
+为了验证签名，用户应该根据 JWS 规则加密 `kubeconfig`的信息（base64 编码，同时丢弃任何的 `=`）。
+然后将使用该编码的信息插入 2 个点之间来形成整个 JWS。
+您可以使用 `HS256` 方案（HMAC-SHA256）验证 JWS，并使用完整令牌（例如 `07401b.f395accd246ae52d`）作为共享密钥。 用户_必须_验证 HS256 是否被使用。
+
+{{< warning >}}
+<!-- 
+**Warning:** Any party with a bootstrapping token can create a valid signature for that
+token. When using ConfigMap signing it's discouraged to share the same token with
+many clients, since a compromised client can potentially man-in-the middle another
+client relying on the signature to bootstrap TLS trust. 
+-->
+**注意:** 拥有 bootstrapping token 任何一方都可以为该 token 创建有效签名。
+当使用 ConfigMap 签名时，不建议许多客户端共享相同的 token，因为受入侵的客户端可能会作为中间人为其它客户端来引导 TLS 信任。
+{{< /warning >}}
+
+<!-- 
+Consult the [kubeadm security model](/docs/reference/generated/kubeadm/#security-model)
+section for more information. 
+-->
+参阅 [kubeadm 安全模型](/docs/reference/generated/kubeadm/#security-model) 获取更多信息。
+{{% /capture %}}