kubernetes: Windows Pod with RunAsUserName and a Projected Volume does not honor file permissions in the volume
What happened:
When a Windows Pod is created with a Projected Volume and RunAsUserName set, file permissions are not handled in the projected volume. In addition if a Windows Pod is created with a Projected Volume and RunAsUser set,
securityContext:
runAsUser: 1000640000
windowsOptions:
runAsUserName: ContainerAdministrator
the Pod will be stuck at ContainerCreating:
E0611 17:38:46.666139 2260 atomic_writer.go:404] pod win-webserver/win-webserver-6dd6cd7d9-ng62b volume kube-api-access-62z59: unable to change file c:\var\lib\kubelet\pods\a7bddda2-a355-48cd-8ee2-71776d6de78f\volumes\kubernetes.io~projected\kube-api-access-62z59\..2021_06_11_17_38_46.035861910\token with owner 1000640000: chown c:\var\lib\kubelet\pods\a7bddda2-a355-48cd-8ee2-71776d6de78f\volumes\kubernetes.io~projected\kube-api-access-62z59\..2021_06_11_17_38_46.035861910\token: not supported by windows
E0611 17:38:46.666139 2260 atomic_writer.go:175] pod win-webserver/win-webserver-6dd6cd7d9-ng62b volume kube-api-access-62z59: error writing payload to ts data directory c:\var\lib\kubelet\pods\a7bddda2-a355-48cd-8ee2-71776d6de78f\volumes\kubernetes.io~projected\kube-api-access-62z59\..2021_06_11_17_38_46.035861910: chown c:\var\lib\kubelet\pods\a7bddda2-a355-48cd-8ee2-71776d6de78f\volumes\kubernetes.io~projected\kube-api-access-62z59\..2021_06_11_17_38_46.035861910\token: not supported by windows
What you expected to happen:
The Pod should go to Running with the project volume files having the correct container user ownership.
How to reproduce it (as minimally and precisely as possible):
Create a Windows Pod with a Projected Volume and runAsUserName set (optionally with runAsUser to cause the stuck at ContainerCreating issue).
Anything else we need to know?:
The KEP, proposal for file permission handling in projected service account volume and its implementation did not take Windows in to account. An os.Chown() was introduced which is not supported on Windows. In addition RunAsUserName being set on Windows Pods was not taken into account.
Environment:
- Kubernetes version (use
kubectl version): 1.21.1 - Cloud provider or hardware configuration: AWS / Azure
- OS: Windows Server 2019 1809
- Kernel:
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 1
- Comments: 38 (30 by maintainers)
Commits related to this issue
- storage: document Windows projected volume limitations xref: https://github.com/kubernetes/kubernetes/issues/102849 — committed to aravindhp/website by aravindhp 3 years ago
- storage: document Windows projected volume limitations xref: https://github.com/kubernetes/kubernetes/issues/102849 — committed to aravindhp/website by aravindhp 3 years ago
- storage: document Windows projected volume limitations xref: https://github.com/kubernetes/kubernetes/issues/102849 — committed to aravindhp/website by aravindhp 3 years ago
- storage: document Windows projected volume limitations xref: https://github.com/kubernetes/kubernetes/issues/102849 — committed to ptux/website by aravindhp 3 years ago
- storage: document Windows projected volume limitations xref: https://github.com/kubernetes/kubernetes/issues/102849 — committed to kevindelgado/kubernetes.github.io by aravindhp 3 years ago
- removed security context for windows daemonsets as of Kubernetes 1.21 windows pods have issues with \ RunAsUser security context. As a workaround the security context is removed until windows and kub... — committed to logzio/logzio-helm by tamir-michaeli 3 years ago
We don’t have a clear long-term solution to issue. There has been some discussions to fix this at the OS layer but there are no timelines. /milestone clear
Hi @jyotimahapatra. This is not on track to be fixed in the 1.24 time frame. We shouldn’t add this to a milestone until https://github.com/microsoft/Windows-Containers/issues/136 is resolved.
/sig windows