Pod Safety Approval (PSA)

However, in the Kubernetes 1.25 release, pod security policies have been completely removed. For now, we’ll just focus on accessing the security of the pod. PSA is enabled by default in Kubernetes 1.23, however we will need to specify which pods must comply with security standards. All you need to do to enable the PSA feature is to add a specific format label to the namespace. All pods in this namespace will have to follow the declared standards.

The label consists of three parts: prefix, mode and level. Prefix always uses the given value pod-security.kubernetes.iofollowed by / (slash). The mod defines the handling of the violation. Finally, the level dictates the degree of security standard to be adhered to. An example of such a label might look like this:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted

Mod can in turn take three values:

• enforce: Violations will result in Pod launch being rejected,

• audit: Pod creation will be allowed. Violations will be added to the audit log,

• warn: Pod creation will be allowed. Violations will be displayed on the console.

We also have security policies determined by the level set for PSA:

• privileged: Fully unrestricted policy,

• baseline: A minimally restrictive policy that covers important standards,

• restricted: Severely restrictive policy in line with best practices for hardening pods from a security standpoint.

Enforcing Pod Security Standards for the Namespace

Restricted

Let’s apply PSA to a pod in the psa namespace. This shows the definition of the namespace and the declaration of the corresponding label. The tag will ensure that the PSS meets the highest safety standards.

apiVersion: v1
kind: Namespace
metadata:
  name: psa-restricted
  labels:
	pod-security.kubernetes.io/enforce: restricted

And create a pod that violates our established restrictions

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: psa-restricted
spec:
  containers:
  - image: busybox:1.35.0
	name: busybox
	command: ["sh", "-c", "sleep 1h"]

Violations will be displayed in the console after running the command to create a pod in the namespace. As you can see from the following, the Pod could not be created:

We need to tweak the Pod’s security context settings to meet very strict standards. Shown here is an example pod definition that does not violate the pod security standard.

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: psa-restricted
spec:
  containers:
  - image: busybox:1.35.0
    name: busybox
    command: ["sh", "-c", "sleep 1h"]
    securityContext:
        allowPrivilegeEscalation: false
        capabilities:
            drop: ["ALL"]
         runAsNonRoot: true
         runAsUser: 2000
         runAsGroup: 3000
         seccompProfile:
    	 type: RuntimeDefault

Pod object creation now works as expected.

Next, we will create a Pod Security Admission (PSA) rule. In a namespace called Audited, we will create a Pod Security Standard (PSS) with a baseline that should be displayed on the console.

Specify a namespace named audited in the file psa-namespace.yaml. We set the PSA label with baseline and mode warn:

apiVersion: v1
kind: Namespace
metadata:
  name: audited
  labels:
    pod-security.kubernetes.io/warn: baseline

We can create a bug using the following Pod configuration in the file psa-pod.yaml. YAML manifest set attribute hostNetwork: truewhich is not allowed for base level:

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: audited
spec:
  hostNetwork: true
  containers:
  - name: busybox
       image: busybox:1.28
       command: ["sh", "-c", "sleep 1h"]

When creating a pod, a warning message appears:

However, the Pod will be created. We can prevent Pod creation by configuring PSA with level restricted:

PSA is a built-in feature enabled by default in Kubernetes version 1.23 or higher. It is easy to implement, allows you to choose the appropriate policy standard, and can be configured to enforce or simply log violations.

Unfortunately, PSA only applies to pods with a predefined set of policies. You can’t write your own rules, change the messaging, or change the Pod if it doesn’t match the PSS.

Lastly, I would like to recommend free webinarwhere you will learn what components Kubernetes consists of, how they interact and what they are needed for, and also get acquainted in detail with the basic objects that exist inside any Kubernetes cluster.