Technology Preview - Pod Security Admission Controller

Pod Security Admission (PSA) Controller is the PSP replacement, and this document describes the technical preview of PSA functionality which is ‘beta’ quality in K8S v1.23 .

The PSA admission controller acts on creation and modification of the pod and determines if it should be admitted based on the requested security context and the policies defined by Pod Security Standards.

Pod Security levels

Pod Security Admission levels refer to the 3 policies defined by the Pod Security Standards: privileged, baseline, and restricted.


Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations. It aims at system- and infrastructure-level workloads managed by privileged, trusted users.


Minimally restrictive policy which prevents known privilege escalations. It aims at ease of adoption for common containerized workloads for non-critical applications.


Heavily restricted policy, following current Pod hardening best practices. It is targeted at operators and developers of security-critical applications, as well as lower-trust users.

Pod Security Admission labels for namespaces

Pod security restrictions are applied at the namespace level.

With PSA feature enabled, namespaces can be configured to define the admission control mode to be used for pod security in each namespace. Kubernetes defines a set of labels to set predefined Pod Security levels for a namespace. The label will define what action the controller control plane takes if a potential violation is detected.

A namespace can configure any or all modes, or set different levels for different modes. The modes are:


Policy violations will cause the pod to be rejected.


Policy violations will trigger the addition of an audit annotation to the event recorded in the K8S audit log but are otherwise allowed.


Policy violations will trigger a user-facing warning but are otherwise allowed.

For each mode, there are two labels that determine the policy used.

This is a generic namespace configuration using labels.

# label indicates which policy level to apply for the mode.
# MODE must be one of `enforce`, `audit`, or `warn`.
# LEVEL must be one of `privileged`, `baseline`, or `restricted`.<MODE>: <LEVEL>

# Optional: per-mode version label can be used to pin the policy to the
# version that shipped with a given Kubernetes minor version (e.g. v1.23).
# MODE must be one of `enforce`, `audit`, or `warn`.
# VERSION must be a valid Kubernetes minor version, or `latest`.<MODE>-version: <VERSION>

For more information refer to

Enable Pod Security Admission

To enable PSA, PodSecurity feature gate must be enabled.

Starting with Kubernetes 1.23 version, PodSecurity feature gate is enabled by default.

For Kubernetes version 1.22, PodSecurity feature gate can be enabled using option feature-gates in bootstrap overrides file, localhost.yml. As the example shown below:

 feature-gates: "TTLAfterFinished=true,HugePageStorageMediumSize=true,RemoveSelfLink=false,MemoryManager=true,PodSecurity=true"

See Kubernetes Custom Configuration for more details on kubernetes configuration, apiserver_extra_args and apiserver_extra_volumes.

Configure defaults for the Pod Security Admission Controller

For the technology preview of the PSA controller, the PSA controller can be configured with default security polices and exemptions at bootstrap time.

The Default PSA controller configuration will apply to namespaces that are not configured with the labels to specify a security level and mode. For example if you display the namespace description using kubectl describe namespace <namespace> and the labels are not displayed, then the behavior of the namespace will follow the default PSA labels’ level, mode and version configuration set with PodSecurity plugin of the AdmissionConfiguration resource.

To configure cluster-wide default policies and/or exemptions, the PodSecurity plugin of the AdmissionConfiguration resource can be used. The AdmissionConfiguration resource is configurable at bootstrap time with the api-server_extra_args and apiserver_extra_volumes overrides in the localhost.yml file.

Any policy that is applied via namespace labels will take precedence.

Example of configuration added to localhost.yml:

  admission-control-config-file: "/etc/kubernetes/admission-control-config-file.yaml"

  - name: admission-control-config-file
    mountPath: "/etc/kubernetes/admission-control-config-file.yaml"
    pathType: "File"
    readOnly: true
    content: |
      kind: AdmissionConfiguration
      - name: PodSecurity
          kind: PodSecurityConfiguration
            enforce: "privileged"
            enforce-version: "latest"
            audit: "privileged"
            audit-version: "latest"
            warn: "privileged"
            warn-version: "latest"

See Kubernetes Custom Configuration for more details on kubernetes configuration, apiserver_extra_args and apiserver_extra_volumes.

The generic definition of the AdmissionConfiguration resource can be found at

Platform namespaces configuration

In preparation for PSA controller full support, namespace labels have been added to all the namespaces used by the platform. System namespaces, such as kube-system, deployment, as well as application namespaces such as, cert-manager have been created by default with privileged label levels.

The following labels configuration is applied by default to Platform namespaces:

controller-0:~$ kubectl describe namespace kube-system
Name:         kube-system

Annotations:  <none>
Status:       Active

No resource quota.

No LimitRange resource

Pod Security Admission Controller - Usage Example

This page walks through a usage example of PSA where you will:

  • Create a namespace for each of the 3 security policies levels: privileged, baseline and restricted.

  • Create a yaml file with a privileged pod configuration.

  • Create a privileged pod in all 3 namespaces.

  • The pod creation will only be successful in the privileged namespace.

controller-0:~$ vi baseline-ns.yaml
apiVersion: v1
kind: Namespace
 name: baseline-ns
 labels: baseline v1.23 baseline v1.23 baseline v1.23

controller-0:~$ kubectl apply -f baseline-ns.yaml

controller-0:~$ vi privileged-ns.yaml
apiVersion: v1
kind: Namespace
 name: privileged-ns
 labels: privileged v1.23 privileged v1.23 privileged v1.23

controller-0:~$ kubectl apply -f privileged-ns.yaml

controller-0:~$ vi restricted-ns.yaml
apiVersion: v1
kind: Namespace
 name: restricted-ns
 labels: restricted v1.23 restricted v1.23 restricted v1.23

controller-0:~$ kubectl apply -f restricted-ns.yaml

controller-0:~$ vi privileged-pod.yaml
apiVersion: v1
kind: Pod
 name: privileged
  - name: pause
     privileged: true

controller-0:~$ kubectl -n privileged-ns apply -f privileged-pod.yaml
pod/privileged created

controller-0:~$ kubectl -n baseline-ns apply -f privileged-pod.yaml
Error from server (Failure): error when creating "privileged-pod.yaml": privileged (container "pause" must not set securityContext.privileged=true)

controller-0:~$ kubectl -n restricted-ns apply -f privileged-pod.yaml
Error from server (Failure): error when creating "privileged-pod.yaml": privileged (container "pause" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "pause" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "pause" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "pause" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "pause" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

For more information refer to