Skip to content

Commit cf0c884

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #49516 from windsonsea/acadmz
[zh] Sync service-accounts-admin.md
2 parents 7ed9cc9 + 8d82fec commit cf0c884

File tree

1 file changed

+94
-78
lines changed

1 file changed

+94
-78
lines changed

‎content/zh-cn/docs/reference/access-authn-authz/service-accounts-admin.md

Lines changed: 94 additions & 78 deletions
Original file line numberDiff line numberDiff line change
@@ -176,95 +176,104 @@ and uid when inspecting a JWT.
176176
<!--
177177
### Verifying and inspecting private claims
178178
179-
The `TokenReview` API can be used to verify and extract private claims from a token:
179+
The TokenReview API can be used to verify and extract private claims from a token:
180180
-->
181181
### 查验和检视私有声明 {#verifying-and-inspecting-private-claims}
182182

183-
`TokenReview` API 可用于校验并从令牌中提取私有声明：
183+
TokenReview API 可用于校验并从令牌中提取私有声明：
184184

185185
<!--
186186
1. First, assume you have a pod named `test-pod` and a service account named `my-sa`.
187-
2. Create a token that is bound to this Pod:
187+
1. Create a token that is bound to this Pod:
188188
-->
189189
1. 首先，假设你有一个名为 `test-pod` 的 Pod 和一个名为 `my-sa` 的服务帐户。
190190
2. 创建绑定到此 Pod 的令牌：
191191

192-
```shell
193-
kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod"
194-
```
192+
```shell
193+
kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod"
194+
```
195195

196196
<!--
197-
3. Copy this token into a new file named `tokenreview.yaml`:
197+
1. Copy this token into a new file named `tokenreview.yaml`:
198+
199+
```yaml
200+
apiVersion: authentication.k8s.io/v1
201+
kind: TokenReview
202+
spec:
203+
token: <token from step 2>
204+
```
198205
-->
199206
3. 将此令牌复制到名为 `tokenreview.yaml` 的新文件中：
200207

201-
```yaml
202-
apiVersion: authentication.k8s.io/v1
203-
kind: TokenReview
204-
spec:
205-
token: <来自第二步的令牌内容>
206-
```
208+
```yaml
209+
apiVersion: authentication.k8s.io/v1
210+
kind: TokenReview
211+
spec:
212+
token: <第 2 步获取的令牌>
213+
```
207214
208215
<!--
209-
4. Submit this resource to the apiserver for review:
210-
-->
211-
4. 将此资源提交给 API 服务器进行审核：
216+
1. Submit this resource to the apiserver for review:
212217
213-
<!--
214-
# we use '-o yaml' so we can inspect the output
215-
-->
216-
```shell
217-
kubectl create -o yaml -f tokenreview.yaml # 我们使用 '-o yaml' 以便检视命令输出
218-
```
218+
```shell
219+
# use '-o yaml' to inspect the output
220+
kubectl create -o yaml -f tokenreview.yaml
221+
```
219222

220-
<!--
221-
You should see an output like below:
223+
You should see an output like below:
222224
-->
223-
你应该看到如下所示的输出：
225+
4. 将此资源提交给 API 服务器进行审核：
224226

