By default, a container blocks its process from invoking protected functions. The security context (SC) must explicitly request access to perform functions such as:

• Run the process as a specific user or group
• Make the process a member of additional groups
• Run a privileged container
• Execute protected commands such as the KILL command

This diagram illustrates the components and process that allow an application to access resources:

1. A developer writes an application that needs access to protected functions
2. A deployer creates a deployment manifest to deploy the application with a pod spec that configures:
   • A security context (SC) (for the pod and/or for each container) that requests the access needed by the application, thereby requesting it
   • A service account to grant the requested access
3. An administrator assigns a security context constraint (SCC) to the service account that grants the requested access. The SCC can be assigned directly to the service account or indirectly via an RBAC role or group.
4. The SCC may be one of OpenShift’s predefined SCCs or it may be a custom SCC.
5. If the SCC grants the access, the admission process allows the pod to deploy and the pod configures the container as specified.

To confirm the current applied scc to the pods in a namespace, we can use this command:

$ export NAMESPACE=<pod namespace>
$ oc -n ${NAMESPACE} get pod -o 'custom-columns=NAME:metadata.name,APPLIED SCC:metadata.annotations.openshift\.io/scc'

Reference links

https://developer.ibm.com/learningpaths/secure-context-constraints-openshift/scc-tutorial/
https://developer.ibm.com/learningpaths/secure-context-constraints-openshift/intro/
https://access.redhat.com/solutions/6614691