Skip to main content

Pod Security Standards

Documentation

Pod Security Standards (PSS) are a series of security policies in Kubernetes to ensure that pods are created and run with appropriate security practices. They were introduced to replace the PodSecurityPolicy (PSP) model, which was discontinued in version 1.25.

They work through an Admission Controller that intercepts the request and verifies the policy.

Kubernetes allows applying these standards per namespace, using labels to define the security level that should be enforced. This ensures that each namespace has its own security rules, without affecting the entire cluster.

PSS defines three security levels:

  • Privileged: This level offers minimal security restrictions, allowing pods with broad permissions, such as running as root or using privileged capabilities. It's used for workloads that require more control over the system. Example use: development environments or pods that need to access the host directly.

  • Baseline (Default): This is the recommended level for most workloads, offering balanced security. It imposes minimal restrictions to prevent unsafe actions, such as running processes as root, but still allows some flexibility. Example use: common applications that don't need elevated permissions or direct host access.

  • Restricted: This is the most secure level and applies the strictest restrictions, ensuring the use of ideal security practices. It prohibits the use of root, prevents privileged containers, and imposes strict controls over permissions and capabilities. Example use: critical applications or in highly regulated environments, where security is a priority.

Security levels can be applied in 3 different scenarios:

  • enforce: Enforcement of the policy level that will ensure all pods created in the namespace meet, at minimum, this policy. If a pod doesn't comply with the chosen policy rules, it will be blocked.

  • warn: The level that will generate warnings. Thus, when a pod doesn't meet the imposed standards, users will receive a notification, but the pod will still be allowed.

  • audit: The audit policy that will record events in logs, allowing you to track which pods are violating this policy, without affecting pod execution.

To apply a PSS you only need to put the correct label on the namespace.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest

It allows you to enforce a more permissive security policy (like baseline), while simultaneously auditing and issuing warnings for a more restricted policy (like restricted). Let's detail each part:

It's not necessary to use all of this, I just put it to show possibilities.

Explanation of each label:

  • pod-security.kubernetes.io/enforce=baseline: Defines that the baseline security level will be enforced on the namespace. This means that any pod that violates the minimum security rules defined by the "baseline" level will be blocked during creation or modification.

  • pod-security.kubernetes.io/enforce-version=latest: Specifies the version of the security policy that will be applied. In this case, it uses the latest version of the pod security policy. Not mandatory.

  • pod-security.kubernetes.io/warn=restricted: Applies the restricted security level in warning mode (warn). This means that if a pod violates the stricter rules of the "restricted" level, Kubernetes will issue a warning to the user, but won't block pod creation. It's useful for preparing the transition to stricter policies without interrupting operations.

  • pod-security.kubernetes.io/warn-version=latest: Defines that the latest version of the restricted level will be used to generate warnings.

  • pod-security.kubernetes.io/audit=restricted: Applies the restricted security level in audit mode (audit). When a pod is created or modified and violates the "restricted" level rules, this will be recorded in Kubernetes audit logs, allowing you to track events without blocking or warning the user.

  • pod-security.kubernetes.io/audit-version=latest: Uses the latest version of the restricted level for auditing. Configuration Goal:

If you apply Pod Security Standards (PSS) to a namespace that already has running pods, the behavior depends on the label you use and the current state of the pods.

  • Pods that are already running won't be immediately affected by the security rules, because PSS is only checked during pod creation or modification. If the pods aren't restarted or recreated, they'll continue running normally, even if they're not compliant with the new PSS rules.

  • New pods or recreated pods will be blocked if they don't meet the rules.

If you try to create new pods or recreate (for example, in a rollout or deployment upgrade scenario) and they're not compliant with the defined security level (like "baseline" or "restricted"), Kubernetes will prevent the creation of these pods. This also affects pods that go through reschedule events (like node failures or maintenance) or pods that are part of workloads like Deployments or StatefulSets. Necessary adjustments:

Before applying a more restrictive security policy, like "restricted", it's recommended to review and adapt your pods to ensure they comply with the new rules.