It has been over five years since Pod Security Policies (PSP) in Kubernetes were replaced by the newer Pod Security Standards (PSS). One of the main reasons for this major change was to simplify management – and yet, even today, Pod Security Standards are still far from being used in all clusters.
That’s why today’s blog post focuses on the functionality, background, and benefits of Pod Security Standards and Pod Security Admission (PSA), which you can easily enable and configure in any standards-compliant Kubernetes cluster.
What Are Pod Security Standards?
Pod security standards in Kubernetes – as the name suggests – define certain security-related criteria for configuring Pods. These can be applied in various modes, either cluster-wide or at the Namespace level, by configuring the Pod Security Admission Controller.
Why the switch from PSP to PSS?
The original announcement of the feature – which also included the deprecation of Pod Security Policies – cites two main reasons for the transition and the need for such standards:
- Confusion regarding usage: Configuring PSPs for Pods often caused confusion and resulted in broader permissions than intended.
- Lack of a safety net: There was no “dry run” or audit mode for PSPs; furthermore, only certain parts of the Pod configuration were supported. Retrofitting clusters to PSPs was time-consuming and fraught with pitfalls.
For these and other reasons, further development of the PSP Admission Controller did not make sense – but developing a new standard based on the experience gained (both positive and negative) did. The result is the development of the Pod Security Standards, with their security profiles and new Admission Controller, as outlined in KEP 2579.
Available PSS Profiles
To keep things simple – after all, there are solutions like OPA Gatekeeper or Kyverno for more complex use cases – only three so-called profiles are defined for you to work with:
privileged: This is actually the opposite of a security standard, because the profile is defined by the absence of any rules. Pods can be configured as desired, and known exploits (e.g., privilege escalations) work in this profile.baseline: A sensible default profile for most application and Pod configurations. It prevents the configuration of settings that would enable known exploits; however, Pods in their minimal configuration are accepted and can be run.restricted: The most restrictive “Pod Security Standards” profile prohibits significantly more configurations than the ”baseline” profile and requires that pods be configured as securely as possible. For example, containers in Pods cannot be run as ”root.”
You can find a detailed list of all criteria defined for each Pod Security Standards profile in the official documentation.
These profiles now need to be applied to the Pods in your cluster—this is where the Pod Security Admission Controller comes into play.
The Pod Security Admission Controller
Requests sent to Kubernetes via its API go through a strict sequence of steps before being processed by the various Kubernetes components:
- Authentication (Who is making the request?)
- Authorization (Is the authenticated entity permitted to make this request?)
- Admission Control, divided into three steps:
- Mutating Admission Controllers that can modify the objects contained in the request as needed (e.g., to inject sidecars or set default values)
- Object schema validation to validate the objects (which may have been modified) contained in the request against Kubernetes’ OpenAPI schema
- Validating Admission Controller to finally accept or reject the objects (which may have been modified) contained in the request
- Persistence in etcd (objects included in the request are stored permanently)
- Response to the client (What was the result of steps 1–4?)
Since Pod Security Standards require a clear yes/no decision based on the defined criteria, and since insecure Pods should not be executed at all, the Pod Security Admission Controller is located in step 3.3 of this sequence. Here, the Admission Controller checks all requests – whether they involve Pods directly or a controller that manages Pods – for compliance with the defined Pod Security Standards profile, including:
- Pods
- Deployments
- StatefulSets
- Jobs
It’s worth noting here that if the defined standard is not met, only the creation of the Pod will fail – a Deployment, for example, would be created without any problems. The Pods defined and managed by that Deployment would not.
Configuring the Pod Security Admission Controller
Since the Pod Security Admission Controller, just like the Pod Security Standards, is part of Kubernetes itself, it is possible to configure the admission controller without installing any additional applications. To do this, you need an appropriate entry in a YAML file that defines the behavior of the configured admission controllers for the cluster, for example, admission-configuration.yaml:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1
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.36"
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: []This file must then be provided to the Kubernetes API server as a file path using the ` --admission-control-config-file ` argument.
The example above from the Kubernetes documentation sets the ” privileged ” Pod Security Standards profile for all namespaces in the cluster, so that any Pod configuration is accepted. But what do the keys enforce, audit, and warn mean?
The Modes of the Pod Security Admission Controller
One of the goals set during the development of the Pod Security Standards was to enable cluster operators to easily enable the feature without disrupting users’ workflows. For this reason, there are three modes that can be configured independently of one another:
warnIf the Admission Controller fails the validation, it returns a warning to the user but accepts the offending Pod configuration.auditCreates an audit entry for the observed event (e.g., the creation of a Pod) in the API server’s audit log (provided that audit logging is enabled), but accepts the offending Pod configuration.enforceRejects all Pod configurations that do not comply with the defined Pod Security Standards profile.
The modes can be freely combined across profiles and modes. The example above defines the profile ` privileged` for all three modes of the Admission Controller, which is equivalent to absolute silence – every Pod is accepted by the Admission Controller, so there are never any warnings or auditable annotations.
Configuration at the Namespace level
More interesting than the example above is the ability to define PSS profiles and Admission Controller modes at the Namespace level. In the example above, the Admission Controller is running but allows any configuration to pass through – even insecure ones. If, for example, you want to further secure the Namespace default, you can do so by applying a combination of labels to the Namespace object:
apiVersion: v1
kind: Namespace
metadata:
name: default
labels:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/enforce-version: v1.35
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/audit-version: latest
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/warn-version: latestWith this configuration using labels, Pods in the default Namespace now behave as follows:
- Pods that match the PSS profile
baselineinv1.35are accepted by the Admission Controller and scheduled. - If a Pod does not comply with the latest version of the PSS profile
restricted, an annotation is created in the audit log event, and the user receives a detailed warning specifying which settings are non-compliant.
With this configuration, as a cluster administrator, you can carefully prepare your users for upcoming changes: Existing Pod configurations that conformed to the ` baseline ` profile in Kubernetes v1.35 will continue to be created (e.g., after upgrading Kubernetes to v1.36). In addition, users receive direct feedback from the admission controller on where they need to make adjustments to meet the stricter requirements of the ` restricted ` profile, and thanks to the audit annotations, you as an administrator can also keep track of such violations.
Pod Security Standards as a Flexible First Step Toward Greater Cluster Security
Pod Security Standards have elegantly solved the old PSP problem: Instead of a complex, error-prone configuration, you get three clearly defined profiles, a native admission controller that requires no additional installation, and – thanks to the three independently combinable modes warn, audit, and enforce – a smooth migration path that doesn’t immediately kick existing workloads out of the cluster.
If you haven’t implemented Pod Security Standards yet, the most pragmatic first step is quick and easy: Set ` enforce ` cluster-wide to ` privileged ` or directly to ` baseline`, add ` audit ` and ` warn ` for the next stricter profile, and monitor which warnings and audit annotations accumulate over the course of a few weeks. This will give you a realistic picture of how far your existing Pod configurations are from a more secure configuration – all without the risk of crippling production workloads with overly strict requirements.
For requirements that go beyond the three PSS profiles, such as organization-specific policies or more complex validation logic, solutions like OPA Gatekeeper or Kyverno are good options. But as a basic layer of protection that’s available out of the box in every Kubernetes cluster, there’s currently hardly a simpler option than the Pod Security Standards – and our MyEngineer® team is always happy to assist you with these as well.
0 Comments