225-
```yaml
226-
apiVersion: authentication.k8s.io/v1
227-
kind: TokenReview
228-
metadata:
229-
creationTimestamp: null
230-
spec:
231-
token: <token>
232-
status:
233-
audiences:
234-
- https://kubernetes.default.svc.cluster.local
235-
authenticated: true
236-
user:
237-
extra:
238-
authentication.kubernetes.io/credential-id:
239-
- JTI=7ee52be0-9045-4653-aa5e-0da57b8dccdc
240-
authentication.kubernetes.io/node-name:
241-
- kind-control-plane
242-
authentication.kubernetes.io/node-uid:
243-
- 497e9d9a-47aa-4930-b0f6-9f2fb574c8c6
244-
authentication.kubernetes.io/pod-name:
245-
- test-pod
246-
authentication.kubernetes.io/pod-uid:
247-
- e87dbbd6-3d7e-45db-aafb-72b24627dff5
248-
groups:
249-
- system:serviceaccounts
250-
- system:serviceaccounts:default
251-
- system:authenticated
252-
uid: f8b4161b-2e2b-11e9-86b7-2afc33b31a7e
253-
username: system:serviceaccount:default:my-sa
254-
```
255-
256-
{{< note >}}
257-
<!--
258-
Despite using `kubectl create -f` to create this resource, and defining it similar to
259-
other resource types in Kubernetes, TokenReview is a special type and the kube-apiserver
260-
does not actually persist the TokenReview object into etcd.
261-
Hence `kubectl get tokenreview` is not a valid command.
262-
-->
263-
尽管你使用了 `kubectl create -f` 来创建此资源，并与 Kubernetes
264-
中的其他资源类型类似的方式定义它，但 TokenReview 是一种特殊类别，
265-
kube-apiserver 实际上并不将 TokenReview 对象持久保存到 etcd 中。
266-
因此 `kubectl get tokenreview` 不是一个有效的命令。
267-
{{< /note >}}
227+
```shell
228+
# 使用 '-o yaml' 检视命令输出
229+
kubectl create -o yaml -f tokenreview.yaml
230+
```
231+
232+
你应该看到如下所示的输出：
233+
234+
```yaml
235+
apiVersion: authentication.k8s.io/v1
236+
kind: TokenReview
237+
metadata:
238+
creationTimestamp: null
239+
spec:
240+
token: <token>
241+
status:
242+
audiences:
243+
- https://kubernetes.default.svc.cluster.local
244+
authenticated: true
245+
user:
246+
extra:
247+
authentication.kubernetes.io/credential-id:
248+
- JTI=7ee52be0-9045-4653-aa5e-0da57b8dccdc
249+
authentication.kubernetes.io/node-name:
250+
- kind-control-plane
251+
authentication.kubernetes.io/node-uid:
252+
- 497e9d9a-47aa-4930-b0f6-9f2fb574c8c6
253+
authentication.kubernetes.io/pod-name:
254+
- test-pod
255+
authentication.kubernetes.io/pod-uid:
256+
- e87dbbd6-3d7e-45db-aafb-72b24627dff5
257+
groups:
258+
- system:serviceaccounts
259+
- system:serviceaccounts:default
260+
- system:authenticated
261+
uid: f8b4161b-2e2b-11e9-86b7-2afc33b31a7e
262+
username: system:serviceaccount:default:my-sa
263+
```
264+
265+
{{< note >}}
266+
<!--
267+
Despite using `kubectl create -f` to create this resource, and defining it similar to
268+
other resource types in Kubernetes, TokenReview is a special type and the kube-apiserver
269+
does not actually persist the TokenReview object into etcd.
270+
Hence `kubectl get tokenreview` is not a valid command.
271+
-->
272+
尽管你使用了 `kubectl create -f` 来创建此资源，并与 Kubernetes
273+
中的其他资源类型类似的方式定义它，但 TokenReview 是一种特殊类别，
274+
kube-apiserver 实际上并不将 TokenReview 对象持久保存到 etcd 中。
275+
因此 `kubectl get tokenreview` 不是一个有效的命令。
276+
{{< /note >}}
268277

