whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Sync English site changes for authentication ref

Browse Source 
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.
This commit is contained in:
Qiming Teng
2020-11-28 22:57:30 +08:00
parent ec9bfbd16e
commit b8c9b2fa30
4 changed files with 672 additions and 279 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/reference/access-authn-authz/service-accounts-admin.md
+196 -52
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" 的服务账户