Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 533 of 8028. Security and ObservabilityFree lesson

Applying Pod Security Standards Profiles

Learners will apply Privileged, Baseline, and Restricted security profiles to control the security posture of pod deployments.

In this lesson, you will learn how to enforce security guardrails at the namespace level by applying the three built-in Pod Security Standards profiles.

Kubernetes Pod Security Admission (PSA) allows you to define how strictly your clusters handle pod security by applying one of three pre-defined policies: Privileged, Baseline, or Restricted. These profiles act as an automated governance layer that ensures your deployments follow defined security best practices.

The Three Profiles

  1. Privileged: This is the "no restrictions" mode. It allows for full privilege escalation and is typically used for system-level components that require host access.
  2. Baseline: This is the standard operational mode. It prevents known privilege escalations and common security misconfigurations (like running as root or accessing host namespaces) while still allowing most "standard" application workloads to run.
  3. Restricted: This is the gold standard for security. It enforces all the hardening practices we’ve discussed, such as requiring non-root execution, dropping all capabilities, and preventing access to host namespaces.

Applying Profiles via Namespace Labels

You don't apply these profiles to individual pods; instead, you label a namespace to tell the Kubernetes API server which policy to enforce. You can set the profile for enforce (blocking non-compliant pods) or audit (logging violations without blocking).

To secure a production namespace using the Restricted profile, you would label it like this:

kubectl label namespace my-secure-app \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest

Once this label is applied, any new pod created in that namespace that violates the "Restricted" criteria (e.g., a container trying to run as root) will be rejected by the API server immediately.

When transitioning existing applications, start by using the warn or audit modes instead of enforce. This allows you to identify which pods are currently non-compliant without breaking your production services. Once you have remediated those deployments to follow principles like "Non-Root User Execution," you can safely switch to enforce mode to lock down your cluster posture.

Key Takeaway: Use Namespace labels to enforce Pod Security Profiles, prioritizing the "Restricted" profile for production workloads to automatically block non-compliant pods at the API gate.