Pod Security Standard and Admissions

Overview

More Information

Pod Security Policy (PSP) and Pod Security Admission (PSA) were introduced by the Kubernetes Auth Special Interest Group (SIG). It is mainly used to govern the security of the pods in the Kubernetes cluster.

As Kubernetes evolves, the Pod Security Policy (PSP) is being deprecated and removed from Kubernetes v1.25. The Pod Security Standard (PSS) is a new way to enforce security policies (Pod) in Kubernetes clusters. It provides a set of baseline and restricted security profiles that can be applied to pods.

You can use any profiles in PSS with any modes in PSA.

Pod Security Standards (PSS)

Reference

https://kubernetes.io/docs/concepts/security/pod-security-standards/

The Pod Security Standards (PSS) are a set of security profiles that define the security requirements for pods in Kubernetes. The PSS is divided into three profiles:

Profile	Restrictiveness	Description
privileged	Unrestricted policy	This level allows all capabilities and does not restrict any security context settings. Allows for privilege escalations. Useful for system-wide programs like logging agents, storage drivers, etc that require privileged access.
baseline	Restricted policy	This level restricts the use of certain capabilities (e.g., hostPath, hostNetwork, hostIPC, hostPID) and encourages the use of security context settings like `readOnlyRootFilesystem` and `runAsNonRoot`. It is designed to prevent known privilege escalations while allowing common workloads to function. Suitable for most workloads.
restricted	Highly restricted policy	This level enforces strict security measures, such as disallowing privilege escalation, requiring `runAsNonRoot`, and restricting access to host namespaces and hostPath volumes. It follows best practices for hardening pods and is suitable for workloads requiring the highest level of security and isolation.

Pod Security Admission (PSA)

Reference

https://kubernetes.io/docs/concepts/security/pod-security-admission/

Pod Security Admission (PSA) is a built-in admission controller that enforces the Pod Security Standards. It is enabled by default in Kubernetes v1.25 and later. To verify if Pod Security Admission is enabled, you can check the kube-apiserver command line arguments. The --enable-admission-plugins flag should include PodSecurity.

kube-apiserver.yaml


apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver-kind-cluster-control-plane
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.89.0.2
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction,PodSecurity
    ...
    image: registry.k8s.io/kube-apiserver:v1.30.0

The Pod Security Admission got three modes to enforce the controls defined by the Pod Security Standards (PSS). A mode defines what happens to the pods that do not meet the Pod Security Standards. The three modes are:

Mode	Description	On violation
enforce	This mode enforces the Pod Security Standards. Pods that do not meet the policy requirements will be rejected.	Reject pod
audit	This mode audits the pods that do not meet the policy requirements. It will record the violations in the audit logs and the pod is allowed to run if it violates the policy.	Record in the audit logs
warn	This mode warns the user about the pods that do not meet the policy requirements and the pod is allowed to run if it violates the policy.	Display warning message

Exemptions

References

Here is the scenario, you setup security in your cluster, for some reasons, you want to have some flexibility in your cluster or some exceptions to the rule or security policies. In this case, you can use the exemptions feature in Pod Security Admission. Meaning that all modes (enforce, audit, and warn) will be skipped (ignore PSA) for the exempted pods.

There are three key exemption dimensions:

Exemption Dimension	Description
Usernames	Requests from authenticated (or impersonated) usernames are ignored by Pod Security Admission.
RuntimeClassNames	Requests for pods with a specific RuntimeClass are ignored by Pod Security Admission.
Namespaces	Requests for pods in a specific namespace are ignored by Pod Security Admission.

To configure the exemptions, you will need to configure the Admission Controller and pass the configuration to kube-apiserver using the --admission-control-config-file flag.

Step 1: Configure the Admission Controller configuration

/etc/kubernetes/admission-config.yaml


apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1 # see compatibility note
    kind: PodSecurityConfiguration
    # Defaults applied when a mode label is not set.
    #
    # Level label values must be one of:
    # - "privileged" (default)
    # - "baseline"
    # - "restricted"
    #
    # Version label values must be one of:
    # - "latest" (default) 
    # - specific version like "v1.32"
    defaults:
      enforce: "privileged"
      enforce-version: "latest"
      audit: "privileged"
      audit-version: "latest"
      warn: "privileged"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: []

Step 2: Pass the configuration to kube-apiserver

From the kube-apiserver, we need to pass the --admission-control-config-file flag to the kube-apiserver command line arguments. The --admission-control-config-file flag should point to the admission configuration file.

kube-apiserver.yaml


apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver-kind-cluster-control-plane
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.89.0.2
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction,PodSecurity
    - --admission-control-config-file=/etc/kubernetes/admission-config.yaml
    ...
    image: registry.k8s.io/kube-apiserver:v1.30.0

Steps to use PSS and PSA

Step 1: Label the namespace with respective mode and profiles

What if?

If no labels are set on a namespace, then it will use the default policy for the namespace. The default policy is privileged.

Important

Changing the namespace labels will affect existing pods in the namespace, but it will not delete them. As the changes will trigger the admission plugin to test existing pods against the new policy and return violations as warnings. For example, if the new policy is set to enforce, pods that violate the new policy will be rejected, but existing pods will not be terminated.


kubectl label namespace <ns> pod-security.kubernetes.io/<mode>=<profile>
 
# example
kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted
kubectl label namespace dev pod-security.kubernetes.io/warn=baseline
 
# apply multiple labels to the namespace
kubectl label namespace staging pod-security.kubernetes.io/audit=baseline pod-security.kubernetes.io/warn=baseline

In prod, the restricted profile is enforced. Meaning all pods in the prod namespace must follow the restricted profile. If a pod does not meet the requirements, it will be rejected. Let’s say u set the restricted profile with warn mode. The pod will be allowed to run, but a warning message will be displayed.
In dev, the baseline profile is set with warn mode. Meaning all pods in the dev namespace must follow the baseline profile. If a pod does not meet the requirements, it will be allowed to run, but a warning message will be displayed.
In staging, the baseline profile is set with audit and warn mode. Meaning all pods in the staging namespace must follow the baseline profile. If a pod does not meet the requirements, it will be allowed to run, but a warning message will be displayed and the violation will be recorded in the audit logs.

Step 2: Create a pod with no violations in the namespace

Here are the examples of creating a pod with no violations in the namespace based on the profiles.

What is privileged?

When you set privileged: true, it means that the container has full access to the host system. It can do anything that the host system can do.

privileged-pod.yaml


apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
  namespace: privileged-namespace
spec:
  containers:
    - name: privileged-container
      image: nginx:latest
      securityContext:
        privileged: true
        allowPrivilegeEscalation: true
        capabilities:
          add: ["ALL"]

Appropriate for workloads that require privileged access to the host system, such as system daemons or monitoring agents.

baseline-pod.yaml


apiVersion: v1
kind: Pod
metadata:
  name: baseline-pod
  namespace: baseline-namespace
spec:
  containers:
    - name: baseline-container
      image: nginx:latest
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        runAsNonRoot: true

Appropriate for most workloads that do not require privileged access to the host system, such as web servers, application servers, or databases.

restricted-pod.yaml


apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod
  namespace: restricted-namespace
spec:
  containers:
    - name: restricted-container
      image: nginx:latest
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        runAsNonRoot: true
        capabilities:
          drop: ["ALL"]

Appropriate for workloads that require the highest level of security and isolation, such as sensitive applications or multi-tenant environments. For example, financial applications, healthcare applications, or government applications.