This is combined with the UID to form the UID + GUID pair used to run a Linux process. The supplemental group IDs are regular Linux group IDs (GIDs). Any attempt by a Pod definition to specify a UID outside the assigned range will fail and requires special privileges. When a Pod is deployed into the namespace, by default, OpenShift will use the first UID and first GID from this range to run the Pod. The range of UIDs, GIDs, and SELinux MCS labels are unique to the project and there will not be overlap with the UIDs or GIDs assigned to other projects. The supplemental Groups IDs are used for controlling access to shared storage like NFS and GlusterFS, while the fsGroup is used for controlling access to block storage such as Ceph RBD, iSCSI, and some Cloud storage. By default, no range is explicitly defined for fsGroup, instead, by default, fsGroup is equal to the minimum value of the “openshift.io/sa.scc.supplemental-groups” annotation. User ID (UID) and Namespacesĭuring the creation of a project or namespace, OpenShift assigns a User ID (UID) range, a supplemental group ID (GID) range, and unique SELinux MCS labels to the project or namespace. This document describes the behavior and significance of the User ID (UIDs) from the Namespace perspective, from the Pods perspective and from the perspective of the workload in execution inside a Container.
In addition to this behavior, the Kubernetes Pod definition provides the ability to specify the UID under which the Pod should run. When a Pod is deployed to a project, by default, a unique UID is allocated and used to execute the Pod.
When the container is running there is an internal UID (the one perceived from within the container) and there is the host-level UID running the process that represents the Container. When designing a Containerfile/Dockerfile, there is an option to specify the User ID (UID) which will be used to execute the application inside the Container.
0 kommentar(er)
