In addition to authorization policies that control what a user
can do, OpenShift provides security context constraints (SCC) that control the
actions that a pod can
perform and what it has the ability to access. Administrators can
manage SCCs using the CLI.
SCCs are objects that define a set of conditions that a pod must run with in
order to be accepted into the system. They allow an administrator to control the
Capabilities a container can request to be added.
Use of host directories as volumes.
The SELinux context of the container.
The user ID.
Two SCCs are added to the cluster by default, privileged and restricted,
which are viewable by cluster administrators using the CLI:
$ oc get scc
NAME PRIV CAPS HOSTDIR SELINUX RUNASUSER
privileged true  true RunAsAny RunAsAny
restricted false  false MustRunAs MustRunAsRange
The definition for each SCC is also viewable by cluster administrators using the
CLI. For example, for the privileged SCC:
# oc export scc/privileged
type: RunAsAny (2)
type: RunAsAny (3)
|The groups that have access to this SCC
|The run as user strategy type which dictates the allowable values for the Security Context
|The SELinux context strategy type which dictates the allowable values for the Security Context
|The users who have access to this SCC
groups fields on the SCC control which SCCs can be used.
By default, cluster administrators, nodes, and the build controller are granted
access to the privileged SCC. All authenticated users are granted access to the
allows privileged pods.
allows host directories to be mounted as volumes.
allows a pod to run as any user.
allows a pod to run with any MCS label.
ensures pods cannot run as privileged.
ensures pods cannot use 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.
SCCs are comprised 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,
AllowPrivilegedContainer is always set to false if unspecified.
Controlled by an allowable set
Fields of this type are checked against the set to ensure their value is
Controlled by a strategy
Items that have a strategy to generate a value provide:
A mechanism to generate the value, and
A mechanism to ensure that a specified value falls into the set of allowable
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
Retrieve all SCCs available for use.
Generate field values for any security context setting that was 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.