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

Merge pull request #35053 from verb/32351-projected-volumes 

Clarify handling of projected SA token permissions
pull/37831/head
Kubernetes Prow Robot 2022-11-08 08:42:19 -08:00 committed by GitHub
parent d543a1de89 3afe0c7cd7
commit fb297763e7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
content/en/docs/concepts/storage/projected-volumes.md
View File

@ -82,6 +82,23 @@ In Linux pods that have a projected volume and `RunAsUser` set in the Pod
the projected files have the correct ownership set including container user the projected files have the correct ownership set including container user
ownership. ownership.
When all containers in a pod have the same `runAsUser` set in their
[`PodSecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)
or container
[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1),
then the kubelet ensures that the contents of the `serviceAccountToken` volume are owned by that user,
and the token file has its permission mode set to `0600`.
{{< note >}}
{{< glossary_tooltip text="Ephemeral containers" term_id="ephemeral-container" >}}
added to a Pod after it is created do *not* change volume permissions that were
set when the pod was created.
If a Pod's `serviceAccountToken` volume permissions were set to `0600` because
all other containers in the Pod have the same `runAsUser`, ephemeral
containers must use the same `runAsUser` to be able to read the token.
{{< /note >}}
### Windows ### Windows
In Windows pods that have a projected volume and `RunAsUsername` set in the In Windows pods that have a projected volume and `RunAsUsername` set in the