$ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=false
Pod security admission is an implementation of the Kubernetes pod security standards. Use pod security admission to restrict the behavior of pods.
Pod security admission standards and security context constraints are reconciled and enforced by two independent controllers. The two controllers work independently using the following processes to enforce security policies:
The security context constraint controller may mutate some security context fields per the pod’s assigned SCC. For example, if the seccomp profile is empty or not set and if the pod’s assigned SCC enforces seccompProfiles
field to be runtime/default
, the controller sets the default type to RuntimeDefault
.
The security context constraint controller validates the pod’s security context against the matching SCC.
The pod security admission controller validates the pod’s security context against the pod security standard assigned to the namespace.
OpenShift Container Platform includes Kubernetes pod security admission. Globally, the privileged
profile is enforced, and the restricted
profile is used for warnings and audits.
In addition to the global pod security admission control configuration, a controller exists that applies pod security admission control warn
and audit
labels to namespaces according to the SCC permissions of the service accounts that are in a given namespace.
Namespaces that are defined as part of the cluster payload have pod security admission synchronization disabled permanently. You can enable pod security admission synchronization on other namespaces as necessary. If an Operator is installed in a user-created |
The controller examines ServiceAccount
object permissions to use security context constraints in each namespace. Security context constraints (SCCs) are mapped to pod security profiles based on their field values; the controller uses these translated profiles. Pod security admission warn
and audit
labels are set to the most privileged pod security profile found in the namespace to prevent warnings and audit logging as pods are created.
Namespace labeling is based on consideration of namespace-local service account privileges.
Applying pods directly might use the SCC privileges of the user who runs the pod. However, user privileges are not considered during automatic labeling.
You can enable or disable automatic pod security admission synchronization for most namespaces.
Namespaces that are defined as part of the cluster payload have pod security admission synchronization disabled permanently. These namespaces include:
By default, all namespaces that have an If an Operator is installed in a user-created |
For each namespace that you want to configure, set a value for the security.openshift.io/scc.podSecurityLabelSync
label:
To disable pod security admission label synchronization in a namespace, set the value of the security.openshift.io/scc.podSecurityLabelSync
label to false
.
Run the following command:
$ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=false
To enable pod security admission label synchronization in a namespace, set the value of the security.openshift.io/scc.podSecurityLabelSync
label to true
.
Run the following command:
$ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=true
A PodSecurityViolation
alert is triggered when the Kubernetes API server reports that there is a pod denial on the audit level of the pod security admission controller. This alert persists for one day.
View the Kubernetes API server audit logs to investigate alerts that were triggered. As an example, a workload is likely to fail admission if global enforcement is set to the restricted
pod security level.
For assistance in identifying pod security admission violation audit events, see Audit annotations in the Kubernetes documentation.
The PodSecurityViolation
alert does not provide details on which workloads are causing pod security violations. You can identify the affected workloads by reviewing the Kubernetes API server audit logs. This procedure uses the must-gather
tool to gather the audit logs and then searches for the pod-security.kubernetes.io/audit-violations
annotation.
You have installed jq
.
You have access to the cluster as a user with the cluster-admin
role.
To gather the audit logs, enter the following command:
$ oc adm must-gather -- /usr/bin/gather_audit_logs
To output the affected workload details, enter the following command:
$ zgrep -h pod-security.kubernetes.io/audit-violations must-gather.local.<archive_id>/<image_digest_id>/audit_logs/kube-apiserver/*log.gz \
| jq -r 'select((.annotations["pod-security.kubernetes.io/audit-violations"] != null) and (.objectRef.resource=="pods")) | .objectRef.namespace + " " + .objectRef.name' \
| sort | uniq -c
Replace <archive_id>
and <image_digest_id>
with the actual path names.
1 test-namespace my-pod