Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 16. Understanding and managing pod security admission

Pod security admission is an implementation of the Kubernetes pod security standards. Use pod security admission to restrict the behavior of pods.

16.1. Security context constraint synchronization with pod security standards
Copia collegamento

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.

Important

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.

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.

16.2. Controlling pod security admission synchronization
Copia collegamento

You can enable or disable automatic pod security admission synchronization for most namespaces.

Important

Namespaces that are defined as part of the cluster payload have pod security admission synchronization disabled permanently. These namespaces include: 

  • default
     
  • kube-node-lease
     
  • kube-system
     
  • kube-public
     
  • openshift
  • All system-created namespaces that are prefixed with 
    openshift-
    , except for 
    openshift-operators

By default, all namespaces that have an 

openshift-
prefix are not synchronized. You can enable synchronization for any user-created 
openshift-*
namespaces. You cannot enable synchronization for any system-created 
openshift-*
namespaces, except for 
openshift-operators
.

Procedure

  • 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 sychronization 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 sychronization 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

16.3. About pod security admission alerts
Copia collegamento

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.

16.3.1. Identifying pod security violations
Copia collegamento

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.

Prerequisites

  • You have installed 
    jq
    .
  • You have access to the cluster as a user with the 
    cluster-admin
    role.

Procedure

  1. To gather the audit logs, enter the following command: 

    $ oc adm must-gather -- /usr/bin/gather_audit_logs

  2. To output the affected workload details, enter the following command: 

    $ zgrep -h pod-security.kubernetes.io/audit-violations must-gather.local.<archive_id>/quay*/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 + " " + .objectRef.resource' \
  | sort | uniq -c

    Replace 

    must-gather.local.<archive_id>
    with the actual directory name.

    Example output

    15 ci namespace-ttl-controller deployments
 1 ci-op-k5whzrsh rpm-repo-546f98d8b replicasets
 1 ci-op-k5whzrsh rpm-repo deployments

Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red HatTorna in cima