OSDOCS-2711 Information on project volume permission issues for Windows pods #37587
Conversation
openshift-ci
bot
added
the
size/XS
|
✔️ Deploy Preview for osdocs ready! 🔨 Explore the source changes: c488988 🔍 Inspect the deploy log: https://app.netlify.com/sites/osdocs/deploys/616f2d1e74efeb0008aa8f66 😎 Browse the preview: https://deploy-preview-37587--osdocs.netlify.app/openshift-enterprise/latest/nodes/containers/nodes-containers-projected-volumes |
|
@aravindhp PTAL |
codyhoag
force-pushed
the
windows-permission-handling-issue
branch
from
cd869c7 to
553ece2
Compare
openshift-ci
bot
added
size/M
codyhoag
force-pushed
the
windows-permission-handling-issue
branch
from
553ece2 to
23590aa
Compare
|
@sgaoshang please verify from a QE perspective. Thanks! |
Also adding @rrasouli |
|
/lgtm |
codyhoag
force-pushed
the
windows-permission-handling-issue
branch
from
149b18e to
62c9f45
Compare
|
New changes are detected. LGTM label has been removed. |
codyhoag
added
the
peer-review-needed
| Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU) | ||
| ---- | ||
|
|
||
| This implies all administrator users, like someone with the `ContainerAdministrator` role, will have read, write, and execute access, while non-administrator users will have read and execute access. |
There was a problem hiding this comment.
s/will have/has in both places.
| [id="file-permission-handling-for-windows-pods_{context}"] | ||
| == File permission handling for Windows pods | ||
|
|
||
| When the `RunAsUser` permission is set in the security context of a Linux-based pod, the projected files have the correct permissions set, including container user ownership. However, this is not the case for Windows pods when the `RunAsUsername` permission 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. |
There was a problem hiding this comment.
Might I suggest moving the 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. sentence to the end?
And going with something like However, this is not the case for Windows pods. If the RunAsUsername permission is set, the kubelet is prevented from setting correct ownership on the files in the projected volume. This is due to differences...
I wonder if a typical user would be more concerned with what happens than why?
|
|
||
| When the `RunAsUser` permission is set in the security context of a Linux-based pod, the projected files have the correct permissions set, including container user ownership. However, this is not the case for Windows pods when the `RunAsUsername` permission 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. | ||
|
|
||
| This problem can get exacerbated when used in conjunction with a hostPath volume where best practices are not followed. For example, giving a pod access to the `C:\var\lib\kubelet\pods\` folder results in that pod being able to access service account tokens from other pods. |
There was a problem hiding this comment.
I like the wording in the upstream issue. Very simple and clear: _In addition, if a Windows pod is created with a Projected Volume and RunAsUser set, the Pod will be stuck at the ContainerCreating phase. (As much as I like the word exacerbate!)
There was a problem hiding this comment.
These are two separate problems:
- A security risk is exposed with a hostPath volume
- When a Windows pod is created with a PV and
RunAsUserpermission, pod gets stuck.
So I don't think we want to replace one with the other. Item 2 is expressed in the next paragraph.
|
|
||
| This implies all administrator users, like someone with the `ContainerAdministrator` role, will have read, write, and execute access, while non-administrator users will have read and execute access. | ||
|
|
||
| Creating a Windows pod with the `RunAsUser` and `RunAsUsername` permissions in its security context results in the pod being stuck in the `ContainerCreating` phase. To handle this scenario, a workaround provided in link:https://bugzilla.redhat.com/show_bug.cgi?id=1971745[BZ#1971745] has been introduced in {product-title}. This forces the file permission handling in projected service account volumes set in the security context of the pod to not be honored for projected volumes on Windows. Note that this workaround for Windows pods is how file permission handling used to work for all pod types prior to {product-title} 4.7. |
There was a problem hiding this comment.
To handle this scenario, a workaround provided in BZ#1971745
I read this to mean that there is a manual workaround, steps that the user needs to perform, in BZ#1971745. But I don't see one. Is there anything the user needs to do here?
|
|
||
| This implies all administrator users, like someone with the `ContainerAdministrator` role, will have read, write, and execute access, while non-administrator users will have read and execute access. | ||
|
|
||
| Creating a Windows pod with the `RunAsUser` and `RunAsUsername` permissions in its security context results in the pod being stuck in the `ContainerCreating` phase. To handle this scenario, a workaround provided in link:https://bugzilla.redhat.com/show_bug.cgi?id=1971745[BZ#1971745] has been introduced in {product-title}. This forces the file permission handling in projected service account volumes set in the security context of the pod to not be honored for projected volumes on Windows. Note that this workaround for Windows pods is how file permission handling used to work for all pod types prior to {product-title} 4.7. |
There was a problem hiding this comment.
@codyhoag I realize this issue can happen by just setting RunAsUser. So we should remove and RunAsUsername.
There was a problem hiding this comment.
@aravindhp we state this sentence earlier:
When the Windows equivalent RunAsUsername permission is set, the kubelet is prevented from setting correct ownership on the files in the projected volume.
Can we center this issue around OpenShift auto-applying the RunAsUser to Windows pods? It seems that's the main reason for this.
I'm beginning to lean towards making this a known issue only. We're providing a lot of background info that I'm not sure a regular user is interested in. It may make more sense to simply state the current behavior and brief implemented workaround in OCP, and let the linked BZ do any deep dive into the nitty gritty details.
Would something like this in the known issues be acceptable?
{product-title} applies the `RunAsUser` security context to all pods irrespective of its
operating system. This means Windows pods automatically have the `RunAsUser`
permission applied to its security context. When the `RunAsUser` permission is set
in the security context of a Linux-based pod, the projected files have the correct
permissions set, including container user ownership. However, when the `RunAsUser`
permission is set in a Windows pod, the kubelet is prevented from setting correct
ownership on the files in the projected volume. In addition, if a Windows pod is created
with a projected volume and the `RunAsUser` permission set, the pod gets stuck in the
`ContainerCreating` phase.
This problem can get exacerbated when used in conjunction with a hostPath volume
where best practices are not followed. For example, giving a pod access to the
`C:\var\lib\kubelet\pods\` folder results in that pod being able to access service account
tokens from other pods.
To handle this issue, {product-title} forces the file permission handling in projected
service account volumes set in the security context of the pod to not be honored for
projected volumes on Windows (link:https://bugzilla.redhat.com/show_bug.cgi?id=1971745[BZ#1971745]).
Note that this behavior for Windows pods is how file permission handling used to work for
all pod types prior to {product-title} 4.7.
There was a problem hiding this comment.
Can we center this issue around OpenShift auto-applying the RunAsUser to Windows pods? It seems that's the main reason for this.
OpenShift having an admission controller that auto applied RunAsUser was the only reason we discovered the main underlying security issue i.e. RunAsUsername for Windows Pods are not honored. So we really need to make the user aware of what the result of using RunAsUsername in conjunction to a projected volume. This is also why we need to explain what the default permission model is for projected volumes for Windows Pods. We don't want users thinking that they are getting the same behavior as with Linux Pods and `RunAsUser. But I am fine if you want to pare down the technical details.
codyhoag
force-pushed
the
windows-permission-handling-issue
branch
from
62c9f45 to
c488988
Compare
https://issues.redhat.com/browse/OSDOCS-2711
Preview: https://deploy-preview-37587--osdocs.netlify.app/openshift-enterprise/latest/nodes/containers/nodes-containers-projected-volumes.html#file-permission-handling-for-windows-pods_nodes-containers-projected-volumes