@@ -51,8 +51,8 @@ Currently, the following types of volume sources can be projected:
51
51
All sources are required to be in the same namespace as the Pod. For more details,
52
52
see the [all-in-one volume](https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md) design document.
53
53
-->
54
- 所有的卷源都要求处于 Pod 所在的同一个名字空间内。进一步的详细信息,可参考
55
- [ 一体化卷] ( https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md ) 设计文档。
54
+ 所有的卷源都要求处于 Pod 所在的同一个名字空间内。更多详细信息,
55
+ 可参考 [ 一体化卷] ( https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md ) 设计文档。
56
56
57
57
<!--
58
58
### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
@@ -86,15 +86,13 @@ parameters are nearly the same with two exceptions:
86
86
87
87
<!--
88
88
## serviceAccountToken projected volumes {#serviceaccounttoken}
89
- When the `TokenRequestProjection` feature is enabled, you can inject the token
90
- for the current [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
89
+ You can inject the token for the current [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
91
90
into a Pod at a specified path. For example:
92
91
-->
93
92
## serviceAccountToken 投射卷 {#serviceaccounttoken}
94
93
95
- 当 ` TokenRequestProjection ` 特性被启用时,你可以将当前
96
- [ 服务账号] ( /zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens )
97
- 的令牌注入到 Pod 中特定路径下。例如:
94
+ 你可以将当前[ 服务账号] ( /zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens ) 的令牌注入到
95
+ Pod 中特定路径下。例如:
98
96
99
97
{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
100
98
@@ -159,6 +157,39 @@ ownership.
159
157
中设置了 ` RunAsUser ` 属性的 Linux Pod 中,投射文件具有正确的属主属性设置,
160
158
其中包含了容器用户属主。
161
159
160
+ <!--
161
+ When all containers in a pod have the same `runAsUser` set in their
162
+ [`PodSecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)
163
+ or container
164
+ [`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1),
165
+ then the kubelet ensures that the contents of the `serviceAccountToken` volume are owned by that user,
166
+ and the token file has its permission mode set to `0600`.
167
+ -->
168
+ 当 Pod 中的所有容器在其
169
+ [ ` PodSecurityContext ` ] ( /zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context )
170
+ 或容器
171
+ [ ` SecurityContext ` ] ( /zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1 )
172
+ 中设置了相同的 ` runAsUser ` 时,kubelet 将确保 ` serviceAccountToken `
173
+ 卷的内容归该用户所有,并且令牌文件的权限模式会被设置为 ` 0600 ` 。
174
+
175
+ {{< note >}}
176
+ <!--
177
+ {{< glossary_tooltip text="Ephemeral containers" term_id="ephemeral-container" >}}
178
+ added to a Pod after it is created do *not* change volume permissions that were
179
+ set when the pod was created.
180
+
181
+ If a Pod's `serviceAccountToken` volume permissions were set to `0600` because
182
+ all other containers in the Pod have the same `runAsUser`, ephemeral
183
+ containers must use the same `runAsUser` to be able to read the token.
184
+ -->
185
+ 在某 Pod 被创建后为其添加的{{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}}** 不会** 更改创建该
186
+ Pod 时设置的卷权限。
187
+
188
+ 如果 Pod 的 ` serviceAccountToken ` 卷权限被设为 ` 0600 `
189
+ 是因为 Pod 中的其他所有容器都具有相同的 ` runAsUser ` ,
190
+ 则临时容器必须使用相同的 ` runAsUser ` 才能读取令牌。
191
+ {{< /note >}}
192
+
162
193
### Windows
163
194
164
195
<!--
0 commit comments