OpenShift - List Security Context Constraints using the oc get securitycontextcontraints command

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

Role Bindings and Security Context Constraint are similar in that they both are access control mechanisms.

  • Role Bindings are used to control what an OpenShift Users are allowed to do
  • Security Context Constraints are used to control what pods are allowed to do

A Security Context Constraint is used to control certain things that a deployment or pod is allowed or not allowed to do, such as mounting a host volume. Typically, a Security Context Constraint (SCC) is associated with a Service Account. Check out my article Run a deployment with a Service Account and Security Context Constraint.

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.

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 Buy Me A Coffee

Add a Comment




We will never share your name or email with anyone. Enter your email if you would like to be notified when we respond to your comment.





Please enter b9730 in the box below so that we can be sure you are a human.




Comments

Web design by yours truely - me, myself, and I   |   jeremy.canfield@freekb.net   |