🏷️ Use appropriate pod security standards

🏷️ Use appropriate pod security standards#

Pod Security Standards (PSS)#

Pod Security Standards (PSS) are a set of built-in, predefined security policies in Kubernetes designed to secure Pods by enforcing security best practices. They replaced the deprecated Pod Security Policies (PSP) and are enforced by the Pod Security Admission (PSA) controller, available by default since Kubernetes v1.23.

The Three Security Profiles#

PSS defines three cumulative, progressively restrictive profiles:

  1. Privileged:

    • Description: An unrestricted policy allowing all capabilities and known privilege escalations.

    • Use Case: Reserved for trusted, system-level workloads that require full access to the host (e.g., CNI plugins, CSI drivers, logging agents in kube-system).

    • Key Permissions: Allows host network, PID, IPC; privileged containers; and unrestricted Linux capabilities.

  2. Baseline:

    • Description: A minimally restrictive policy that prevents known privilege escalations while allowing most common application configurations.

    • Use Case: The recommended starting point for most general application workloads.

    • Key Restrictions: Blocks privileged containers, host namespaces, hostPath volumes, and the addition of dangerous Linux capabilities (e.g., NET_BIND_SERVICE).

  3. Restricted:

    • Description: A heavily restricted policy that follows current Pod hardening best practices.

    • Use Case: For security-critical, multi-tenant, or internet-facing applications where maximum isolation is required.

    • Key Requirements: Inherits all Baseline restrictions and further requires running as a non-root user, dropping all Linux capabilities, using a read-only root filesystem, and setting a seccomp profile.

Enforcement with Pod Security Admission (PSA)#

PSA enforces PSS at the namespace level using labels. It operates in three modes, which can be combined:

  • enforce: Rejects any Pod that violates the specified policy.

  • audit: Allows the Pod to run but logs the violation in the audit log.

  • warn: Allows the Pod to run but returns a warning message to the user.

This allows for a phased adoption strategy (e.g., start with warn and audit, then move to enforce).