The set of SCCs that admission uses to authorize a pod are determined by the user identity and groups that the user belongs to.
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 the pod:
- Retrieve all SCCs available for use.
- Generate field values for security context settings that were 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.
A pod must validate every field against the SCC.
There should be at least one Security Context Constraint (SCC) defined which does not permit privileged containers.
If you need to run privileged containers, this should be defined in a separate SCC and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that SCC.
Make sure that the Allow Privileged field is set to false, when create a SCC.
Pods defined with spec.containers[].securityContext.privileged: true will not be permitted.
Default Value
By default, OpenShift 4 clusters include the following SCCs:
**`
anyuid. Allow Privileged: false
hostaccess. Allow Privileged: false
Hostmount-anyuid Allow Privileged: false
hostnetwork Allow Privileged: false
node-exporter Allow Privileged: true
non-root Allow Privileged: false
Privileged Allow Privileged: true
Restricted Allow Privileged: false
**`
Imported from SD Elements: https://redhat.sdelements.com/bunits/psse-secure-development/group-3-supporting-and-tooling-offering/openshift-zero-trust-workload-identity-manager/tasks/phase/deployment/311-T2001/