Pod Security Standards in Kubernetes

Kubernetes uses the Pod Security Admission (PSA) controller to enforce security policies inside clusters. Deprecated PodSecurityPolicies leave a gap. This guide shows how to configure namespaces and apply PSA to prevent dangerous containers. You learn policy levels, label workflows, audit mode and enforcement mode steps—all at a glance.

TL;DR

• PSA replaces deprecated PodSecurityPolicy in Kubernetes v1.25+.
• Three policy levels: privileged, baseline, restricted.
• Label namespaces to set audit, warn or enforce modes.
• Use YAML to deploy PSA in API server or via helm.
• Test policies with audit logs before enforcement.
• Combine PSA with securityContext for robust controls.

Pod Security Standards Overview

Pod Security Standards define guardrails for container security. They codify best practices on Linux capabilities, privilege escalation, user IDs, seccomp profiles and more. PSA uses these standards to admit or reject pods. You choose a level per namespace. The controller runs inside the kube-apiserver as a built-in plugin.

PSA Requirements and Policy Levels

PSA supports three levels:

• Privileged: No security checks. Mirrors default PSP behavior.
• Baseline: Blocks known privilege escalations. Enforces default seccomp and disallows SYS_ADMIN, NET_RAW.
• Restricted: Hardens pods further. Removes all nonessential capabilities, enforces rootless containers, blocks hostNetwork, hostPID, hostIPC.

Use restricted for production. Baseline for dev and low-risk workloads.

Enforcing Pod Security Standards via Admission Controller

PSA integrates as an admission controller. It intercepts pod create and update requests, inspects labels on target namespaces, and compares the pod spec against the policy level. Then it admits, warns or rejects accordingly.

This flow ensures every pod matches your namespace policy.

Configuring Namespaces for Pod Security Standards

PSA uses namespace labels of form:

• pod-security.kubernetes.io/enforce: <level>
• pod-security.kubernetes.io/warn: <level>
• pod-security.kubernetes.io/audit: <level>

Example: apply restricted enforcement in namespace myapp:

apiVersion: v1
kind: Namespace
metadata:
  name: myapp
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: baseline
    pod-security.kubernetes.io/audit: baseline

This config enforces restricted on pod creation. It warns and audits baseline violations. Always audit first in production to avoid downtime.

Pod Security Standards Enforcement Strategies

Follow these steps to deploy PSA:

1. Enable PSA in API server with --enable-admission-plugins=PodSecurity.
2. Label existing namespaces in audit mode.
3. Monitor audit logs for violations.
4. Transition warn mode for remediation windows.
5. Apply enforce mode after fixes.

You can also deploy PSA using the helm chart of your managed Kubernetes. Always consult your provider docs.

Testing and Auditing Pod Security Standards

Run pods that violate your chosen policy. Use kubectl to see warnings:

kubectl run privtest --image=nginx --overrides='{
  "spec": {"securityContext": {"privileged": true}}
}'
kubectl get events --namespace=myapp

Look for warnings tagged by PSA. Fix the pod spec or move it to a privileged namespace.

SecurityContext and PSA Synergy

PSA relies on pod spec fields. The securityContext section must align with policy level. Key fields:

• runAsUser: Prevents root.
• runAsGroup: Enforces group ID.
• capabilities.drop: Remove SYS_ADMIN.
• seccompProfile.type: Should be RuntimeDefault.
• allowPrivilegeEscalation: Must set to false.

Combine namespace policy with explicit securityContext for defense in depth.

Use-Cases for Pod Security Standards

PSA helps secure diverse workloads. Examples:

• Event-driven functions: FaaS pods often run untrusted code. Set restricted policy to block exec and privilege escalation.
• CI/CD agents: Agents need moderate rights. Use baseline to allow hostPath mounts but deny NET_RAW.
• Legacy apps: Require privileged. Create a separate namespace with privileged enforcement.

Upgrading from PodSecurityPolicy to Pod Security Standards

PSP is deprecated in v1.21 and removed in v1.25. Follow these steps to migrate:

1. Inventory existing PSPs. Map rules to PSA levels.
2. Label namespaces according to mapped levels.
3. Enable PSA plugin in API server.
4. Test pods under audit mode.
5. Remove PSP admission plugin flags.

Best Practices and Troubleshooting

Always start in audit mode. Use centralized logging to track warnings. Automate label application using GitOps workflows. Document namespace policies. Review PSA release notes when you upgrade Kubernetes. If pods fail without clear logs, check for missing labels or misconfigured securityContext fields. Combine PSA with NetworkPolicies and RBAC for a full defense strategy.

References

• Enforcing Pod Security Standards
• kube-apiserver documentation
• Configure a Security Context for a Pod or Container

Suggested Reading

• Which Kubernetes apiVersion Should You Use?
• Namespace Scope in Kubernetes
• How to Access a Service in Another Namespace in Kubernetes
• SELinux Blocking Grafana Connection: How I Fixed It
• Understanding Proxies in Kubernetes

PostHashID: 8b7367c434f06fa0a9bc41acc43d0130a0128cb89feab31896390cc0b48be20a