How to use Pod Security Standards in Kubernetes Cluster

Here in this article we will see how we can enable and use Pod Security Standards in Kubernetes Cluster environment. We will be enabling the Pod Security Admission Controller in Kubernetes API server and create namespace which will enforce the Pod Security Standard isolation levels. Also we will see how we can enable audit logging of these security restriction event in kubernetes cluster by enabling audit log policy in Kubernetes Cluster.

Test Environment

Fedora 36 server
Kubernetes Cluster v1.25.2 (1 master + 1 worker node)

What are Pod Security Standards

Pod Security Standards play an important role is configuring the Kubernetes Cluster security at the Pod and Container level. Its provides a set of policies that when used provide the Pods and their respective containers with access to host from Highly-permissive to Highly-restrictive.

Profile	Description
Privileged	Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations.
Baseline	Minimally restrictive policy which prevents known privilege escalations. Allows the default (minimally specified) Pod configuration.
Restricted	Heavily restricted policy, following current Pod hardening best practices.

Kubernetes offers a built-in Pod Security admission controller to enforce the Pod Security Standards. Pod security restrictions are applied at the namespace level when pods are created.

Procedure

Step1: Enable Pod Security Admission Controller for Pod Security Standards

As a first step we need to enable the PodSecurity feature gate in the kube-apiserver manifest as shown below. For v1.25.x PodSecurity feature gate is enabled by default as per the documentation.

For a kubernetes cluster with version < 1.22.x, we need to enable this feature gate explicitly as shown below. Once the update is done, the API server pod will be restarted.

Once the Pod Security Admission Controller is enabled it places requirements on a Pod’s Security Context and other related fields according to the three levels defined by the Pod Security Standards: privileged, baseline, and restricted.

Step2: Create a new namespace with control mode and isolation level

As mentioned above, Pod security restrictions are applied at the namespace level when pods are created.

First we need to decide on the isolation level that we want to use for the Pod (ie. privileged, baseline and restricted). Once that is decided we need to decide on the control mode that we want set at the namespace level (ie. enforce, audit, warn). Whenever there is a pod violates any of the policy restrictions, based on the control mode that particular action will either be rejected, logged as an audit event in audit.log or trigger a warning for the end user. Here are the details on the control mode that we can use for the admission controller.

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

In this step we will create a new namespace – podsecurityns for testing the pod security standard related features and restrictions. We will be using enforce mode with restricted level for this namespace. For this mode and level to take effect we need to define a set of labels for the namespace as shown below.

Here is the yaml definition file that we will apply to create a namespace with pod security restriction and enforcement mode labels as shown below.

Now let’s apply this yaml definition file to create the secure namespace.

Step3: Create a Pod violating a security restriction

Now let us try to create a pod with securityContext for allowing Privileged Escalation as true in our secure namespace – podsecurityns.

As you can see from the below error, we are unable to create the pod as it violates the PodSecurity restricted policy that we enabled for this namespace. Also this event should be logged into the audit.log file as we enabled the control mode – audit for restricted level access.

But for the audit logs to be generated we need to configure our API server to use a audit policy for logging the events into the logs file on the Host machine. Follow the next step for enabling auditing in Kubernetes API server.

Step4: Enable audit logging for Kubernetes API server

Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster. The policy determines what’s recorded and the backends persist the records.

Create an audit policy yaml definition file

Configure kube-apiserver with the audit policy file and the backend log path location. Here is the updated kube-apiserver.yml definition file with audit logging settings enabled.

Ensure that kubernetes cluster nodes are in ready state after the kube-apiserver manifest changes as shown below.

NOTE: The audit logging feature increases the memory consumption of the API server because some context required for auditing is stored for each request. Memory consumption depends on the audit logging configuration.

Now’s if you try to apply the same privilegedpod.yml from the Step3 you should be able to see an audit log event getting generated as shown below.

Step5: Create a new namespace without any Pod Security Standard restrictions

Step6: Create a Pod violating a security restriction in standardns namespace

Now let us try to create a pod with securityContext for allowing Privileged Escalation as true in our secure namespace – podsecurityns.

Hope you enjoyed reading this article. Thank you..