Chapter 16. Managing Security Context Constraints
16.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
Docker has a default list of capabilities that are allowed for each container of a pod. 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
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.
The cluster contains eight default SCCs:
If additional workloads are run on master hosts, use caution when providing access to
hostnetwork. A workload that runs
hostnetworkon a master host is effectively root on the cluster and must be trusted accordingly.
Do not modify the default SCCs. Customizing the default SCCs can lead to issues when OpenShift Container Platform is upgraded. Instead, create new SCCs.
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
- 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:
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:
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
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.
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.
SupplementalGroups SCC strategy of
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.
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.
16.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.
16.2. About pre-allocated Security Context Constraints values
The admission controller is aware of certain conditions in the Security Context Constraints (SCCs) that trigger it to look up pre-allocated values from a namespace and populate the SCC before processing the pod. Each SCC strategy is evaluated independently of other strategies, with the pre-allocated values, where allowed, for each policy aggregated with pod specification values to make the final values for the various IDs defined in the running pod.
The following SCCs cause the admission controller to look for pre-allocated values when no ranges are defined in the pod specification:
MustRunAsRangewith no minimum or maximum set. Admission looks for the
openshift.io/sa.scc.uid-rangeannotation to populate range fields.
MustRunAswith no level set. Admission looks for the
openshift.io/sa.scc.mcsannotation to populate the level.
MustRunAs. Admission looks for the
MustRunAs. Admission looks for the
During the generation phase, the security context provider uses default values for any parameter values that are not specifically set in the pod. Default values are based on the selected strategy:
MustRunAsNonRootstrategies do not provide default values. If the pod needs a parameter value, such as a group ID, you must define the value in the pod specification.
MustRunAs(single value) strategies provide a default value that is always used. For example, for group IDs, even if the pod specification defines its own ID value, the namespace’s default parameter value also appears in the pod’s groups.
MustRunAs(range-based) strategies provide the minimum value of the range. As with a single value
MustRunAsstrategy, the namespace’s default parameter value appears in the running pod. If a range-based strategy is configurable with multiple ranges, it provides the minimum value of the first configured range.
SupplementalGroups strategies fall back to the
openshift.io/sa.scc.uid-range annotation if the
openshift.io/sa.scc.supplemental-groups annotation does not exist on the namespace. If neither exists, the SCC is not created.
By default, the annotation-based
FSGroup strategy configures itself with a single range based on the minimum value for the annotation. For example, if your annotation reads
FSGroup strategy configures itself with a minimum and maximum value of
1. If you want to allow more groups to be accepted for the
FSGroup field, you can configure a custom SCC that does not use the annotation.
openshift.io/sa.scc.supplemental-groups annotation accepts a comma-delimited list of blocks in the format of
openshift.io/sa.scc.uid-range annotation accepts only a single block.
16.3. Example Security Context Constraints
The following examples show the Security Context Constraint (SCC) format and annotations:
allowHostDirVolumePlugin: true allowHostIPC: true allowHostNetwork: true allowHostPID: true allowHostPorts: true allowPrivilegedContainer: true allowedCapabilities: 1 - '*' apiVersion: security.openshift.io/v1 defaultAddCapabilities:  2 fsGroup: 3 type: RunAsAny groups: 4 - system:cluster-admins - system:nodes kind: SecurityContextConstraints metadata: annotations: kubernetes.io/description: 'privileged allows access to all privileged and host features and the ability to run as any user, any group, any fsGroup, and with any SELinux context. WARNING: this is the most relaxed SCC and should be used only for cluster administration. Grant with caution.' creationTimestamp: null name: privileged priority: null readOnlyRootFilesystem: false requiredDropCapabilities:  5 runAsUser: 6 type: RunAsAny seLinuxContext: 7 type: RunAsAny seccompProfiles: - '*' supplementalGroups: 8 type: RunAsAny users: 9 - system:serviceaccount:default:registry - system:serviceaccount:default:router - system:serviceaccount:openshift-infra:build-controller volumes: - '*'
- A list of capabilities that a pod can request. An empty list means that none of capabilities can be requested while the special symbol
*allows any capabilities.
- A list of additional capabilities that are added to any pod.
FSGroupstrategy, which dictates the allowable values for the Security Context.
- The groups that can access this SCC.
- A list of capabilities that are be dropped from a pod.
runAsUserstrategy type, which dictates the allowable values for the Security Context.
seLinuxContextstrategy type, which dictates the allowable values for the Security Context.
supplementalGroupsstrategy, which dictates the allowable supplemental groups for the Security Context.
- The users who can access this SCC.
groups fields on the SCC control which users can access the SCC. By default, cluster administrators, nodes, and the build controller are granted access to the privileged SCC. All authenticated users are granted access to the restricted SCC.
apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: securityContext: 1 containers: - name: sec-ctx-demo image: gcr.io/google-samples/node-hello:1.0
- When a container or pod does not request a user ID under which it should be run, the effective UID depends on the SCC that emits this pod. Because restricted SCC is granted to all authenticated users by default, it will be available to all users and service accounts and used in most cases. The restricted SCC uses
MustRunAsRangestrategy for constraining and defaulting the possible values of the
securityContext.runAsUserfield. The admission plug-in will look for the
openshift.io/sa.scc.uid-rangeannotation on the current project to populate range fields, as it does not provide this range. In the end, a container will have
runAsUserequal to the first value of the range that is hard to predict because every project has different ranges.
apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: securityContext: runAsUser: 1000 1 containers: - name: sec-ctx-demo image: gcr.io/google-samples/node-hello:1.0
- A container or pod that requests a specific user ID will be accepted by OpenShift Container Platform only when a service account or a user is granted access to a SCC that allows such a user ID. The SCC can allow arbitrary IDs, an ID that falls into a range, or the exact user ID specific to the request.
This configuration is valid for SELinux, fsGroup, and Supplemental Groups.
16.4. Creating Security Context Constraints
You can create a Security Context Constraint (SCC) by using the CLI.
You must install the
Your account must have
cluster-adminprivileges to create SCCs.
Define the SCC in a JSON or YAML file:
Security Context Constraint Object Definition
kind: SecurityContextConstraints apiVersion: security.openshift.io/v1 metadata: name: scc-admin allowPrivilegedContainer: true runAsUser: type: RunAsAny seLinuxContext: type: RunAsAny fsGroup: type: RunAsAny supplementalGroups: type: RunAsAny users: - my-admin-user groups: - my-admin-group
Optionally, you can add drop capabilities to an SCC by setting the
requiredDropCapabilitiesfield with the desired values. Any specified capabilities will be dropped from the container. For example, to create an SCC with the
SYS_CHROOTrequired drop capabilities, add the following to the SCC object:
requiredDropCapabilities: - KILL - MKNOD - SYS_CHROOT
You can see the list of possible values in the Docker documentation.Tip
Because capabilities are passed to the Docker, you can use a special
ALLvalue to drop all possible capabilities.
oc createpassing the file to create it:
$ oc create -f scc_admin.yaml securitycontextconstraints "scc-admin" created
Verify that the SCC was created:
$ oc get scc scc-admin NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES scc-admin true  RunAsAny RunAsAny RunAsAny RunAsAny <none> false [awsElasticBlockStore azureDisk azureFile cephFS cinder configMap downwardAPI emptyDir fc flexVolume flocker gcePersistentDisk gitRepo glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk quobyte rbd secret vsphere]
16.5. Role-based access to Security Context Constraints
You can specify SCCs as resources that are handled by RBAC. This allows you to scope access to your SCCs to a certain project or to the entire cluster. Assigning users, groups, or service accounts directly to an SCC retains cluster-wide scope.
You cannot assign a SCC to pods created in one of the default namespaces:
openshift. These namespaces should not be used for running pods or services.
To include access to SCCs for your role, specify the
scc resource when creating a role.
$ oc create role <role-name> --verb=use --resource=scc --resource-name=<scc-name> -n <namespace>
This results in the following role definition:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: ... name: role-name 1 namespace: namespace 2 ... rules: - apiGroups: - security.openshift.io 3 resourceNames: - scc-name 4 resources: - securitycontextconstraints 5 verbs: 6 - use
- The role’s name.
- Namespace of the defined role. Defaults to
defaultif not specified.
- The API group that includes the SecurityContextConstraint resource. Automatically defined when
sccis specified as a resource.
- An example name for an SCC you want to have access.
- Name of the resource group that allows users to specify SCC names in the
- A list of verbs to apply to the role.
A local or cluster role with such a rule allows the subjects that are bound to it with a RoleBinding or a ClusterRoleBinding to use the user-defined SCC called
Because RBAC is designed to prevent escalation, even project administrators will be unable to grant access to an SCC. By defualt, they are not allowed to use the verb
use on SCC resources, including the
16.6. Security Context Constraints reference commands
You can manage SCCs in your instance as normal API objects using the CLI.
You must have
cluster-admin privileges to manage SCCs.
Do not modify the default SCCs. Customizing the default SCCs can lead to issues when upgrading. Instead, create new SCCs.
16.6.1. Listing SCCs
To get a current list of SCCs:
$ oc get scc NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES anyuid false  MustRunAs RunAsAny RunAsAny RunAsAny 10 false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] hostaccess false  MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret] hostmount-anyuid false  MustRunAs RunAsAny RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret] hostnetwork false  MustRunAs MustRunAsRange MustRunAs MustRunAs <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] node-exporter false  RunAsAny RunAsAny RunAsAny RunAsAny <none> false [*] nonroot false  MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] privileged true [*] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [*] restricted false  MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
16.6.2. Examining an SCC
You can view information about a particular SCC, including which users, service accounts, and groups the SCC is applied to.
For example, to examine the
$ oc describe scc restricted Name: restricted Priority: <none> Access: Users: <none> 1 Groups: system:authenticated 2 Settings: Allow Privileged: false Default Add Capabilities: <none> Required Drop Capabilities: KILL,MKNOD,SYS_CHROOT,SETUID,SETGID Allowed Capabilities: <none> Allowed Seccomp Profiles: <none> Allowed Volume Types: configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret Allow Host Network: false Allow Host Ports: false Allow Host PID: false Allow Host IPC: false Read Only Root Filesystem: false Run As User Strategy: MustRunAsRange UID: <none> UID Range Min: <none> UID Range Max: <none> SELinux Context Strategy: MustRunAs User: <none> Role: <none> Type: <none> Level: <none> FSGroup Strategy: MustRunAs Ranges: <none> Supplemental Groups Strategy: RunAsAny Ranges: <none>
To preserve customized SCCs during upgrades, do not edit settings on the default SCCs.
16.6.3. Deleting an SCC
To delete an SCC:
$ oc delete scc <scc_name>
If you delete a default SCC, it will regenerate when you restart the cluster.
16.6.4. Updating an SCC
To update an existing SCC:
$ oc edit scc <scc_name>
To preserve customized SCCs during upgrades, do not edit settings on the default SCCs.