- Status: superseded by ADR-0040
- Deciders: Cristian, Lars, Olle
- Date: 2021-08-23
Context and Problem Statement¶
OpenShift likes to shift (pun intended) the UID -- i.e., assign arbitrary UIDs -- to containers. They do this as an additional security feature, given that OpenShift is a multi-tentant Kubernetes solution. Each OpenShift project received a non-overlapping UID range. Hence, in case an attacker escapes a container, it will be more difficult to interfere with other processes.
However, this shifting of UIDs introduces an additional complexity: What if a process wants to write to the filesystem? What uid, gid and permissions should the files and folders have? To solve this problem, the OpenShift documentation (see "Support arbitrary user ids") recommends setting gid=0 on those files and folders. Specifically, the Dockerfiles of the container images should contain:
RUN chgrp -R 0 /some/directory && chmod -R g=u /some/directory
During execution, OpenShift assigns
gid=0 as a supplementary group to containers, so as to give them access to the required files.
In contrast to OpenShift, Compliant Kubernetes is not a multi-tenant solution. Given previous vulnerabilities in Kubernetes that affected tenant isolation (e.g., CVE-2020-8554
), we believe that non-trusting users should not share a Workload Cluster. Hence, we do not assign arbitrary UIDs to containers and do not need to assign
gid=0 as a supplementary group.
gid=0 practice above seems to have made its way in quite a few Dockerfiles, however, it is far from being the default outside OpenShift.
What should Compliant Kubernetes do with the
- For user expectations, we want to make it easy to start with Compliant Kubernetes.
- For better security and easier audits, we do not want to add unnecessary permissions.
- ID mapping in mounts has landed in Linux 5.12. Once this feature is used in container runtimes and Kubernetes, the
gid=0problem will go away.
gid=0by default -- this is what Kubespray does.
- Never allow
Chosen option: "disallow
gid=0 by default". Enabling it on a case-by-case basis is okay.
- We do not unnecessarily add a permission to containers.
- Some users will complain about their container images not starting, and we will need to add a less restricted PodSecurityPolicy in their cluster.
PodSecurityPolicies are deprecated in favor of PodSecurity Admission. This decision will have to be revisited once PodSecurity Admission is stable.
In case we notice that the
gid=0 practice is gaining significant uptake, we will have to revisit this decision to allow
gid=0 by default.
In case ID mapping is implemented in container runtimes and Kubernetes, this problem will likely go away. In that case, this decision might be revisited to never allow