kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

[zh] Sync English site changes for authentication ref 

Some changes are large because ... the original translator failed to
include the English source. I don't know why those PRs got merged in the
first place.
pull/25293/head
Qiming Teng 2020-11-28 22:57:30 +08:00
parent ec9bfbd16e
commit b8c9b2fa30
4 changed files with 672 additions and 279 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

84
content/zh/docs/reference/access-authn-authz/authentication.md
View File

@ -66,7 +66,7 @@ for more details about this.
使用证书中的 'subject' 的通用名称（Common Name）字段（例如，"/CN=bob"）来
确定用户名。接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对
某资源执行特定的操作。进一步的细节可参阅
[证书请求](/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
[证书请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)
下普通用户主题。
<!--
@ -182,7 +182,7 @@ For example, using the `openssl` command line tool to generate a certificate sig
例如，使用 `openssl` 命令行工具生成一个证书签名请求：
``` bash
```bash
openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"
```
@ -321,54 +321,15 @@ how to manage these tokens with `kubeadm`.
以了解关于启动引导令牌身份认证组件与控制器的更深入的信息，以及如何使用
`kubeadm` 来管理这些令牌。
<!--
### Static Password File
Basic authentication is enabled by passing the `-basic-auth-file=SOMEFILE`
option to API server. Currently, the basic auth credentials last indefinitely,
and the password cannot be changed without restarting API server. Note that basic
authentication is currently supported for convenience while we finish making the
more secure modes described above easier to use.
-->
### Static Password File
通过向 API 服务器传递 `--basic-auth-file=SOMEFILE` 选项可以启用基本的
身份认证。目前，基本身份认证所涉及的凭据信息会长期有效，并且在不重启 API
服务器的情况下无法改变用户的密码。
要注意的是，对基本身份认证的支持目前仅是出于方便性考虑。
与此同时我们正在增强前述的、更为安全的模式的易用性。
<!--
The basic auth file is a csv file with a minimum of 3 columns: password, user name, user id.
In Kubernetes version 1.6 and later, you can specify an optional fourth column containing
comma-separated group names. If you have more than one group, you must enclose the fourth
column value in double quotes ("). See the following example:
-->
基本身份认证数据文件是一个 CSV 文件，包含至少 3 列：密码、用户名和用户 ID。
在 Kuernetes 1.6 及后续版本中，你可以指定一个可选的第 4 列，在其中给出用逗号
分隔的用户组名。如果用户组名不止一个，你必须将第 4 列的值用双引号括起来。
参见下面的例子：
```conf
password,user,uid,"group1,group2,group3"
```
<!--
When using basic authentication from an http client, the API server expects an `Authorization` header
with a value of `Basic BASE64ENCODED(USER:PASSWORD)`.
-->
当在 HTTP 客户端使用基本身份认证机制时，API 服务器会期望看到名为
`Authorization` 的 HTTP 头部，其值形如 `Basic USER:PASSWORD的Base64编码字符串`
<!--
### Service Account Tokens
A service account is an automatically enabled authenticator that uses signed
bearer tokens to verify requests. The plugin takes two optional flags:
* `-service-account-key-file` A file containing a PEM encoded key for signing bearer tokens.
* `--service-account-key-file` A file containing a PEM encoded key for signing bearer tokens.
If unspecified, the API server's TLS private key will be used.
* `-service-account-lookup` If enabled, tokens which are deleted from the API will be revoked.
* `--service-account-lookup` If enabled, tokens which are deleted from the API will be revoked.
-->
### 服务账号令牌 {#service-account-tokens}
@ -555,7 +516,33 @@ is included in a request.
中的 `id_token`（而非 `access_token`）作为持有者令牌。
关于如何在请求中设置令牌，可参见[前文](#putting-a-bearer-token-in-a-request)。
![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg)
{{< mermaid >}}
sequenceDiagram
participant user as 用户
participant idp as 身份提供者
participant kube as Kubectl
participant api as API 服务器
user ->> idp: 1. 登录到 IdP
activate idp
idp -->> user: 2. 提供 access_token,<br>id_token, 和 refresh_token
deactivate idp
activate user
user ->> kube: 3. 调用 Kubectl 并<br>设置 --token 为 id_token<br>或者将令牌添加到 .kube/config
deactivate user
activate kube
kube ->> api: 4. Authorization: Bearer...
deactivate kube
activate api
api ->> api: 5. JWT 签名合法么？
api ->> api: 6. JWT 是否已过期？(iat+exp)
api ->> api: 7. 用户被授权了么？
api -->> kube: 8. 已授权：执行<br>操作并返回结果
deactivate api
activate kube
kube --x user: 9. 返回结果
deactivate kube
{{< /mermaid >}}
<!--
1. Login to your identity provider
@ -683,7 +670,7 @@ For an identity provider to work with Kubernetes it must:
3. 拥有由 CA 签名的证书（即使 CA 不是商业 CA 或者是自签名的 CA 也可以）
<!--
A note about requirement #3 above, requiring a CA signed certificate. If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed. This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation. If you don't have a CA handy, you can use [this script](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh) from the CoreOS team to create a simple CA and a signed certificate and key pair.
A note about requirement #3 above, requiring a CA signed certificate. If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed. This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation. If you don't have a CA handy, you can use [this script](https://github.com/dexidp/dex/blob/master/examples/k8s/gencert.sh) from the Dex team to create a simple CA and a signed certificate and key pair.
Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh) that generates SHA256 certs with a longer life and larger key size.
-->
关于上述第三条需求，即要求具备 CA 签名的证书，有一些额外的注意事项。
@ -691,8 +678,11 @@ Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSe
你必须对身份服务的 Web 服务器证书进行签名，签名所用证书的 `CA` 标志要设置为
`TRUE`，即使用的是自签名证书。这是因为 GoLang 的 TLS 客户端实现对证书验证
标准方面有非常严格的要求。如果你手头没有现成的 CA 证书，可以使用 CoreOS
团队所开发的[这个脚本](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh)来创建一个简单的 CA 和被签了名的证书与密钥对。
或者你也可以使用[这个类似的脚本](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)，生成一个合法期更长、密钥尺寸更大的 SHA256 证书。
团队所开发的[这个脚本](https://github.com/dexidp/dex/blob/master/examples/k8s/gencert.sh)
来创建一个简单的 CA 和被签了名的证书与密钥对。
或者你也可以使用
[这个类似的脚本](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)，
生成一个合法期更长、密钥尺寸更大的 SHA256 证书。
<!--
Setup instructions for specific systems:

330
content/zh/docs/reference/access-authn-authz/authorization.md
View File

@ -1,41 +1,49 @@
---
title: 鉴权概述
content_type: concept
weight: 60
---
<!--
reviewers:
- erictune
- lavalamp
- deads2k
- liggitt
cnapprove:
- fatalc
<!-- title: Authorization Overview -->
title: 授权概述
title: Authorization Overview
content_type: concept
weight: 60
---
-->
<!-- overview -->
<!-- Learn more about Kubernetes authorization, including details about creating
policies using the supported authorization modules. -->
了解有关 Kubernetes 授权的更多信息，包括使用支持的授权模块创建策略的详细信息。
<!--
Learn more about Kubernetes authorization, including details about creating
policies using the supported authorization modules.
-->
了解有关 Kubernetes 鉴权的更多信息，包括使用支持的鉴权模块创建策略的详细信息。
<!-- body -->
<!-- In Kubernetes, you must be authenticated (logged in) before your request can be
<!--
In Kubernetes, you must be authenticated (logged in) before your request can be
authorized (granted permission to access). For information about authentication,
see [Accessing Control Overview](/docs/reference/access-authn-authz/controlling-access/).
see [Accessing Control Overview](/docs/concepts/security/controlling-access/).
Kubernetes expects attributes that are common to REST API requests. This means
that Kubernetes authorization works with existing organization-wide or
cloud-provider-wide access control systems which may handle other APIs besides
the Kubernetes API. -->
the Kubernetes API.
-->
在 Kubernetes 中，你必须在鉴权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息，
请参阅[访问控制概述](/zh/docs/concepts/security/controlling-access/).
在 Kubernetes 中，您必须在授权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息，
请参阅 [访问控制概述](/zh/docs/reference/access-authn-authz/controlling-access/).
Kubernetes 期望 REST API 请求中常见的属性。
这意味着 Kubernetes 授权适用于现有的组织范围或云提供商范围的访问控制系统，
Kubernetes 期望请求中存在 REST API 常见的属性。
这意味着 Kubernetes 鉴权适用于现有的组织范围或云提供商范围的访问控制系统，
除了 Kubernetes API 之外，它还可以处理其他 API。
<!-- ## Determine Whether a Request is Allowed or Denied
<!--
## Determine Whether a Request is Allowed or Denied
Kubernetes authorizes API requests using the API server. It evaluates all of the
request attributes against all policies and allows or denies the request. All
parts of an API request must be allowed by some policy in order to proceed. This
@ -48,20 +56,26 @@ Controllers.)
When multiple authorization modules are configured, each is checked in sequence.
If any authorizer approves or denies a request, that decision is immediately
returned and no other authorizer is consulted. If all modules have no opinion on
the request, then the request is denied. A deny returns an HTTP status code 403. -->
the request, then the request is denied. A deny returns an HTTP status code 403.
-->
## 确定是允许还是拒绝请求
Kubernetes 使用 API ​​服务器授权 API 请求。它根据所有策略评估所有请求属性来决定允许或拒绝请求。
一个 API 请求的所有部分必须被某些策略允许才能继续。这意味着默认情况下拒绝权限。
（尽管 Kubernetes 使用 API ​​服务器，但是依赖于特定种类对象的特定字段的访问控制和策略由准入控制器处理。）
Kubernetes 使用 API 服务器对 API 请求进行鉴权。
它根据所有策略评估所有请求属性来决定允许或拒绝请求。
一个 API 请求的所有部分都必须被某些策略允许才能继续。
这意味着默认情况下拒绝权限。
配置多个授权模块时，将按顺序检查每个模块。
如果任何授权模块批准或拒绝请求，则立即返回该决定，并且不会与其他授权模块协商。
如果所有模块对请求没有意见，则拒绝该请求。一个拒绝响应返回 HTTP 状态代码 403 。
（尽管 Kubernetes 使用 API 服务器，但是依赖于特定对象种类的特定字段的访问控制
和策略由准入控制器处理。）
当系统配置了多个鉴权模块时，Kubernetes 将按顺序使用每个模块。
如果任何鉴权模块批准或拒绝请求，则立即返回该决定，并且不会与其他鉴权模块协商。
如果所有模块对请求没有意见，则拒绝该请求。
被拒绝响应返回 HTTP 状态代码 403。
<!--
## Review Your Request Attributes
Kubernetes reviews only the following API request attributes:
* **user** - The `user` string provided during authentication.
@ -74,30 +88,59 @@ Kubernetes reviews only the following API request attributes:
* **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
* **Subresource** - The subresource that is being accessed (for resource requests only).
* **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only).
* **API group** - The API group being accessed (for resource requests only). An empty string designates the [core API group](/docs/concepts/overview/kubernetes-api/).
* **API group** - The {{< glossary_tooltip text="API Group" term_id="api-group" >}} being accessed (for resource requests only). An empty string designates the _core_ [API group](/docs/reference/using-api/#api-groups).
-->
## 审查你的请求属性
## 审查您的请求属性
Kubernetes 仅审查以下 API 请求属性：
* **user** - 身份验证期间提供的 `user` 字符串。
* **group** - 经过身份验证的用户所属的组名列表。
* **extra** - 由身份验证层提供的任意字符串键到字符串值的映射。
* **API** - 指示请求是否针对 API 资源。
* **Request path** - 各种非资源端点的路径，如 `/api` 或 `/healthz`。
* **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete` 和 `deletecollection` 用于资源请求。要确定资源 API 端点的请求动词，请参阅[确定请求动词](/zh/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied)。
* **HTTP request verb** - HTTP 动词 `get`，`post`，`put` 和 `delete` 用于非资源请求。
* **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求） - 对于使用 `get`，`update`，`patch` 和 `delete` 动词的资源请求，您必须提供资源名称。
* **Subresource** - 正在访问的子资源（仅限资源请求）。
* **Namespace** - 正在访问的对象的名称空间（仅适用于命名空间资源请求）。
* **API group** - 正在访问的 API 组（仅限资源请求）。空字符串表示[核心 API 组](/zh/docs/concepts/overview/kubernetes-api/)。
* **用户** - 身份验证期间提供的 `user` 字符串。
* **组** - 经过身份验证的用户所属的组名列表。
* **额外信息** - 由身份验证层提供的任意字符串键到字符串值的映射。
* **API** - 指示请求是否针对 API 资源。
* **请求路径** - 各种非资源端点的路径，如 `/api` 或 `/healthz`。
* **API 请求动词** - API 动词 `get`、`list`、`create`、`update`、`patch`、`watch`、
`proxy`、`redirect`、`delete` 和 `deletecollection` 用于资源请求。
要确定资源 API 端点的请求动词，请参阅
[确定请求动词](#determine-the-request-verb)。
* **HTTP 请求动词** - HTTP 动词 `get`、`post`、`put` 和 `delete` 用于非资源请求。
* **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求）-
对于使用 `get`、`update`、`patch` 和 `delete` 动词的资源请求，你必须提供资源名称。
* **子资源** - 正在访问的子资源（仅限资源请求）。
* **名字空间** - 正在访问的对象的名称空间（仅适用于名字空间资源请求）。
* **API 组** - 正在访问的 {{< glossary_tooltip text="API 组" term_id="api-group" >}}
（仅限资源请求）。空字符串表示[核心 API 组](/zh/docs/reference/using-api/#api-groups)。
<!--
## Determine the Request Verb
**Non-resource requests**
Requests to endpoints other than `/api/v1/...` or `/apis/<group>/<version>/...`
are considered "non-resource requests", and use the lower-cased HTTP method of the request as the verb.
For example, a `GET` request to endpoints like `/api` or `/healthz` would use `get` as the verb.
-->
## 确定请求动词 {#determine-the-request-verb}
**非资源请求**
对于 `/api/v1/...` 或 `/apis/<group>/<version>/...` 之外的端点的请求被
视为“非资源请求（Non-Resource Requests）”，并使用该请求的 HTTP 方法的
小写形式作为其请求动词。
例如，对 `/api` 或 `/healthz` 这类端点的 `GET` 请求将使用 `get` 作为其动词。
<!--
**Resource requests**
To determine the request verb for a resource API endpoint, review the HTTP verb
used and whether or not the request acts on an individual resource or a
collection of resources:
-->
**资源请求**
要确定对资源 API 端点的请求动词，需要查看所使用的 HTTP 动词以及该请求是针对
单个资源还是一组资源：
<!--
HTTP verb | request verb
----------|---------------
POST | create
@ -105,50 +148,65 @@ GET, HEAD | get (for individual resources), list (for collections)
PUT | update
PATCH | patch
DELETE | delete (for individual resources), deletecollection (for collections)
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `policy` API group.
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization
of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
* [Authentication](/docs/reference/access-authn-authz/authentication/) layer checks for authorization of the `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
-->
## 确定请求动词
要确定资源 API 端点的请求谓词，请检查所使用的 HTTP 动词以及请求是否对单个资源或资源集合起作用：
HTTP 动词 | request 动词
HTTP 动词 | 请求动词
----------|---------------
POST | create
GET, HEAD | get (单个资源)，list (资源集合)
GET, HEAD | get （针对单个资源）、list（针对集合）
PUT | update
PATCH | patch
DELETE | delete (单个资源)，deletecollection (资源集合)
Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例如：
* [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/) 检查 `policy` API 组中 `podsecuritypolicies` 资源的 `use` 动词的授权。
* [RBAC](/zh/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 检查 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` 动词的授权。
* [认证](/zh/docs/reference/access-authn-authz/authentication/) layer 检查核心 API 组中 `users`，`groups` 和 `serviceaccounts` 的 `impersonate` 动词的授权，以及 `authentication.k8s.io` API 组中的 `userextras`。
DELETE | delete（针对单个资源）、deletecollection（针对集合）
<!--
## Authorization Modules
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)
* `use` verb on `podsecuritypolicies` resources in the `policy` API group.
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
* `bind` and `escalate` verbs on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
* [Authentication](/docs/reference/access-authn-authz/authentication/)
* `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
-->
Kubernetes 有时使用专门的动词以对额外的权限进行鉴权。例如：
* [PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/)
* `policy` API 组中 `podsecuritypolicies` 资源使用 `use` 动词
* [RBAC](/zh/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
* 对 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind`
和 `escalate` 动词
* [身份认证](/zh/docs/reference/access-authn-authz/authentication/)
* 对核心 API 组中 `users`、`groups` 和 `serviceaccounts` 以及 `authentication.k8s.io`
API 组中的 `userextras` 所使用的 `impersonate` 动词。
<!--
## Authorization Modules {#authorization-modules}
* **Node** - A special-purpose authorizer that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/reference/access-authn-authz/node/).
* **ABAC** - Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc). To learn more about using the ABAC mode, see [ABAC Mode](/docs/reference/access-authn-authz/abac/).
* **RBAC** - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see [RBAC Mode](/docs/reference/access-authn-authz/rbac/)
* When specified RBAC (Role-Based Access Control) uses the `rbac.authorization.k8s.io` API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.
* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
* **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/reference/access-authn-authz/webhook/).
-->
-->
## 鉴权模块 {#authorization-modules}
## 授权模块
* **Node** - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅[节点授权](/zh/docs/reference/access-authn-authz/node/).
* **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 [ABAC 模式](/zh/docs/reference/access-authn-authz/abac/)。
* **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 [RBAC 模式](/zh/docs/reference/access-authn-authz/rbac/)。
* 当指定的 RBAC（基于角色的访问控制）使用 `rbac.authorization.k8s.io` API 组来驱动授权决策时，允许管理员通过 Kubernetes API 动态配置权限策略。
* 要启用 RBAC，请使用 `--authorization-mode = RBAC` 启动 apiserver 。
* **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 [Webhook 模式](/zh/docs/reference/access-authn-authz/webhook/)。
* **Node** - 一个专用鉴权组件，根据调度到 kubelet 上运行的 Pod 为 kubelet 授予权限。
了解有关使用节点鉴权模式的更多信息，请参阅[节点鉴权](/zh/docs/reference/access-authn-authz/node/)。
* **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范型，通过使用将属性组合
在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性、资源属性、
对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅
[ABAC 模式](/zh/docs/reference/access-authn-authz/abac/)。
* **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对
计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，
例如查看、创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅
[RBAC 模式](/zh/docs/reference/access-authn-authz/rbac/)。
* 被启用之后，RBAC（基于角色的访问控制）使用 `rbac.authorization.k8s.io` API 组来
驱动鉴权决策，从而允许管理员通过 Kubernetes API 动态配置权限策略。
* 要启用 RBAC，请使用 `--authorization-mode = RBAC` 启动 API 服务器。
* **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST；
通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时
将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅
[Webhook 模式](/zh/docs/reference/access-authn-authz/webhook/)。
<!--
#### Checking API Access
@ -157,28 +215,41 @@ Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例
The command uses the `SelfSubjectAccessReview` API to determine if the current user can perform
a given action, and works regardless of the authorization mode used.
-->
#### 检查 API 访问 {#checking-api-access}
#### 检查 API 访问
`kubectl` 提供 `auth can-i` 子命令，用于快速查询 API 鉴权。
该命令使用 `SelfSubjectAccessReview` API 来确定当前用户是否可以执行给定操作，
无论使用何种鉴权模式该命令都可以工作。
`kubectl` 提供 `auth can-i` 子命令，用于快速查询 API 授权层。
该命令使用 `SelfSubjectAccessReview` API 来确定当前用户是否可以执行给定操作，并且无论使用何种授权模式都可以工作。
```bash
$ kubectl auth can-i create deployments --namespace dev
```shell
kubectl auth can-i create deployments --namespace dev
```
```
yes
$ kubectl auth can-i create deployments --namespace prod
```
```shell
kubectl auth can-i create deployments --namespace prod
```
```
no
```
<!--
Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation)
to determine what action other users can perform.
-->
管理员可以将此与[用户模拟](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation)结合使用，以确定其他用户可以执行的操作。
管理员可以将此与
[用户扮演](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation)
结合使用，以确定其他用户可以执行的操作。
```bash
$ kubectl auth can-i list secrets --namespace dev --as dave
kubectl auth can-i list secrets --namespace dev --as dave
```
```
no
```
<!--
`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which
exposes the API server authorization to external services. Other resources in
@ -191,18 +262,22 @@ this group include:
These APIs can be queried by creating normal Kubernetes resources, where the response "status"
field of the returned object is the result of the query.
-->
`SelfSubjectAccessReview` 是 `authorization.k8s.io` API 组的一部分，它将 API
服务器鉴权公开给外部服务。该组中的其他资源包括：
`SelfSubjectAccessReview` 是 `authorization.k8s.io` API 组的一部分，它将 API 服务器授权公开给外部服务。
该组中的其他资源包括：
* `SubjectAccessReview` - 对任意用户的访问进行评估，而不仅仅是当前用户。
当鉴权决策被委派给 API 服务器时很有用。例如，kubelet 和扩展 API 服务器使用
它来确定用户对自己的 API 的访问权限。
* `LocalSubjectAccessReview` - 与 `SubjectAccessReview` 类似，但仅限于特定的
名字空间。
* `SelfSubjectRulesReview` - 返回用户可在名字空间内执行的操作集的审阅。
用户可以快速汇总自己的访问权限，或者用于 UI 中的隐藏/显示动作。
* `SubjectAccessReview` - 访问任何用户的 Review ，而不仅仅是当前用户。用于将授权决策委派给 API 服务器。例如，kubelet 和扩展 API 服务器使用它来确定用户对自己的 API 的访问权限。
* `LocalSubjectAccessReview` - 与 `SubjectAccessReview` 类似，但仅限于特定的命名空间。
* `SelfSubjectRulesReview` - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限，或者用于 UI 中的隐藏/显示动作。
可以通过创建普通 Kubernetes 资源来查询这些 API ，其中返回对象的响应 “status” 字段是查询的结果。
可以通过创建普通的 Kubernetes 资源来查询这些 API，其中返回对象的响应 "status"
字段是查询的结果。
```bash
$ kubectl create -f - -o yaml << EOF
kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
@ -212,7 +287,14 @@ spec:
verb: create
namespace: dev
EOF
```
<!--
The generated `SelfSubjectAccessReview` is:
-->
生成的 `SelfSubjectAccessReview` 为：
```yaml
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
@ -235,32 +317,39 @@ You must include a flag in your policy to indicate which authorization module
your policies include:
The following flags can be used:
-->
## 为你的鉴权模块设置参数
你必须在策略中包含一个参数标志，以指明你的策略包含哪个鉴权模块：
可以使用的参数有：
<!--
* `--authorization-mode=ABAC` Attribute-Based Access Control (ABAC) mode allows you to configure policies using local files.
* `--authorization-mode=RBAC` Role-based access control (RBAC) mode allows you to create and store policies using the Kubernetes API.
* `--authorization-mode=Webhook` WebHook is an HTTP callback mode that allows you to manage authorization using a remote REST endpoint.
* `--authorization-mode=Node` Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
* `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing.
* `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests.
-->
* `--authorization-mode=ABAC` 基于属性的访问控制（ABAC）模式允许你
使用本地文件配置策略。
* `--authorization-mode=RBAC` 基于角色的访问控制（RBAC）模式允许你使用
Kubernetes API 创建和存储策略。
* `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式，允许你使用远程
REST 端点管理鉴权。
* `--authorization-mode=Node` 节点鉴权是一种特殊用途的鉴权模式，专门对
kubelet 发出的 API 请求执行鉴权。
* `--authorization-mode=AlwaysDeny` 该标志阻止所有请求。仅将此标志用于测试。
* `--authorization-mode=AlwaysAllow` 此标志允许所有请求。仅在你不需要 API 请求
的鉴权时才使用此标志。
<!--
You can choose more than one authorization module. Modules are checked in order
so an earlier module has higher priority to allow or deny a request.
-->
## 为您的授权模块应用参数
您必须在策略中包含一个参数标志，以指明您的策略包含哪个授权模块：
可以使用以下参数：
* `--authorization-mode=ABAC` 基于属性的访问控制（ABAC）模式允许您使用本地文件配置策略。
* `--authorization-mode=RBAC` 基于角色的访问控制（RBAC）模式允许您使用 Kubernetes API 创建和存储策略。
* `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式，允许您使用远程 REST 端点管理授权。
* `--authorization-mode=Node` 节点授权是一种特殊用途的授权模式，专门授权由 kubelet 发出的 API 请求。
* `--authorization-mode=AlwaysDeny` 该标志阻止所有请求。仅将此标志用于测试。
* `--authorization-mode=AlwaysAllow` 此标志允许所有请求。仅在您不需要 API 请求的授权时才使用此标志。
您可以选择多个授权模块。模块按顺序检查，以便较早的模块具有更高的优先级来允许或拒绝请求。
你可以选择多个鉴权模块。模块按顺序检查，以便较靠前的模块具有更高的优先级来允许
或拒绝请求。
<!--
## Privilege escalation via pod creation
@ -271,34 +360,37 @@ access their privileges within that namespace. They can create pods that access
secrets the user cannot themselves read, or that run under a service account
with different/greater permissions.
-->
## 通过 Pod 创建升级权限
## 通过创建 Pod 提升权限
能够在命名空间中创建 Pod 的用户可能会升级其在该命名空间内的权限。
他们可以创建在该命名空间内访问其权限的 Pod 。
他们可以创建用户无法自己读取 secret 的 Pod ，或者在具有不同/更高权限的服务帐户下运行的 Pod 。
能够在名字空间中创建 Pod 的用户可能会提升其在该名字空间内的权限。
他们可以创建在该名字空间内访问其权限的 Pod。
他们可以创建 Pod 访问用户自己无法读取的 Secret，或者在具有不同/更高权限的
服务帐户下运行的 Pod 。
{{< caution >}}
<!--
System administrators, use care when granting access to pod
creation. A user granted permission to create pods (or controllers that create
pods) in the namespace can: read all secrets in the namespace; read all config
maps in the namespace; and impersonate any service account in the namespace and
take any action the account could take. This applies regardless of authorization
mode.
System administrators, use care when granting access to pod creation. A user
granted permission to create pods (or controllers that create pods) in the
namespace can: read all secrets in the namespace; read all config maps in the
namespace; and impersonate any service account in the namespace and take any
action the account could take. This applies regardless of authorization mode.
-->
**注意：** 系统管理员在授予对 Pod 创建的访问权限时要小心。
授予在命名空间中创建 Pod（或创建 Pod 的控制器）的权限的用户可以：
读取命名空间中的所有 secret；读取命名空间中的所有 ConfigMap；
并模拟命名空间中的任何服务帐户并执行帐户可以执行的任何操作。
无论采用何种授权方式，这都适用。
系统管理员在授予对 Pod 创建的访问权限时要小心。
被授予在名字空间中创建 Pod（或创建 Pod 的控制器）的权限的用户可以：
读取名字空间中的所有 Secret；读取名字空间中的所有 ConfigMap；
并模拟名字空间中的任意服务账号并执行账号可以执行的任何操作。
无论采用何种鉴权方式，这都适用。
{{< /caution >}}
## {{% heading "whatsnext" %}}
<!--
* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/).
* To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
-->
* 要了解有关身份验证的更多信息，请参阅 **身份验证** [控制对 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)。
* 要了解有关准入控制的更多信息，请参阅 [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。
* 要了解有关身份验证的更多信息，请参阅
[控制对 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)
中的 **身份验证** 部分。
* 要了解有关准入控制的更多信息，请参阅
[使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。

289
content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md
View File

@ -1,107 +1,238 @@
---
approvers:
- jbeda
title: 使用启动引导令牌（Bootstrap Tokens）认证
weight: 20
---
{{< toc >}}
<!--
reviewers:
- jbeda
title: Authenticating with Bootstrap Tokens
content_type: concept
weight: 20
-->
## 概述
<!-- overview -->
启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群或者在现有集群中添加新节点时使用的。
它被设计成能够支持 [`kubeadm`](/zh/docs/reference/setup-tools/kubeadm/)，但是也可以被用在其他的案例中以便用户在
不使用 `kubeadm` 的情况下启动集群。它也被设计成可以通过 RBAC 策略，结合 [Kubelet TLS
Bootstrapping](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 系统进行工作。
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
启动引导令牌被定义成一个特定类型的 secrets(`bootstrap.kubernetes.io/token`)，并存在于
`kube-system` 命名空间中。然后这些 secrets 会被 API 服务器上的启动引导的认证器读取。
控制器管理器中的控制器 TokenCleaner 能够删除过期的令牌。在节点发现的过程中 Kubernetes 会使用特殊的 ConfigMap 对象。
控制器管理器中的 BootstrapSigner 控制器也会使用启动引导令牌为这类对象生成签名信息。
<!--
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/)
系统进行工作。
目前，启动引导令牌处于 **alpha** 阶段，但是预期也不会有大的突破性变化。
<!-- 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）”，它应该被共享给收信的第三方。
令牌的第一部分是 "Token ID"，它是一种公开信息，用于引用令牌并确保不会
泄露认证所使用的秘密信息。
第二部分是"令牌秘密（Token Secret）"，它应该被共享给受信的第三方。
## 启用启动引导令牌
所有与启动引导令牌相关的特性在 Kubernetes v1.6 版本中默认都是禁用的。
<!--
## Enabling Bootstrap Token Authentication
你可以在 API 服务器上通过 `--enable-bootstrap-token-auth` 参数启用启动引导令牌。
你可以设置控制管理器的 `--controllers` 参数来启用启动引导令牌相关的控制器，例如 `--controllers=*,tokencleaner,bootstrapsigner` 。
在使用 `kubeadm` 时，这是自动完成的。
The Bootstrap Token authenticator can be enabled using the following flag on the
API server:
-->
## 启用启动引导令牌身份认证 {#enabling-bootstrap-token-authentication}
HTTPS 调用中的令牌是这样使用的：
启动引导令牌认证组件可以通过 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 来设置。
每个合法的令牌背后对应着 `kube-system` 命名空间中的某个 Secret 对象。
你可以从 [这里](https://git.k8s.io/community/contributors/design-proposals/bootstrap-discovery.md) 找到完整设计文档。
过期的令牌可以通过启用控制器管理器中的 `tokencleaner` 控制器来删除。
这是 secret 看起来的样子。注意，`base64(string)` 表示应该通过 base64 对值进行编码。
这里使用的是未解码的版本以便于阅读。
<!--
## 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
data:
description: base64(The default bootstrap token generated by 'kubeadm init'.)
token-id: base64(07401b)
stringData:
# 供人阅读的描述，可选。
description: "The default bootstrap token generated by 'kubeadm init'."
# 令牌 ID 和秘密信息，必需。
token-id: 07401b
token-secret: base64(f395accd246ae52d)
expiration: base64(2017-03-10T03:22:11Z)
usage-bootstrap-authentication: base64(true)
usage-bootstrap-signing: base64(true)
# 可选的过期时间字段
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
```
secret 的类型必须是 `bootstrap.kubernetes.io/token` ，而且名字必须是 `bootstrap-token-<token id>`。
`description` 是人类可读的描述，而不应该是机器可读的信息。令牌 ID 和 Secret 是包含在数据字典中的。
<!--
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.
`usage-bootstrap-*` 成员表示这个 secret 的用途。启用时，值必须设置为 `true`。
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-authentication` 表示令牌可以用于 API 服务器的认证。认证器会以
`system:bootstrap:<Token ID>` 认证。它被包含在 `system:bootstrappers` 组中。
命名和组是故意受限制的，以防止用户在启动引导后再使用这些令牌。
`usage-bootstrap-*` 成员表明这个 Secret 的用途。启用时，值必须设置为 `true`。
`usage-bootstrap-signing` 表示令牌应该被用于 `cluster-info` ConfigMap 的签名，就像下面描述的那样。
<!--
* `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 的签名，
就像下面描述的那样。
`expiration` 数据成员显示了令牌在失效后到现在的时间。这是遵循 RFC3339 进行编码的 UTC 时间。
TokenCleaner 控制器会删除过期的令牌。
<!--
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 控制器会自动删除过期的令牌。
## 使用 `kubeadm` 管理令牌
<!--
## Token Management with kubeadm
你可以使用 `kubeadm` 工具管理正在运行集群的令牌。它会从 `kubeadm` 创建的集群（`/etc/kubernetes/admin.conf`）
自动抓取默认管理员密码。你可以通过参数 `--kubeconfig` 对下面命令指定一个另外的 kubeconfig 文件抓取密码。
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 token list` 列举了令牌，同时显示了它们的过期时间和用途。
* `kubeadm token create` 创建一个新令牌。
* `--description` 设置新令牌的描述。
* `--ttl duration` 设置令牌从“现在”起到过期时间的差值。
默认是 0 ，也就是不过期。
* `--usages` 设置令牌被使用的方式。默认是 `signing,authentication`。用途在上面已经描述。
* `kubeadm token delete <token id>|<token id>.<token secret>` 删除令牌。
令牌可以只用 ID 来确认，也可以用整个令牌的值。如果只用 ID 的情况下，密文不匹配的令牌也会被删除。
你可以使用 `kubeadm` 工具管理运行中集群上的令牌。
参见 [kubeadm token 文档](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/)
以了解详细信息。
### ConfigMap 签名
<!--
## ConfigMap Signing
除了认证之外，令牌可以用于签名 ConfigMap。这在集群启动过程的早期，在客户端信任 API 服务器之前被使用。
被签名的 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.
被签名的 ConfigMap 是 `cluster-info`，存在于 `kube-public` 命名空间中。
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 中嵌入的签名校验 ConfigMap 的载荷。
ConfigMap 会是这个样子的：
@ -117,7 +248,7 @@ data:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <really long certificate data>
certificate-authority-data: <非常长的证书数据>
server: https://10.138.0.2:6443
name: ""
contexts: []
@ -127,10 +258,46 @@ data:
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`。在将来可能会有扩展。
签名是一个 JWS 签名，使用了 "detached" 模式。为了检验签名，用户应该按照 JWS 规则
（base64 编码而忽略结尾的 `=`）对 `kubeconfig` 的载荷进行编码。完成编码的载荷会被通过插入 JWS 并存在于两个点的中间
，用于形成一个完整的 JWS。可以使用令牌的完整信息（比如 `07401b.f395accd246ae52d`）作为共享密钥，
通过 `HS256` 方式 (HMAC-SHA256) 对 JWS 进行校验。 用户 _必须_ 确保使用了 HS256。
<!--
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/)
了解更多信息。

248
content/zh/docs/reference/access-authn-authz/service-accounts-admin.md
View File

@ -1,76 +1,209 @@
---
approvers:
title: 管理 Service Accounts
content_type: concept
weight: 50
---
<!--
reviewers:
- bprashanth
- davidopp
- lavalamp
- liggitt
title: 管理 Service Accounts
---
title: Managing Service Accounts
content_type: concept
weight: 50
-->
*这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/zh/docs/tasks/configure-pod-container/configure-service-account/)中的信息。*
<!-- overview -->
<!--
This is a Cluster Administrator guide to service accounts. You should be familiar with
[configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/).
*对授权和用户账户的支持已在规划中，当前并不完备，为了更好地描述 service accounts，有时这些不完善的特性也会被提及。*
Support for authorization and user accounts is planned but incomplete. Sometimes
incomplete features are referred to in order to better describe service accounts.
-->
这是一篇针对服务账号的集群管理员指南。你应该熟悉
[配置 Kubernetes 服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)。
## 用户账户与服务账户
对鉴权和用户账号的支持已在规划中，当前并不完备。
为了更好地描述服务账号，有时这些不完善的特性也会被提及。
Kubernetes 区分用户账户和服务账户的概念主要基于以下原因：
<!-- body -->
- 用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。
- 用户账户是全局性的。 其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离，
服务账户是 namespace 隔离的。
- 通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。
- 对人员和服务账户审计所考虑的因素可能不同。
- 针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建，并且有 namespace 级别的名称，这种配置是很轻量的。
<!--
## User accounts versus service accounts
## 服务账户的自动化
Kubernetes distinguishes between the concept of a user account and a service account
for a number of reasons:
-->
## 用户账号与服务账号 {#user-accounts-versus-service-accounts}
三个独立组件协作完成服务账户相关的自动化 :
Kubernetes 区分用户账号和服务账号的概念，主要基于以下原因：
- 服务账户准入控制器（Service account admission controller）
- Token 控制器（Token controller）
- 服务账户控制器（Service account controller）
<!--
- User accounts are for humans. Service accounts are for processes, which run
in pods.
- User accounts are intended to be global. Names must be unique across all
namespaces of a cluster. Service accounts are namespaced.
- Typically, a cluster's user accounts might be synced from a corporate
database, where new user account creation requires special privileges and is
tied to complex business processes. Service account creation is intended to be
more lightweight, allowing cluster users to create service accounts for
specific tasks by following the principle of least privilege.
- Auditing considerations for humans and service accounts may differ.
- A config bundle for a complex system may include definition of various service
accounts for components of that system. Because service accounts can be created
without many constraints and have namespaced names, such config is portable.
-->
- 用户账号是针对人而言的。 服务账号是针对运行在 Pod 中的进程而言的。
- 用户账号是全局性的。其名称跨集群中名字空间唯一的。服务账号是名字空间作用域的。
- 通常情况下，集群的用户账号可能会从企业数据库进行同步，其创建需要特殊权限，
并且涉及到复杂的业务流程。
服务账号创建有意做得更轻量，允许集群用户为了具体的任务创建服务账号
以遵从权限最小化原则。
- 对人员和服务账号审计所考虑的因素可能不同。
- 针对复杂系统的配置包可能包含系统组件相关的各种服务账号的定义。因为服务账号
的创建约束不多并且有名字空间域的名称，这种配置是很轻量的。
### 服务账户准入控制器
<!--
## Service account automation
对 pod 的改动通过一个被称为 [Admission Controller](/zh/docs/reference/access-authn-authz/admission-controllers/) 的插件来实现。它是 apiserver 的一部分。
当 pod 被创建或更新时，它会同步地修改 pod。 当该插件处于激活状态 ( 在大多数发行版中都是默认的 )，当 pod 被创建或更新时它会进行以下动作：
Three separate components cooperate to implement the automation around service accounts:
1. 如果该 pod 没有 `ServiceAccount` 设置，将其 `ServiceAccount` 设为 `default`。
2. 保证 pod 所关联的 `ServiceAccount` 存在，否则拒绝该 pod。
4. 如果 pod 不包含 `ImagePullSecrets` 设置，那么 将 `ServiceAccount` 中的 `ImagePullSecrets` 信息添加到 pod 中。
5. 将一个包含用于 API 访问的 token 的 `volume` 添加到 pod 中。
6. 将挂载于 `/var/run/secrets/kubernetes.io/serviceaccount` 的 `volumeSource` 添加到 pod 下的每个容器中。
- A `ServiceAccount` admission controller
- A Token controller
- A `ServiceAccount` controller
-->
## 服务账号的自动化 {#service-account-automation}
### Token 管理器
三个独立组件协作完成服务账号相关的自动化：
Token 管理器是 controller-manager 的一部分。 以异步的形式工作：
- `ServiceAccount` 准入控制器
- Token 控制器
- `ServiceAccount` 控制器
- 检测服务账户的创建，并且创建相应的 Secret 以支持 API 访问。
- 检测服务账户的删除，并且删除所有相应的服务账户 Token Secret。
- 检测 Secret 的增加，保证相应的服务账户存在，如有需要，为 Secret 增加 token。
- 检测 Secret 的删除，如有需要，从相应的服务账户中移除引用。
<!--
### ServiceAccount Admission Controller
你需要通过 `--service-account-private-key-file` 参数项传入一个服务账户私钥文件至 Token 管理器。 私钥用于为生成的服务账户 token 签名。
同样地，你需要通过 `--service-account-key-file` 参数将对应的公钥传入 kube-apiserver。 公钥用于认证过程中的 token 校验。
The modification of pods is implemented via a plugin
called an [Admission Controller](/docs/reference/access-authn-authz/admission-controllers/).
It is part of the API server.
It acts synchronously to modify pods as they are created or updated. When this plugin is active
(and it is by default on most distributions), then it does the following when a pod is created or modified:
-->
### ServiceAccount 准入控制器 {#serviceaccount-admission-controller}
#### 创建额外的 API tokens
对 Pod 的改动通过一个被称为
[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
的插件来实现。它是 API 服务器的一部分。
当 Pod 被创建或更新时，它会同步地修改 Pod。
如果该插件处于激活状态（在大多数发行版中都是默认激活的），当 Pod 被创建
或更新时它会进行以下操作：
控制器中有专门的循环来保证每个服务账户中都存在 API token 对应的 Secret。 当需要为服务账户创建额外的 API token 时，创建一个类型为 `ServiceAccountToken` 的 Secret，并在 annotation 中引用服务账户，控制器会生成 token 并更新 :
<!--
1. If the pod does not have a `serviceAccountName` set, it sets the
`serviceAccountName` to `default`.
1. It ensures that the `serviceAccountName` referenced by the pod exists, and
otherwise rejects it.
1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets`
of the ServiceAccount referenced by `serviceAccountName` are added to the pod.
1. It adds a `volume` to the pod which contains a token for API access
if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's
`automountServiceAccountToken` is set to `false`.
1. It adds a `volumeSource` to each container of the pod mounted at
`/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has
created a volume for ServiceAccount token.
-->
1. 如果该 Pod 没有设置 `serviceAccountName`，将其 `serviceAccountName` 设为
`default`。
1. 保证 Pod 所引用的 `serviceAccountName` 确实存在，否则拒绝该 Pod。
1. 如果 Pod 不包含 `imagePullSecrets` 设置，将 `serviceAccountName` 所引用
的服务账号中的 `imagePullSecrets` 信息添加到 Pod 中。
1. 如果服务账号的 `automountServiceAccountToken` 或 Pod 的
`automountServiceAccountToken` 都为设置为 `false`，则为 Pod 创建一个
`volume`，在其中包含用来访问 API 的令牌。
1. 如果前一步中为服务账号令牌创建了卷，则为 Pod 中的每个容器添加一个
`volumeSource`，挂载在其 `/var/run/secrets/kubernetes.io/serviceaccount`
目录下。
secret.json:
<!--
You can migrate a service account volume to a projected volume when
the `BoundServiceAccountTokenVolume` feature gate is enabled.
The service account token will expire after 1 hour or the pod is deleted. See
more details about
[projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
-->
当 `BoundServiceAccountTokenVolume` 特性门控被启用时，你可以将服务账号卷迁移到投射卷。
服务账号令牌会在 1 小时后或者 Pod 被删除之后过期。
更多信息可参阅[投射卷](/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage/)。
```json
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "mysecretname",
"annotations": {
"kubernetes.io/service-account.name": "myserviceaccount"
}
},
"type": "kubernetes.io/service-account-token"
}
<!--
### Token Controller
TokenController runs as part of `kube-controller-manager`. It acts asynchronously. It:
- watches ServiceAccount creation and creates a corresponding
ServiceAccount token Secret to allow API access.
- watches ServiceAccount deletion and deletes all corresponding ServiceAccount
token Secrets.
- watches ServiceAccount token Secret addition, and ensures the referenced
ServiceAccount exists, and adds a token to the Secret if needed.
- watches Secret deletion and removes a reference from the corresponding
ServiceAccount if needed.
-->
### Token 控制器 {#token-controller}
TokenController 作为 `kube-controller-manager` 的一部分运行，以异步的形式工作。
其职责包括：
- 监测 ServiceAccount 的创建并创建相应的服务账号令牌 Secret 以允许访问 API。
- 监测 ServiceAccount 的删除并删除所有相应的服务账号令牌 Secret。
- 监测服务账号令牌 Secret 的添加，保证相应的 ServiceAccount 存在，如有需要，
向 Secret 中添加令牌。
- 监测服务账号令牌 Secret 的删除，如有需要，从相应的 ServiceAccount 中移除引用。
<!--
You must pass a service account private key file to the token controller in
the `kube-controller-manager` using the `--service-account-private-key-file`
flag. The private key is used to sign generated service account tokens.
Similarly, you must pass the corresponding public key to the `kube-apiserver`
using the `--service-account-key-file` flag. The public key will be used to
verify the tokens during authentication.
-->
你必须通过 `--service-account-private-key-file` 标志为 `kube-controller-manager`
的令牌控制器传入一个服务账号私钥文件。该私钥用于为所生成的服务账号令牌签名。
同样地，你需要通过 `--service-account-key-file` 标志将对应的公钥通知给
kube-apiserver。公钥用于在身份认证过程中校验令牌。
<!--
#### To create additional API tokens
A controller loop ensures a Secret with an API token exists for each
ServiceAccount. To create additional API tokens for a ServiceAccount, create a
Secret of type `kubernetes.io/service-account-token` with an annotation
referencing the ServiceAccount, and the controller will update it with a
generated token:
Below is a sample configuration for such a Secret:
-->
#### 创建额外的 API 令牌 {#to-create-additional-api-tokens}
控制器中有专门的循环来保证每个 ServiceAccount 都存在对应的包含 API 令牌的 Secret。
当需要为 ServiceAccount 创建额外的 API 令牌时，可以创建一个类型为
`kubernetes.io/service-account-token` 的 Secret，并在其注解中引用对应的
ServiceAccount。控制器会生成令牌并更新该 Secret：
下面是这种 Secret 的一个示例配置：
```yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecretname
annotations:
kubernetes.io/service-account.name: myserviceaccount
type: kubernetes.io/service-account-token
```
```shell
@ -78,12 +211,23 @@ kubectl create -f ./secret.json
kubectl describe secret mysecretname
```
#### 删除 / 失效 服务账户 token
<!--
#### To delete/invalidate a ServiceAccount token Secret
-->
#### 删除/废止服务账号令牌 Secret
```shell
kubectl delete secret mysecretname
```
### 服务账户管理器
<!--
### ServiceAccount controller
A ServiceAccount controller manages the ServiceAccounts inside namespaces, and
ensures a ServiceAccount named "default" exists in every active namespace.
-->
### 服务账号控制器 {#serviceaccount-controller}
服务账号控制器管理各名字空间下的 ServiceAccount 对象，并且保证每个活跃的
名字空间下存在一个名为 "default" 的 ServiceAccount。
服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为 "default" 的服务账户