304 lines
12 KiB
Markdown
304 lines
12 KiB
Markdown
---
|
||
title: 使用启动引导令牌（Bootstrap Tokens）认证
|
||
weight: 20
|
||
---
|
||
|
||
<!--
|
||
reviewers:
|
||
- jbeda
|
||
title: Authenticating with Bootstrap Tokens
|
||
content_type: concept
|
||
weight: 20
|
||
-->
|
||
|
||
<!-- overview -->
|
||
|
||
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
|
||
|
||
<!--
|
||
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/), 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.
|
||
-->
|
||
启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群
|
||
或者在现有集群中添加新节点时使用的。
|
||
它被设计成能够支持 [`kubeadm`](/zh/docs/reference/setup-tools/kubeadm/)，
|
||
但是也可以被用在其他的案例中以便用户在不使用 `kubeadm` 的情况下启动集群。
|
||
它也被设计成可以通过 RBAC 策略，结合
|
||
[Kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||
系统进行工作。
|
||
|
||
<!-- body -->
|
||
<!--
|
||
## Bootstrap Tokens Overview
|
||
|
||
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.
|
||
-->
|
||
启动引导令牌被定义成一个特定类型的 Secret （`bootstrap.kubernetes.io/token`），
|
||
并存在于 `kube-system` 名字空间中。
|
||
这些 Secret 会被 API 服务器上的启动引导认证组件（Bootstrap Authenticator）读取。
|
||
控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。
|
||
这些令牌也被用来在节点发现的过程中会使用的一个特殊的 ConfigMap 对象。
|
||
BootstrapSigner 控制器也会使用这一 ConfigMap。
|
||
|
||
<!--
|
||
## Token Format
|
||
|
||
Bootstrap Tokens take the form of `abcdef.0123456789abcdef`. More formally,
|
||
they must match the regular expression `[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.
|
||
-->
|
||
## 令牌格式
|
||
|
||
启动引导令牌使用 `abcdef.0123456789abcdef` 的形式。
|
||
更加规范地说，它们必须符合正则表达式 `[a-z0-9]{6}\.[a-z0-9]{16}`。
|
||
|
||
令牌的第一部分是 "Token ID"，它是一种公开信息，用于引用令牌并确保不会
|
||
泄露认证所使用的秘密信息。
|
||
第二部分是"令牌秘密（Token Secret）"，它应该被共享给受信的第三方。
|
||
|
||
## 启用启动引导令牌
|
||
|
||
<!--
|
||
## Enabling Bootstrap Token Authentication
|
||
|
||
The Bootstrap Token authenticator can be enabled using the following flag on the
|
||
API server:
|
||
-->
|
||
## 启用启动引导令牌身份认证 {#enabling-bootstrap-token-authentication}
|
||
|
||
启动引导令牌认证组件可以通过 API 服务器上的如下标志启用：
|
||
|
||
```
|
||
--enable-bootstrap-token-auth
|
||
```
|
||
|
||
<!--
|
||
When enabled, bootstrapping tokens can be used as bearer token credentials to
|
||
authenticate requests against the API server.
|
||
-->
|
||
启动引导令牌被启用后，可以作为持有者令牌的凭据，用于 API 服务器请求的身份认证。
|
||
|
||
```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.
|
||
|
||
Expired tokens can be deleted automatically by enabling the `tokencleaner`
|
||
controller on the controller manager.
|
||
-->
|
||
令牌认证为用户名 `system:bootstrap:<token id>` 并且是组 `system:bootstrappers`
|
||
的成员。额外的组信息可以通过令牌的 Secret 来设置。
|
||
|
||
过期的令牌可以通过启用控制器管理器中的 `tokencleaner` 控制器来删除。
|
||
|
||
<!--
|
||
## Bootstrap Token Secret Format
|
||
|
||
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).
|
||
|
||
Here is what the secret looks like.
|
||
-->
|
||
## 启动引导令牌的 Secret 格式 {#bootstrap-token-secret-format}
|
||
|
||
每个合法的令牌背后对应着 `kube-system` 名字空间中的某个 Secret 对象。
|
||
你可以从
|
||
[这里](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
|
||
找到完整设计文档。
|
||
|
||
这是 Secret 看起来的样子。
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Secret
|
||
metadata:
|
||
# name 必须是 "bootstrap-token-<token id>" 格式的
|
||
name: bootstrap-token-07401b
|
||
namespace: kube-system
|
||
|
||
# type 必须是 'bootstrap.kubernetes.io/token'
|
||
type: bootstrap.kubernetes.io/token
|
||
stringData:
|
||
# 供人阅读的描述，可选。
|
||
description: "The default bootstrap token generated by 'kubeadm init'."
|
||
|
||
# 令牌 ID 和秘密信息，必需。
|
||
token-id: 07401b
|
||
token-secret: base64(f395accd246ae52d)
|
||
|
||
# 可选的过期时间字段
|
||
expiration: "2017-03-10T03:22:11Z"
|
||
# 允许的用法
|
||
usage-bootstrap-authentication: "true"
|
||
usage-bootstrap-signing: "true"
|
||
|
||
# 令牌要认证为的额外组，必须以 "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.
|
||
|
||
The `usage-bootstrap-*` members indicate what this secret is intended to be used
|
||
for. A value must be set to `true` to be enabled.
|
||
-->
|
||
Secret 的类型必须是 `bootstrap.kubernetes.io/token`，而且名字必须是 `bootstrap-token-<token id>`。
|
||
令牌必须存在于 `kube-system` 名字空间中。
|
||
|
||
`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-signing` indicates that the token may be used to sign the
|
||
`cluster-info` ConfigMap as described below.
|
||
-->
|
||
* `usage-bootstrap-authentication` 表示令牌可以作为持有者令牌用于 API 服务器的身份认证。
|
||
* `usage-bootstrap-signing` 表示令牌可被用于 `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` 字段控制令牌的失效期。过期的令牌在用于身份认证时会被拒绝，在用于
|
||
ConfigMap 签名时会被忽略。
|
||
过期时间值是遵循 RFC3339 进行编码的 UTC 时间。
|
||
启用 TokenCleaner 控制器会自动删除过期的令牌。
|
||
|
||
<!--
|
||
## Token Management with kubeadm
|
||
|
||
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-management-with-kubeadm}
|
||
|
||
你可以使用 `kubeadm` 工具管理运行中集群上的令牌。
|
||
参见 [kubeadm token 文档](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/)
|
||
以了解详细信息。
|
||
|
||
<!--
|
||
## ConfigMap Signing
|
||
|
||
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.
|
||
|
||
Enable ConfigMap signing by enabling the `bootstrapsigner` controller on the
|
||
Controller Manager.
|
||
-->
|
||
### ConfigMap 签名 {#configmap-signing}
|
||
|
||
除了身份认证，令牌还可以用于签名 ConfigMap。
|
||
这一用法发生在集群启动过程的早期，在客户端信任 API 服务器之前。
|
||
被签名的 ConfigMap 可以被共享令牌完成身份认证。
|
||
|
||
通过在控制器管理器上启用 `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.
|
||
|
||
The ConfigMap may look like this:
|
||
-->
|
||
被签名的 ConfigMap 是 `kube-public` 名字空间中的 `cluster-info`。
|
||
典型的工作流中，客户端在未经认证和忽略 TLS 报错的状态下读取这个 ConfigMap。
|
||
通过检查 ConfigMap 中嵌入的签名校验 ConfigMap 的载荷。
|
||
|
||
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: <非常长的证书数据>
|
||
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.
|
||
-->
|
||
签名是一个使用 "detached" 模式生成的 JWS 签名。
|
||
为了检验签名，用户应该按照 JWS 规则（base64 编码且丢掉结尾的 `=`）对
|
||
`kubeconfig` 的载荷进行编码。完成编码的载荷会被插入到两个句点中间，形成完整的
|
||
JWS。你可以使用完整的令牌（比如 `07401b.f395accd246ae52d`）作为共享密钥，
|
||
通过 `HS256` 方式 (HMAC-SHA256) 对 JWS 进行校验。
|
||
用户 _必须_ 确保使用了 HS256。
|
||
|
||
{{< 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.
|
||
-->
|
||
任何拥有了启动引导令牌的主体都可以为该令牌生成一个合法的签名。
|
||
当使用 ConfigMap 签名时，非常不建议针对很多客户使用相同的令牌，因为某个被攻击的
|
||
客户可能对另一个一来签名来开启 TLS 信任的客户发起中间人攻击。
|
||
{{< /warning >}}
|
||
|
||
<!--
|
||
Consult the [kubeadm implementation details](/docs/reference/setup-tools/kubeadm/implementation-details/)
|
||
section for more information.
|
||
-->
|
||
参考 [kubeadm 实现细节](/zh/docs/reference/setup-tools/kubeadm/implementation-details/)
|
||
了解更多信息。
|
||
|