Red Hat OpenShift Container Platform

Example security context constraints

The following examples show how to define and use security context constraints (SCCs) in your cluster.

Annotated privileged SCC

allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegedContainer: true
allowedCapabilities:
- '*'
apiVersion: security.openshift.io/v1
defaultAddCapabilities: []
fsGroup:
  type: RunAsAny
groups:
- 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: null
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups:
  type: RunAsAny
users:
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
- system:serviceaccount:openshift-infra:build-controller
volumes:
- '*'

where
allowedCapabilities: 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.
defaultAddCapabilities: A list of additional capabilities that are added to any pod.
fsGroup: The FSGroup strategy, which dictates the allowable values for the security context.
groups: The groups that can access this SCC.
requiredDropCapabilities: A list of capabilities to drop from a pod. Or, specify ALL to drop all capabilities.
runAsUser: The runAsUser strategy type, which dictates the allowable values for the security context.
seLinuxContext: The seLinuxContext strategy type, which dictates the allowable values for the security context.
supplementalGroups: The supplementalGroups strategy, which dictates the allowable supplemental groups for the security context.
users: The users who can access this SCC.
volumes: The allowable volume types for the security context. In the example, * allows the use of all volume types.

The users and 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-v2 SCC.

When verifying access to an SCC, be aware of the following command behaviors:

The oc adm policy who-can use scc <scc_name> and oc auth can-i use scc/<scc_name> commands evaluate only RBAC policies (RoleBinding or ClusterRoleBinding resources). Their output does not include users or groups configured directly in the SCC users and groups fields.
The oc describe scc <scc_name> command displays only the users and groups configured directly within the SCC object. Its output does not include access granted through RBAC policies.

Without explicit runAsUser setting

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
  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 the restricted-v2 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-v2 SCC uses MustRunAsRange strategy for constraining and defaulting the possible values of the securityContext.runAsUser field. The admission plugin will look for the openshift.io/sa.scc.uid-range annotation on the current project to populate range fields, as it does not provide this range. In the end, a container will have runAsUser equal to the first value of the range that is hard to predict because every project has different ranges.

With explicit runAsUser setting

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
  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 Red Hat 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.