From 31416af3fa8840af9970561c07ee454ebbf54222 Mon Sep 17 00:00:00 2001 From: Lee Verberne Date: Fri, 18 Mar 2022 17:35:10 +0100 Subject: [PATCH 1/6] Clarify handling of projected SA token permissions --- .../concepts/storage/projected-volumes.md | 20 ++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index df67132cf5..835f1c9b12 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -71,18 +71,24 @@ A container using a projected volume source as a [`subPath`](/docs/concepts/stor volume mount will not receive updates for those volume sources. {{< /note >}} -## SecurityContext interactions +### serviceAccountToken and securityContext The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the the correct owner permissions set. -### Linux +#### Linux -In Linux pods that have a projected volume and `RunAsUser` set in the Pod -[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context), -the projected files have the correct ownership set including container user -ownership. +Kubernetes will improve security for serviceAccountToken files when all containers +have the same `runAsUser` set in +[`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) +by setting the file owner to the `runAsUser` and the file mode to `0600`. -### Windows +Note that {{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}} +aren't present when the pod is created. Adding an ephemeral container to a pod +will not change the permissions that were set when the pod was created. + +#### Windows In Windows pods that have a projected volume and `RunAsUsername` set in the Pod `SecurityContext`, the ownership is not enforced due to the way user From f84789b09974bb1f1ca7395fa6a86ad6e527b379 Mon Sep 17 00:00:00 2001 From: Lee Verberne Date: Sun, 17 Jul 2022 12:49:15 +0200 Subject: [PATCH 2/6] Improve clarity of projected account token behavior Co-authored-by: Tim Bannister --- .../concepts/storage/projected-volumes.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index 835f1c9b12..142243c9a7 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -77,16 +77,21 @@ The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-s #### Linux -Kubernetes will improve security for serviceAccountToken files when all containers -have the same `runAsUser` set in +In some cases, Kubernetes applies a security optimization for the contents of`serviceAccountToken` +volumes. +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) -by setting the file owner to the `runAsUser` and the file mode to `0600`. +[`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 that every file has its permission mode set to `0600`. -Note that {{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}} -aren't present when the pod is created. Adding an ephemeral container to a pod -will not change the permissions that were set when the pod was created. +{{< note >}} +If you add any {{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}} to +a Pod, those won't have been present when the pod started running on that node. +Adding an ephemeral container to a pod does **not** change any volume permissions +that were set when the pod was created. +{{< /note >}} #### Windows From d825c72ed10de68d6b6bafd2b03f7ba2d9ade027 Mon Sep 17 00:00:00 2001 From: Lee Verberne Date: Tue, 19 Jul 2022 08:24:51 +0200 Subject: [PATCH 3/6] Fix typo in projected volumes formatting Co-authored-by: Chris Negus --- content/en/docs/concepts/storage/projected-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index 142243c9a7..64fb2817d7 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -77,7 +77,7 @@ The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-s #### Linux -In some cases, Kubernetes applies a security optimization for the contents of`serviceAccountToken` +In some cases, Kubernetes applies a security optimization for the contents of `serviceAccountToken` volumes. When all containers in a pod have the same `runAsUser` set in their [`PodSecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) From 2512f5d7f1a9e2fd625fa733905d45e78fbf56f3 Mon Sep 17 00:00:00 2001 From: Lee Verberne Date: Fri, 26 Aug 2022 20:13:01 +0200 Subject: [PATCH 4/6] Update content/en/docs/concepts/storage/projected-volumes.md Co-authored-by: Tim Bannister --- content/en/docs/concepts/storage/projected-volumes.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index 64fb2817d7..de1ebfa526 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -87,10 +87,13 @@ then the kubelet ensures that the contents of the `serviceAccountToken` volume and that every file has its permission mode set to `0600`. {{< note >}} -If you add any {{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}} to -a Pod, those won't have been present when the pod started running on that node. -Adding an ephemeral container to a pod does **not** change any volume permissions -that were set when the pod was created. +{{< 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 From 77fd1deecd96bafc74d47a8e138ce8c459add1cd Mon Sep 17 00:00:00 2001 From: Lee Verberne Date: Wed, 2 Nov 2022 14:15:41 +0100 Subject: [PATCH 5/6] Address reviewer comments --- .../en/docs/concepts/storage/projected-volumes.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index de1ebfa526..1f0c9eb0c4 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -71,14 +71,17 @@ A container using a projected volume source as a [`subPath`](/docs/concepts/stor volume mount will not receive updates for those volume sources. {{< /note >}} -### serviceAccountToken and securityContext +## SecurityContext interactions The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the the correct owner permissions set. -#### Linux +### Linux + +In Linux pods that have a projected volume and `RunAsUser` set in the Pod +[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context), +the projected files have the correct ownership set including container user +ownership. -In some cases, Kubernetes applies a security optimization for the contents of `serviceAccountToken` -volumes. 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 @@ -96,7 +99,7 @@ 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 Pod `SecurityContext`, the ownership is not enforced due to the way user From 3afe0c7cd7658348d2cf8b2ce80a67e2045588a2 Mon Sep 17 00:00:00 2001 From: Lee Verberne Date: Wed, 2 Nov 2022 15:06:18 +0100 Subject: [PATCH 6/6] Clarify which files are modified in projected service account tokens --- content/en/docs/concepts/storage/projected-volumes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index 1f0c9eb0c4..f86fdc929f 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -86,8 +86,8 @@ 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 that every file has its permission mode set to `0600`. +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" >}}