第 12 章 Managing security context constraints
12.1. About security context constraints
Similar to the way that RBAC resources control user access, administrators can use security context constraints (SCCs) to control permissions for pods. These permissions include actions that a pod, a collection of containers, can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with in order to be accepted into the system.
SCCs allow an administrator to control:
- Whether a pod can run privileged containers.
- The capabilities that a container can request.
- The use of host directories as volumes.
- The SELinux context of the container.
- The container user ID.
- The use of host namespaces and networking.
-
The allocation of an
FSGroupthat owns the pod’s volumes. - The configuration of allowable supplemental groups.
- Whether a container requires the use of a read only root file system.
- The usage of volume types.
-
The configuration of allowable
seccompprofiles.
The cluster contains eight default SCCs:
-
anyuid -
hostaccess -
hostmount-anyuid hostnetwork警告If additional workloads are run on master hosts, use caution when providing access to
hostnetwork. A workload that runshostnetworkon a master host is effectively root on the cluster and must be trusted accordingly.-
node-exporter -
nonroot -
privileged -
restricted
Do not modify the default SCCs. Customizing the default SCCs can lead to issues when OpenShift Container Platform is upgraded. Instead, create new SCCs.
The privileged SCC allows:
- Users to run privileged pods
- Pods to mount host directories as volumes
- Pods to run as any user
- Pods to run with any MCS label
- Pods to use the host’s IPC namespace
- Pods to use the host’s PID namespace
- Pods to use any FSGroup
- Pods to use any supplemental group
- Pods to use any seccomp profiles
- Pods to request any capabilities
The restricted SCC:
- Ensures that pods cannot run as privileged.
- Ensures that pods cannot mount host directory volumes.
- Requires that a pod run as a user in a pre-allocated range of UIDs.
- Requires that a pod run with a pre-allocated MCS label.
- Allows pods to use any FSGroup.
- Allows pods to use any supplemental group.
For more information about each SCC, see the kubernetes.io/description annotation available on the SCC.
SCCs are composed of settings and strategies that control the security features a pod has access to. These settings fall into three categories:
| Category | Description |
|---|---|
| Controlled by a boolean |
Fields of this type default to the most restrictive value. For example, |
| Controlled by an allowable set | Fields of this type are checked against the set to ensure their value is allowed. |
| Controlled by a strategy | Items that have a strategy to generate a value provide:
|
CRI-O has the following default list of capabilities that are allowed for each container of a pod:
-
CHOWN -
DAC_OVERRIDE -
FSETID -
FOWNER -
SETGID -
SETUID -
SETPCAP -
NET_BIND_SERVICE -
KILL
The containers use the capabilities from this default list, but pod manifest authors can alter it by requesting additional capabilities or removing some of the default behaviors. Use the allowedCapabilities, defaultAddCapabilities, and requiredDropCapabilities parameters to control such requests from the pods and to dictate which capabilities can be requested, which ones must be added to each container, and which ones must be forbidden.
12.1.1. SCC Strategies
RunAsUser
-
MustRunAs- Requires arunAsUserto be configured. Uses the configuredrunAsUseras the default. Validates against the configuredrunAsUser. -
MustRunAsRange- Requires minimum and maximum values to be defined if not using pre-allocated values. Uses the minimum as the default. Validates against the entire allowable range. -
MustRunAsNonRoot- Requires that the pod be submitted with a non-zerorunAsUseror have theUSERdirective defined in the image. No default provided. -
RunAsAny- No default provided. Allows anyrunAsUserto be specified.
SELinuxContext
-
MustRunAs- RequiresseLinuxOptionsto be configured if not using pre-allocated values. UsesseLinuxOptionsas the default. Validates againstseLinuxOptions. -
RunAsAny- No default provided. Allows anyseLinuxOptionsto be specified.
SupplementalGroups
-
MustRunAs- Requires at least one range to be specified if not using pre-allocated values. Uses the minimum value of the first range as the default. Validates against all ranges. -
RunAsAny- No default provided. Allows anysupplementalGroupsto be specified.
FSGroup
-
MustRunAs- Requires at least one range to be specified if not using pre-allocated values. Uses the minimum value of the first range as the default. Validates against the first ID in the first range. -
RunAsAny- No default provided. Allows anyfsGroupID to be specified.
12.1.2. Controlling volumes
The usage of specific volume types can be controlled by setting the volumes field of the SCC. The allowable values of this field correspond to the volume sources that are defined when creating a volume:
-
azureFile -
azureDisk -
flocker -
flexVolume -
hostPath -
emptyDir -
gcePersistentDisk -
awsElasticBlockStore -
gitRepo -
secret -
nfs -
iscsi -
glusterfs -
persistentVolumeClaim -
rbd -
cinder -
cephFS -
downwardAPI -
fc -
configMap -
vsphereVolume -
quobyte -
photonPersistentDisk -
projected -
portworxVolume -
scaleIO -
storageos - * (a special value to allow the use of all volume types)
-
none(a special value to disallow the use of all volumes types. Exist only for backwards compatibility)
The recommended minimum set of allowed volumes for new SCCs are configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.
The list of allowable volume types is not exhaustive because new types are added with each release of OpenShift Container Platform.
For backwards compatibility, the usage of allowHostDirVolumePlugin overrides settings in the volumes field. For example, if allowHostDirVolumePlugin is set to false but allowed in the volumes field, then the hostPath value will be removed from volumes.
12.1.3. Admission
Admission control with SCCs allows for control over the creation of resources based on the capabilities granted to a user.
In terms of the SCCs, this means that an admission controller can inspect the user information made available in the context to retrieve an appropriate set of SCCs. Doing so ensures the pod is authorized to make requests about its operating environment or to generate a set of constraints to apply to the pod.
The set of SCCs that admission uses to authorize a pod are determined by the user identity and groups that the user belongs to. Additionally, if the pod specifies a service account, the set of allowable SCCs includes any constraints accessible to the service account.
Admission uses the following approach to create the final security context for the pod:
- Retrieve all SCCs available for use.
- Generate field values for security context settings that were not specified on the request.
- Validate the final settings against the available constraints.
If a matching set of constraints is found, then the pod is accepted. If the request cannot be matched to an SCC, the pod is rejected.
A pod must validate every field against the SCC. The following are examples for just two of the fields that must be validated:
These examples are in the context of a strategy using the preallocated values.
A FSGroup SCC strategy of MustRunAs
If the pod defines a fsGroup ID, then that ID must equal the default fsGroup ID. Otherwise, the pod is not validated by that SCC and the next SCC is evaluated.
If the SecurityContextConstraints.fsGroup field has value RunAsAny and the pod specification omits the Pod.spec.securityContext.fsGroup, then this field is considered valid. Note that it is possible that during validation, other SCC settings will reject other pod fields and thus cause the pod to fail.
A SupplementalGroups SCC strategy of MustRunAs
If the pod specification defines one or more supplementalGroups IDs, then the pod’s IDs must equal one of the IDs in the namespace’s openshift.io/sa.scc.supplemental-groups annotation. Otherwise, the pod is not validated by that SCC and the next SCC is evaluated.
If the SecurityContextConstraints.supplementalGroups field has value RunAsAny and the pod specification omits the Pod.spec.securityContext.supplementalGroups, then this field is considered valid. Note that it is possible that during validation, other SCC settings will reject other pod fields and thus cause the pod to fail.
12.1.4. SCC prioritization
SCCs have a priority field that affects the ordering when attempting to validate a request by the admission controller. A higher priority SCC is moved to the front of the set when sorting. When the complete set of available SCCs are determined they are ordered by:
- Highest priority first, nil is considered a 0 priority
- If priorities are equal, the SCCs will be sorted from most restrictive to least restrictive
- If both priorities and restrictions are equal the SCCs will be sorted by name
By default, the anyuid SCC granted to cluster administrators is given priority in their SCC set. This allows cluster administrators to run pods as any user by without specifying a RunAsUser on the pod’s SecurityContext. The administrator may still specify a RunAsUser if they wish.
