Update configure-service-account.md
yanrong.shi
parent
6871dd9cec
commit
a9ce4b8633
|
|
@ -33,10 +33,8 @@ not apply.
|
|||
<!--
|
||||
When you (a human) access the cluster (for example, using `kubectl`), you are
|
||||
authenticated by the apiserver as a particular User Account (currently this is
|
||||
usually `admin`, unless your cluster administrator has customized your
|
||||
cluster). Processes in containers inside pods can also contact the apiserver.
|
||||
When they do, they are authenticated as a particular Service Account (for example,
|
||||
`default`).
|
||||
usually `admin`, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver.
|
||||
When they do, they are authenticated as a particular Service Account (for example, `default`).
|
||||
-->
|
||||
当你（自然人）访问集群时（例如，使用 `kubectl`），API 服务器将你的身份验证为
|
||||
特定的用户帐户（当前这通常是 `admin`，除非你的集群管理员已经定制了你的集群配置）。
|
||||
|
|
@ -50,29 +48,30 @@ Pod 内的容器中的进程也可以与 api 服务器接触。
|
|||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
## Use the Default Service Account to access the API server.
|
||||
## Use the Default Service Account to access the API server
|
||||
|
||||
When you create a pod, if you do not specify a service account, it is
|
||||
automatically assigned the `default` service account in the same namespace.
|
||||
If you get the raw json or yaml for a pod you have created (for example, `kubectl get pods/podname -o yaml`),
|
||||
If you get the raw json or yaml for a pod you have created (for example, `kubectl get pods/<podname> -o yaml`),
|
||||
you can see the `spec.serviceAccountName` field has been
|
||||
[automatically set](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
|
||||
[automatically set](/docs/concepts/overview/working-with-objects/object-management/).
|
||||
-->
|
||||
## 使用默认的服务账户访问 API 服务器
|
||||
|
||||
当你创建 Pod 时，如果没有指定服务账户，Pod 会被指定给命名空间中的 `default` 服务账户。
|
||||
如果你查看 Pod 的原始 JSON 或 YAML（例如：`kubectl get pods/podname -o yaml`），
|
||||
你可以看到 `spec.serviceAccountName` 字段已经被自动设置了。
|
||||
如果你查看 Pod 的原始 JSON 或 YAML（例如：`kubectl get pods/<podname> -o yaml`），
|
||||
你可以看到 `spec.serviceAccountName` 字段已经被[自动设置](/zh-cn/docs/concepts/overview/working-with-objects/object-management/)了。
|
||||
|
||||
<!--
|
||||
You can access the API from inside a pod using automatically mounted service account credentials,
|
||||
as described in [Accessing the Cluster](/docs/tasks/accessing-application-cluster/access-cluster/).
|
||||
The API permissions of the service account depend on the [authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use.
|
||||
You can access the API from inside a pod using automatically mounted service account credentials, as described in
|
||||
[Accessing the Cluster](/docs/tasks/access-application-cluster/access-cluster).
|
||||
The API permissions of the service account depend on the
|
||||
[authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use.
|
||||
|
||||
You can opt out of automounting API credentials on `/var/run/secrets/kubernetes.io/serviceaccount/token` for a service account by setting `automountServiceAccountToken: false` on the ServiceAccount:
|
||||
-->
|
||||
你可以使用自动挂载给 Pod 的服务账户凭据访问 API，
|
||||
[访问集群](/zh-cn/docs/tasks/access-application-cluster/access-cluster/)页面中有相关描述。
|
||||
[访问集群](/zh-cn/docs/tasks/access-application-cluster/access-cluster)页面中有相关描述。
|
||||
服务账户的 API 许可取决于你所使用的
|
||||
[鉴权插件和策略](/zh-cn/docs/reference/access-authn-authz/authorization/#authorization-modules)。
|
||||
|
||||
|
|
@ -111,7 +110,7 @@ The pod spec takes precedence over the service account if both specify a `automo
|
|||
如果 Pod 和服务账户都指定了 `automountServiceAccountToken` 值，则 Pod 的 spec 优先于服务帐户。
|
||||
|
||||
<!--
|
||||
## Use Multiple Service Accounts.
|
||||
## Use Multiple Service Accounts
|
||||
|
||||
Every namespace has a default service account resource called `default`.
|
||||
You can list this and any other serviceAccount resources in the namespace with this command:
|
||||
|
|
@ -122,7 +121,7 @@ You can list this and any other serviceAccount resources in the namespace with t
|
|||
你可以用下面的命令查询这个服务账户以及命名空间中的其他 ServiceAccount 资源：
|
||||
|
||||
```shell
|
||||
kubectl get serviceAccounts
|
||||
kubectl get serviceaccounts
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -141,7 +140,7 @@ You can create additional ServiceAccount objects like this:
|
|||
你可以像这样来创建额外的 ServiceAccount 对象：
|
||||
|
||||
```shell
|
||||
kubectl create -f - <<EOF
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
|
|
@ -170,7 +169,7 @@ The output is similar to this:
|
|||
-->
|
||||
输出类似于：
|
||||
|
||||
```none
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
|
|
@ -215,7 +214,7 @@ kubectl delete serviceaccount/build-robot
|
|||
```
|
||||
|
||||
<!--
|
||||
## Manually create a service account API token.
|
||||
## Manually create a service account API token
|
||||
|
||||
Suppose we have an existing service account named "build-robot" as mentioned above, and we create
|
||||
a new secret manually.
|
||||
|
|
@ -225,7 +224,7 @@ a new secret manually.
|
|||
假设我们有一个上面提到的名为 "build-robot" 的服务账户，现在我们手动创建一个新的 Secret。
|
||||
|
||||
```shell
|
||||
kubectl create -f - <<EOF
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
|
|
@ -281,13 +280,13 @@ The content of `token` is elided here.
|
|||
|
||||
### Create an imagePullSecret
|
||||
|
||||
- Create an imagePullSecret, as described in [Specifying ImagePullSecret on a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
- Create an imagePullSecret, as described in [Specifying ImagePullSecrets on a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
-->
|
||||
## 为服务账户添加 ImagePullSecrets {#add-imagepullsecrets-to-a-service-account}
|
||||
|
||||
### 创建 ImagePullSecret
|
||||
|
||||
- 创建一个 ImagePullSecret，如[为 Pod 设置 ImagePullSecret](/zh-cn/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)所述。
|
||||
- 创建一个 ImagePullSecret，如[为 Pod 设置 ImagePullSecret](/zh-cn/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 所述。
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \
|
||||
|
|
@ -382,7 +381,7 @@ imagePullSecrets:
|
|||
<!--
|
||||
Finally replace the serviceaccount with the new updated `sa.yaml` file
|
||||
-->
|
||||
最后，用新的更新的 `sa.yaml` 文件替换服务账户。
|
||||
最后，使用新更新的 `sa.yaml` 文件替换服务账户。
|
||||
|
||||
```shell
|
||||
kubectl replace serviceaccount default -f ./sa.yaml
|
||||
|
|
@ -427,11 +426,8 @@ command line arguments to `kube-apiserver`:
|
|||
|
||||
<!--
|
||||
* `--service-account-issuer`
|
||||
It can be used as the Identifier of the service account token issuer. You can specify the
|
||||
`--service-account-issuer` argument multiple times, this can be useful to enable a non-disruptive
|
||||
change of the issuer. When this flag is specified multiple times, the first is used to generate
|
||||
tokens and all are used to determine which issuers are accepted. You must be running Kubernetes
|
||||
v1.22 or later to be able to specify `--service-account-issuer` multiple times.
|
||||
|
||||
It can be used as the Identifier of the service account token issuer. You can specify the `--service-account-issuer` argument multiple times, this can be useful to enable a non-disruptive change of the issuer. When this flag is specified multiple times, the first is used to generate tokens and all are used to determine which issuers are accepted. You must be running Kubernetes v1.22 or later to be able to specify `--service-account-issuer` multiple times.
|
||||
-->
|
||||
* `--service-account-issuer`
|
||||
|
||||
|
|
@ -440,13 +436,10 @@ command line arguments to `kube-apiserver`:
|
|||
这样做是有用的。如果这个参数被多次指定，则第一个参数值会被用来生成令牌，
|
||||
而所有参数值都会被用来确定哪些发放者是可接受的。你所运行的 Kubernetes
|
||||
集群必须是 v1.22 或更高版本，才能多次指定 `--service-account-issuer`。
|
||||
|
||||
<!--
|
||||
* `--service-account-key-file`
|
||||
File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify
|
||||
ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified
|
||||
multiple times with different files. If specified multiple times, tokens signed by any of the
|
||||
specified keys are considered valid by the Kubernetes API server.
|
||||
|
||||
File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If specified multiple times, tokens signed by any of the specified keys are considered valid by the Kubernetes API server.
|
||||
-->
|
||||
* `--service-account-key-file`
|
||||
|
||||
|
|
@ -454,26 +447,21 @@ command line arguments to `kube-apiserver`:
|
|||
的令牌。所指定的文件中可以包含多个秘钥，并且你可以多次使用此参数，
|
||||
每次参数值为不同的文件。多次使用此参数时，由所给的秘钥之一签名的令牌会被
|
||||
Kubernetes API 服务器认为是合法令牌。
|
||||
|
||||
<!--
|
||||
* `--service-account-signing-key-file`
|
||||
Path to the file that contains the current private key of the service account token issuer. The
|
||||
issuer signs issued ID tokens with this private key.
|
||||
|
||||
Path to the file that contains the current private key of the service account token issuer. The issuer signs issued ID tokens with this private key.
|
||||
-->
|
||||
* `--service-account-signing-key-file`
|
||||
|
||||
指向包含当前服务账户令牌发放者的私钥的文件路径。
|
||||
此发放者使用此私钥来签署所发放的 ID 令牌。
|
||||
|
||||
<!--
|
||||
* `--api-audiences` (can be omitted)
|
||||
The service account token authenticator validates that tokens used against the API are bound to
|
||||
at least one of these audiences. If `api-audiences` is specified multiple times, tokens for any of
|
||||
the specified audiences are considered valid by the Kubernetes API server. If the
|
||||
`--service-account-issuer` flag is configured and this flag is not, this field defaults to a
|
||||
single element list containing the issuer URL.
|
||||
|
||||
The service account token authenticator validates that tokens used against the API are bound to at least one of these audiences. If `api-audiences` is specified multiple times, tokens for any of the specified audiences are considered valid by the Kubernetes API server. If the `--service-account-issuer` flag is configured and this flag is not, this field defaults to a single element list containing the issuer URL.
|
||||
-->
|
||||
* `--api-audiences` (can be omitted)
|
||||
* `--api-audiences` (可以省略)
|
||||
|
||||
服务账户令牌身份检查组件会检查针对 API 访问所使用的令牌，
|
||||
确认令牌至少是被绑定到这里所给的受众（audiences）之一。
|
||||
|
|
@ -555,6 +543,7 @@ provider configuration at `{service-account-issuer}/.well-known/openid-configura
|
|||
If the URL does not comply, the `ServiceAccountIssuerDiscovery` endpoints will
|
||||
not be registered, even if the feature is enabled.
|
||||
-->
|
||||
{{< note >}}
|
||||
分发者的 URL 必须遵从
|
||||
[OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)。
|
||||
这意味着 URL 必须使用 `https` 模式，并且必须在
|
||||
|
|
@ -563,6 +552,7 @@ not be registered, even if the feature is enabled.
|
|||
|
||||
如果 URL 没有遵从这一规范，`ServiceAccountIssuerDiscovery` 末端就不会被注册，
|
||||
即使该特性已经被启用。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The Service Account Issuer Discovery feature enables federation of Kubernetes
|
||||
|
|
@ -606,9 +596,11 @@ The responses served at `/.well-known/openid-configuration` and
|
|||
compliant. Those documents contain only the parameters necessary to perform
|
||||
validation of Kubernetes service account tokens.
|
||||
-->
|
||||
{{< note >}}
|
||||
对 `/.well-known/openid-configuration` 和 `/openid/v1/jwks` 路径请求的响应被设计为与
|
||||
OIDC 兼容，但不是与其完全一致。
|
||||
返回的文档仅包含对 Kubernetes 服务账户令牌进行验证所必须的参数。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The JWKS response contains public keys that a relying party can use to validate
|
||||
|
|
@ -635,6 +627,7 @@ JWKS URI is required to use the `https` scheme.
|
|||
这时需要向 API 服务器传递 `--service-account-jwks-uri` 参数。
|
||||
与分发者 URL 类似，此 JWKS URI 也需要使用 `https` 模式。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
|
|
|
|||
Loading…
Reference in New Issue