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

Clarify handling of projected SA token permissions

Author: k8s-ci-robot

content/en/docs/concepts/storage/projected-volumes.md

@@ -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