Skip to main content


OpenShift Security Context Constraint (SCC)

Security context constraints allow administrators to control permissions for pods in a cluster. A service account provides an identity for processes that run in a pod. The default service account is used to run applications within a project. You can run other applications in the same project, but if you don't necessarily want to override the privileges used for all applications, create a new service account that can be granted the special rights in the project where the application is to be run. For example run install litmus-admin service account.

$ oc apply -f

serviceaccount/litmus-admin created created created

The next step is to run the service account as a cluster administrator. It is the granting of the appropriate rights to the service account. This is done by specifying that the service account should run with a specific security context constraint (SCC).

As an administrator, you can see the list of SCCs defined in the cluster by running the oc get scc command.

$ oc get scc --as system:admin

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]
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]

By default, applications would run under the restricted SCC. You can use the default SCC or create your own SCC to provide the HCE experiment service account (here litmus-admin) to run all the experiments. Here is one such SCC that can be used:

kind: SecurityContextConstraints
# To mount the socket path directory in helper pod
allowHostDirVolumePlugin: true
allowHostIPC: false
allowHostNetwork: false
# To run fault injection on a target container using pid namespace.
# It is used in stress, network, dns and http experiments.
allowHostPID: true
allowHostPorts: false
allowPrivilegeEscalation: true
# To run some privileged modules in dns, stress and network chaos
allowPrivilegedContainer: true
# NET_ADMIN & SYS_ADMIN: used in network chaos experiments to perform
# network operations (running tc command in network ns of target container).
# SYS_ADMIN: used in stress chaos experiment to perform cgroup operations.
defaultAddCapabilities: null
type: MustRunAs
groups: []
name: litmus-scc
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: null
type: RunAsAny
type: MustRunAs
type: RunAsAny
- system:serviceaccount:litmus:argo
# To allow configmaps mounts on upload scripts or envs.
- configMap
# To derive the experiment pod name in the experimemnt.
- downwardAPI
# used for chaos injection like io chaos.
- emptyDir
- hostPath
- persistentVolumeClaim
- projected
# To authenticate with different cloud providers
- secret

Install the SCC:

$ oc create -f litmus-scc.yaml created

Now to associate the new service account with the SCC, run the given command:

$ oc adm policy add-scc-to-user litmus-scc -z litmus-admin --as system:admin -n litmus added: "litmus-admin"

The -z option indicates to apply the command to the service account in the current project. To add-scc-to-user add the name of SCC. Provide the namespace of the target service account after -n.