From 0f5ad4f54b6d1bd0840c6f5255e697a78895d4d7 Mon Sep 17 00:00:00 2001 From: Aravindh Puthiyaparambil Date: Wed, 10 Nov 2021 15:02:03 -0800 Subject: [PATCH] [docs] Update project volume verbiage ...from https://github.com/kubernetes/website/pull/30366/ --- docs/projected-volume.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/docs/projected-volume.md b/docs/projected-volume.md index 731bb8f7a..ba2e58b10 100644 --- a/docs/projected-volume.md +++ b/docs/projected-volume.md @@ -4,10 +4,15 @@ A [projected volume](https://kubernetes.io/docs/concepts/storage/volumes/#projec volume sources into the same directory in the container. With the [proposal for file permission handling in projected service account volume](https://github.com/kubernetes/enhancements/pull/1598) enhancement, the projected files have the correct permissions set including container user ownership for Linux pods when `RunAsUser` is set in the Pod -`SecurityContext`. However, for Windows pods this is not the case when `RunAsUsername` is set, due to differences in -the way user accounts are managed in Windows. Windows stores and manages local user and group accounts in a database -file called Security Account Manager (SAM). This database is not shared between the Windows container host and the -running containers. This prevents the kubelet from setting correct ownership on the files in the projected volume. +`SecurityContext`. 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 accounts are managed in Windows. Windows stores and manages local +user and group accounts in a database file called Security Account Manager (SAM). Each container maintains its own +instance of the SAM database, to which the host has no visibility into while the container is running. Windows +containers are designed to run the user mode portion of the OS in isolation from the host, hence the maintenance of a +virtual SAM database. As a result, the kublet running on the host does not have the ability to dynamically configure +host file ownership for virtualized container accounts. It is recommended that if files on the host machine are to be +shared with the container then they should be placed into their own volume mount outside of `C:\`. + This problem is tracked by [Windows Pod with RunAsUserName and a Projected Volume does not honor file permissions in the volume](https://github.com/kubernetes/kubernetes/issues/102849) issue.