Pod Security Admission

Kubernetes v1.22 and higher provides a built-in Pod Security Admission (PSA) controller allowing to restrict the behavior of pods.

NEW FEATURE
PSA is enabled by default since Kubernetes v1.23. Its predecessor, the PSP mechanism was removed from version v.1.25.

What is a Pod Security Admission?

A Pod Security Admission (PSA) is an admission controller that applies restrictions at the namespace level when pods are created.

Using PSA with Kublr

When the Pod Security Admission is enabled, for each namespace, you can create the label setting one of the policy LEVELS:

privileged
baseline
restricted

And reactions for exceeding them (MODE):

Mode	Description
`enforce`	Policy violations will cause the pod to be rejected.
`warn`	Policy violations will trigger a user-facing warning, but are otherwise allowed.
`audit`	Policy violations will trigger the addition of an audit annotation to the event recorded in the audit log, but are otherwise allowed.

pod-security.kubernetes.io/<MODE>: <LEVEL>

If the label is absent (Admission Configuration is not used), the Pod Security Admission will not react.

The PSA controls only Pods, thus if you create, for example, a new Deployment which Pods are restricted from launching then the Deployment and ReplicaSet will be created but the Pods will not be and the corresponding errors will be displayed in the log.

NOTE You can use PSP and PSA simultaneously, but this makes the cluster support more complicated and thus not recommended as a scenario for the daily use, but only for the period of migration from PSP to PSA.

Applying PSA to entire cluster

At the namespace level

Add label with the required permissions to each namespace. Before adding the label, you can test it by running the command with the dry-run flag to see possible conflicts with already existing Pods.

See tutorial on applying PSA on the namespace level in the Kubernetes documentation.

Approach disadvantages:

Namespaces without labels will not be restricted
User having full access for the namespace can delete the label and thus make a privileged Pod

Using AdmissionConfiguration

This approach allows specifying permissions to namespaces in the configuration file, not directly in the namespaces. Also, the exemptions for users and/or objects can be specified so that these objects/users will not be processed by PSA.

See example on using AdmissionConfiguration in the Kubernetes documentation.

Approach disadvantages:

Settings are stored not via the Kubernetes object, but via the configuration file, referred in the launch options of the kube-apiserver.
As the AdmissionConfiguration file is external to the cluster, it is necessary to synchronize its content in the multi-master configurations or provide access to the file from the single source in the network.

Combined approach example

Configurations on the namespace (NS) level and via AdmissionConfiguration (AC) can be combined. Consider the examples below.

AC	Exemptions	NS	Result
enforce:baseline	no	enforce:privileged	Privileged Pod in the NS will run as NS label has priority.
enforce:baseline	NS	enforce:baseline	Privileged pod in the NS will run as NS is exempted from security check by AC.
enforce:privileged	no	enforce:baseline	Privileged Pod will not run as NS label has priority.

Configuring PSA via cluster specification

From Kublr release 1.25, PSA is managed via the cluster specification:

kublr:
  psa:
    defaults:
      enforce: "privileged" or "baseline" or "restricted"
      audit: "privileged" or "baseline" or "restricted"
      warn: "privileged" or "baseline" or "restricted"
    exemptions:
      usernames: [Array of authenticated usernames to exempt.]
      runtimeClasses: [Array of runtime class names to exempt.]
      namespaces: [Array of namespaces to exempt.]

The defaults are:

kublr:
  psa:
    defaults:
      enforce: "privileged"
      audit: "privileged"
      warn: "privileged"
    exemptions:
      usernames: []
      runtimeClasses: []
      namespaces:
        - kublr
        - kube-system