You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 11, 2023. It is now read-only.
Is this an ISSUE or FEATURE REQUEST? (choose one): ISSUE
What version of acs-engine?: v0.12
Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes
What happened:
I tried to install a helm chart (z2jh.jupyter.org) that has been working fine on same k8s version created with older acs-engine versions, and I expected it to work. It did not, and when more digging was performed, it turned out that:
The chart contained a deployment that explicitly specified a non-0 uid (1000) to run
However, per this patch (Adopt CIS Kubernetes Benchmark, Part 1: API Server. #1989), the SecurityContextDeny admission controller was enabled by default. This means that pods that set any uid will fail, and by default this means that you can only run pods that run all containers as root.
SecurityContextDeny seems to operate outside the scope of PodSecurityPolicies as well, so am actually unsure how to get around this? I've temporarily edited /etc/kubernetes/manifests to remove SecurityContextDeny from the list of admission controllers.
What you expected to happen:
One of:
It continues to work as it did before
A detailed note in the release notes saying SecurityContextDeny is now a default admission controller, the ramifications for this, how to disable it if necessary, and how to allow specific UIDs to run.
How to reproduce it (as minimally and precisely as possible):
Run a pod that explicitly specifies a non 0 uid to run.
Anything else we need to know:
IMO, PodSecurityPolicies are a much better security mechanism than SecurityContextDeny, and SecurityContextDeny should not be a default. The same effect can be achieved with a restrictive PSP by default instead, if desired.
The text was updated successfully, but these errors were encountered:
@yuvipanda Please refer to this comment (#1989 (comment)) as a way to disable SecurityContextDeny setting for now.
I am reading into documents about PSP to see if removing SecurityContextDeny would provide better customer experience. Will update shortly on this. Thanks!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution. Note that acs-engine is deprecated--see https://github.com/Azure/aks-engine instead.
Is this a request for help?: No
Is this an ISSUE or FEATURE REQUEST? (choose one): ISSUE
What version of acs-engine?: v0.12
Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes
What happened:
I tried to install a helm chart (z2jh.jupyter.org) that has been working fine on same k8s version created with older acs-engine versions, and I expected it to work. It did not, and when more digging was performed, it turned out that:
SecurityContextDeny seems to operate outside the scope of PodSecurityPolicies as well, so am actually unsure how to get around this? I've temporarily edited /etc/kubernetes/manifests to remove SecurityContextDeny from the list of admission controllers.
What you expected to happen:
One of:
How to reproduce it (as minimally and precisely as possible):
Run a pod that explicitly specifies a non 0 uid to run.
Anything else we need to know:
IMO, PodSecurityPolicies are a much better security mechanism than SecurityContextDeny, and SecurityContextDeny should not be a default. The same effect can be achieved with a restrictive PSP by default instead, if desired.
The text was updated successfully, but these errors were encountered: