Skip to content

[docs] Update SAM verbiage in project volume doc #798

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
openshift-merge-robot merged 1 commit into from
Nov 19, 2021
Merged

[docs] Update SAM verbiage in project volume doc #798

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions docs/projected-volume.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Comment on lines +9 to +10
Copy link
Contributor

@codyhoag codyhoag Nov 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
user and group accounts in a database file called Security Account Manager (SAM). Each container maintains its own
instance of the SAM database; the host machine has no visibility into the SAM database while the container is running. Windows

This sentence sounded awkward to me. Does this suggestion mean the same thing?

Copy link
Contributor Author

@aravindhp aravindhp Nov 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could imply the SAM database on the host. So it would be safer to leave this as is.

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 kubelet running on the host does not have the ability to dynamically configure
host file ownership for virtualized container accounts. If files on the host machine are to be shared with the
container, they should be placed into their own volume mount outside of the `C:\` drive.

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.

Expand Down