
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).
The oc get securitycontextconstraints (or oc get scc) command can be used to list the Security Context Constraints.
~]$ oc get securitycontextconstraints
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES
anyuid false <no value> MustRunAs RunAsAny RunAsAny RunAsAny 10 false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
hostaccess false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","hostPath","persistentVolumeClaim","projected","secret"]
hostmount-anyuid false <no value> MustRunAs RunAsAny RunAsAny RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","hostPath","nfs","persistentVolumeClaim","projected","secret"]
hostnetwork false <no value> MustRunAs MustRunAsRange MustRunAs MustRunAs <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
nonroot false <no value> MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
privileged true ["*"] RunAsAny RunAsAny RunAsAny RunAsAny <no value> false ["*"]
restricted false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny <no value> false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
Each Security Context Constraint contains a list of things that are or are not permitted, and a Security Context Constraint would be bound to a User or Service Account, and then the User or Service Account would be associated with a deployment, as a way to control what the User or Service Account is or is not permitted to do with the deployment.
- anyuid - Same as the "restricted" Security Context Constraint but allows a pod to be run by any UID or GID.
- hostaccess - Allows access to all host namespaces but still requires pods to be run with a UID and SELinux context that are allocated to the namespace.
- hostmount-anyuid - Same as the "restricted" Security Context Constraint but allows host mounts and running as any UID and any GID on the system.
- 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 UID. The user must specify the UID or it must be specified in the manifest of the container runtime.
- 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 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 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
The oc describe securitycontextconstraint command can be used to show more details about a Security Context Constraint, including the Users and Groups the Security Context Constraint has been applied to. However, this output will not show the Service Accounts, which makes this a bit of an unreliable command.
~]$ oc describe scc anyuid
Name: anyuid
Priority: 10
Access:
Users: john.doe
Groups: system:cluster-admins
Once a Security Context Constraint (SCC) has been applied to a User, Group or Service Account, the Security Context Constraint will appear in the list of Cluster Role Bindings.
~]$ oc get clusterrolebindings | grep scc
NAME ROLE AGE
system:openshift:scc:restricted ClusterRole/system:openshift:scc:restricted 411s
And the Users, Groups and Service Accounts that have been applied to the Security Context Constraint (SCC) can be seen with the oc describe clusterrolebindings command.
~]$ oc describe clusterrolebindings system:openshift:scc:restricted
Name: system:openshift:scc:restricted
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: system:openshift:scc:restricted
Subjects:
Kind Name Namespace
---- ---- ---------
User john.doe my-project
Group my-group my-project
ServiceAccount my-service-account my-project
Did you find this article helpful?
If so, consider buying me a coffee over at