If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

A Security Context Constraint is used to control certain things, such as:

• Whether or not a pod can be run as root
• Whether or not a pod can access the host OpenShift system
• Whether or not a pod can access the host OpenShift network

Typically, a Deployment is associated with a Service Account which has a certain Security Context Constraint (SCC) so that the pod runs with a certain Security Context Constraint (SCC).

Here is a start YAML file that can be used to create a Security Context Constraint.

The oc apply or oc create command with the -f or --filename option can be used to create the Security Context Constraint using the template JSON or YAML file.

The oc replace command can be used to replace a Security Context Constraint using a new or updated template JSON or YAML file.

The oc edit command can be used to update a Security Context Constraint template YAML file

kind: SecurityContextConstraints
apiVersion: v1
metadata:
  name: my-security-context-constraint
allowPrivilegedContainer: true
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
fsGroup:
  type: RunAsAny
supplementalGroups:
  type: RunAsAny
users:
- my-service-account
groups:
- my-group

Here are the default Security Context Constraints.

• anyuid - Same as the "restricted" Security Context Constraint but allows a pod to be run by any User ID (UID) or Group ID (GID). Check out my article on securityContext runAsUser and runAsGroup.
• hostaccess - Allows access to all host namespaces but still requires pods to be run with a User ID (UID) and SELinux context that are allocated to the namespace. Check out my article on securityContext runAsUser and runAsGroup.
• hostmount-anyuid - Same as the "restricted" Security Context Constraint but allows host mounts and running as any User ID (UID) or Group ID (GID). Check out my article on securityContext runAsUser and runAsGroup.
• hostnetwork - Allows using host networking and host ports but still requires pods to be run with a UID and SELinux context that are allocated to the namespace.
• nonroot - Same as the "restricted" Security Context Constraint but allows users to run with any non-root User ID (UID) or Group ID (GID). Check out my article on securityContext runAsUser and runAsGroup.
• privileged - 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
• restricted - Denies access to all host features and requires pods to be run with a User ID (UID), and SELinux context that are allocated to the namespace. This is the most restrictive SCC provided by a new installation and will be used by default for authenticated users.
  • Pods cannot run as privileged
  • Pods cannot mount host directory volumes (see Mount a local directory in a deployment and hostPath volumes are not allowed to be used)
  • Requires that a pod is run as a user in a pre-allocated range of User IDs (UIDs).
  • Requires that a pod is run with a pre-allocated MCS label
  • Allows pods to use any FSGroup
  • Allows pods to use any supplemental group