269278
<!--
270279
#### Schema for service account private claims
@@ -495,9 +504,11 @@ API [直接获得](#bound-service-account-token-volume) API 凭据，
495504
当挂载的 Pod 被删除时这些令牌将自动失效。
496505

497506
<!--
498-
You can still [manually create](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount) a Secret to hold a service account token; for example, if you need a token that never expires.
507+
You can still [manually create](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount)
508+
a Secret to hold a service account token; for example, if you need a token that never expires.
499509

500-
Once you manually create a Secret and link it to a ServiceAccount, the Kubernetes control plane automatically populates the token into that Secret.
510+
Once you manually create a Secret and link it to a ServiceAccount,
511+
the Kubernetes control plane automatically populates the token into that Secret.
501512
-->
502513
你仍然可以[手动创建](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount)
503514
Secret 来保存服务账号令牌；例如在你需要一个永不过期的令牌的时候。
@@ -668,7 +679,7 @@ kube-apiserver。公钥用于在身份认证过程中校验令牌。
668679

669680
<!--
670681
An alternate setup to setting `--service-account-private-key-file` and `--service-account-key-file` flags is
671-
to configure an external JWT signer for [external ServiceAccount token signing and key management](#external-serviceaccount-token-signing-and-key-management).
682+
to configure an external JWT signer for [external ServiceAccount token signing and key management](#external-serviceaccount-token-signing-and-key-management).
672683
Note that these setups are mutually exclusive and cannot be configured together.
673684
-->
674685
设置 `--service-account-private-key-file` 和 `--service-account-key-file`
@@ -881,10 +892,9 @@ That manifest snippet defines a projected volume that combines information from
881892
1. A `serviceAccountToken` source, that contains a token that the kubelet acquires from kube-apiserver.
882893
The kubelet fetches time-bound tokens using the TokenRequest API. A token served for a TokenRequest expires
883894
either when the pod is deleted or after a defined lifespan (by default, that is 1 hour).
884-
The kubelet also refreshes that token before the token expires.
885895
The token is bound to the specific Pod and has the kube-apiserver as its audience.
886896
1. A `configMap` source. The ConfigMap contains a bundle of certificate authority data. Pods can use these
887-
certificates to make sure that they are connecting to your cluster's kube-apiserver (and not to middlebox
897+
certificates to make sure that they are connecting to your cluster's kube-apiserver (and not to a middlebox
888898
or an accidentally misconfigured peer).
889899
1. A `downwardAPI` source. This `downwardAPI` volume makes the name of the namespace containing the Pod available
890900
to application code running inside the Pod.
@@ -1059,9 +1069,12 @@ kubectl -n examplens delete secret/example-automated-thing-token-zyxwv
10591069

10601070
<!--
10611071
The kube-apiserver can be configured to use external signer for token signing and token verifying key management.
1062-
This feature enables kubernetes distributions to integrate with key management solutions of their choice (eg: HSMs, cloud KMSes) for service account credential signing and verification.
1063-
To configure kube-apiserver to use external-jwt-signer set the `--service-account-signing-endpoint` flag to the location of a Unix domain socket (UDS) on a filesystem, or be prefixed with an @ symbol and name a UDS in the abstract socket namespace.
1064-
At the configured UDS, shall be an RPC server which implements [ExternalJWTSigner](https://github.com/kubernetes/kubernetes/blob/release-1.32/staging/src/k8s.io/externaljwt/apis/v1alpha1/api.proto).
1072+
This feature enables kubernetes distributions to integrate with key management solutions of their choice
1073+
(for example, HSMs, cloud KMSes) for service account credential signing and verification.
1074+
To configure kube-apiserver to use external-jwt-signer set the `--service-account-signing-endpoint` flag
1075+
to the location of a Unix domain socket (UDS) on a filesystem, or be prefixed with an @ symbol and name
1076+
a UDS in the abstract socket namespace. At the configured UDS, shall be an RPC server which implements
1077+
[ExternalJWTSigner](https://github.com/kubernetes/kubernetes/blob/release-1.32/staging/src/k8s.io/externaljwt/apis/v1alpha1/api.proto).
10651078
The external-jwt-signer must be healthy and be ready to serve supported service account keys for the kube-apiserver to start.
10661079
-->
10671080
kube-apiserver 可以被配置为使用外部签名程序进行令牌签名和令牌验证密钥管理。
@@ -1073,14 +1086,17 @@ kube-apiserver 可以被配置为使用外部签名程序进行令牌签名和
10731086
的 RPC 服务器。external-jwt-signer 必须处于健康状态，并准备好为 kube-apiserver 启动提供支持的服务账户密钥。
10741087

10751088
<!--
1076-
Check out [KEP-740](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/740-service-account-external-signing) for more details on ExternalJWTSigner.
1089+
Check out [KEP-740](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/740-service-account-external-signing)
1090+
for more details on ExternalJWTSigner.
10771091
-->
10781092
有关 ExternalJWTSigner 的细节，查阅
10791093
[KEP-740](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/740-service-account-external-signing)。
10801094

10811095
{{< note >}}
10821096
<!--
1083-
The kube-apiserver flags `--service-account-key-file` and `--service-account-signing-key-file` will continue to be used for reading from files unless `--service-account-signing-endpoint` is set; they are mutually exclusive ways of supporting JWT signing and authentication.
1097+
The kube-apiserver flags `--service-account-key-file` and `--service-account-signing-key-file` will continue
1098+
to be used for reading from files unless `--service-account-signing-endpoint` is set; they are mutually
1099+
exclusive ways of supporting JWT signing and authentication.
10841100
-->
10851101
kube-apiserver 的 `--service-account-key-file` 和 `--service-account-signing-key-file`
10861102
标志将继续被用于从文件中读取，除非设置了 `--service-account-signing-endpoint`；

0 commit comments

Comments
 (0)