Understanding and applying Kubernetes Pod Security Policies

A Kubernetes Pod Security Policy (PSP) is a central part of the Kubernetes Security Context, but implementing robust container security is only one of the required steps. A Pod Security Policy allows granular security configuration at the cluster level. Pod Security Policy default values are typically open to maximize flexibility, so the responsibility to calibrate policies to tighten security falls on DevOps.

Understanding Kubernetes Pod Security Policy for cloud native application security

Though Kubernetes provides an excellent security infrastructure, it is almost humanly impossible to ensure all PSP profile entries will ensure secure configuration and hardening of the container deployment. 

Pod Security Policy is the tool to control the:

• Running of privileged containers
• Usage of host namespaces
• Usage of host networking and ports
• Usage of volume types
• Usage of the host filesystem
• Permissions for specific FlexVolume drivers
• Allocation of an FSGroup that owns the pod’s volumes
• Requirement for the use of a read only root file system
• User and group IDs of the container
• Restricting escalation to root privileges
• Linux capabilities
• SELinux context of the container
• Allowed Proc Mount types for the container
• AppArmor profile used by containers
• seccomp profile used by containers
• sysctl profile used by containers

What is Kubernetes security context?

The Kubernetes Security Context is the range of access and permission constraints applied to each individual pod and container configured at runtime. As a Kubernetes pod is the smallest deployable computing unit, defining the minimum security conditions required for a cluster to accept a pod must be calibrated to balance the need for security and the organization’s requirements. 

Pod Security Policy acts as an admission controller, validating requests for pod creation and updates against the configured policies. Properly configuring Pod Security Policies is crucial as a controller manager typically creates pods through a templated controller, such as Deployment or Replica set.

Configuring Pod Security Policy

When working directly with Kubernetes, Pod security policies are defined in a YAML file then applied with a kubectl command. To create a privileged container, for example, you would enter a code such as this one: This container configuration:

• Sets allowPrivilegeEscalation to true, which allows the container to gain more privileges than its parent process, meaning that the container can escalate privileges.

• Sets readOnlyRootFilesystem to false, which mounts the container root filesystem as read-write
• Sets privileged to true, which specifies that the container will run as privileged.
• Sets runAsUser to 0 , which specifies that the container will run as UID 0 (root).

This container configuration allows privilege escalation, potentially endangering the security of the entire cluster. If Pod Security Policy is configured to restrict authorization only to non-privileged containers, this container will not be deployed. Cisco Cloud Native Security Solution dashboard presents a far more readable alternative: And will trigger an alert when a Pod Security Policy non-compliant container is detected. This container configuration:

• Sets allowPrivilegeEscalation to false, which stops the container from gaining more privileges than its parent process.

• Sets readOnlyRootFilesystem to true, which prevents writing on the root filesystem, limiting access to reading only.

• Sets privileged to false, which stops the container from escalating privileges.
• Sets runAsUser to 1000, which specifies that the container can only run with UID 1000.

This container configuration blocks privilege escalation, and prevents modifying the filesystem. When Pod Security Policy are configured to restrict authorization only to non-privileged containers, the read only root file system will allow the replica set to run that container, as shown in the Strict-Security-Profile below. Even if the deployment rules are set to block containers not conforming to PSP no alert will show for that container Using Cisco Cloud Native Security Solution gives you access to pre-set/pre-configured best practices profiles you can use without being an expert in PSP or secomp configuration infra. This allows an almost immediate bootstrap of a user with a correct profile.

Selecting the appropriate Pod Security Policy

Selecting the optimal Pod Security Policy to apply when adding or creating a new environment is greatly facilitated by the Cisco Cloud Native Security Solution Policy Advisor. Cisco Cloud Native Security Solution’s Policy Advisor displays all connections affected by a rule, giving an instant bird-eye view of the downstream effect of a rule modification on the application running. This enables administrators to set and centralize the management of operational policies, minimizing conflicting rules, and improving Kubernetes-orchestrated applications’ security profile. 

As a result, administrators can be confident that their workload runtimes based on containers are configured to maximize productivity without compromising security. It’s only one piece of the cloud native application security puzzle, but it’s critical to get it right.

Please note: Depreciation of Pod Security Policy

Kubernetes will depreciate the PSP in Kubernetes version 1.21 and completely in version 1.25. Although it is being deprecated Cisco Cloud Native Security Solution has backward compatibility and the same security functionality will be supported by validation/mutation of the executed APIs – not relaying on K8s (“old PSP”).

Want more context? You can read our discussion of Kubernetes and multi-cloud security for additional information.