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
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
In Windows pods that have a projected volume and `RunAsUsername` set in the