Pod Security Standards: A Security-First Guide

Kubernetes Pod Security Standards

TL;DR: I enforce PSS restricted on all production namespaces: runAsNonRoot: true, allowPrivilegeEscalation: false, all capabilities dropped, read-only root filesystem. Start with warn mode to find violations, then switch to enforce. This single change blocks the majority of container escape attacks.

Imagine this: your Kubernetes cluster is humming along nicely, handling thousands of requests per second. Then, out of nowhere, you discover that one of your pods has been compromised. The attacker exploited a misconfigured pod to escalate privileges and access sensitive data. If this scenario sends chills down your spine, you're not alone. Kubernetes security is a moving target, and Pod Security Standards (PSS) are here to help.

PSS is Kubernetes' answer to the growing need for solid, declarative security policies. They provide a framework for defining and enforcing security requirements for pods, ensuring that your workloads adhere to best practices. But PSS isn't just about ticking compliance checkboxes — it's about aligning security with DevSecOps principles, where security is baked into every stage of the development lifecycle.

From PodSecurityPolicy (deprecated in Kubernetes 1.21) to Pod Security Standards, the focus has shifted toward simplicity and usability. PSS is designed to be developer-friendly while still offering powerful controls to secure your workloads.

At its core, PSS enables teams to adopt a "security-first" mindset — protecting your cluster from external threats while mitigating risks posed by internal misconfigurations. By enforcing security policies at the namespace level, PSS ensures that every pod deployed adheres to predefined standards.

From experience: Run kubectl label ns YOUR_NAMESPACE pod-security.kubernetes.io/warn=restricted first. This logs warnings without blocking deployments. Review the warnings for 1-2 weeks, fix the pod specs, then switch to enforce. I've migrated clusters with 100+ namespaces using this process with zero downtime.

Key Challenges in Securing Kubernetes Pods

Securing Kubernetes pods is easier said than done. Pods are the atomic unit of Kubernetes, and their configurations can be a goldmine for attackers if not properly secured. Common vulnerabilities include overly permissive access controls, unbounded resource limits, and insecure container images.

The core tension: developers want their pods to "just work," and adding runAsNonRoot: true or dropping capabilities breaks applications that assume root access. I've seen teams disable PSS entirely because one service needed NET_BIND_SERVICE. The fix isn't to weaken the policy — it's to grant targeted exceptions via a namespace with Baseline level for that specific workload, while keeping Restricted everywhere else.

Remember the Tesla Kubernetes breach in 2018? Attackers exploited a misconfigured pod to mine cryptocurrency. The pod had access to sensitive credentials stored in environment variables, and the cluster lacked proper monitoring. This incident underscores the importance of securing pod configurations from the outset.

Common Pitfall: Ignoring resource limits in pod configurations can lead to denial-of-service attacks. Always define resources.limits and resources.requests in your pod manifests to prevent resource exhaustion.

Implementing Pod Security Standards in Production

How do you implement Pod Security Standards effectively? Here's the breakdown:

1. Understand the PSS levels: Kubernetes defines three levels — Privileged, Baseline, and Restricted. Each represents a stricter set of security controls.

2. Apply labels to namespaces:
   

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

1. Audit and monitor: Use Kubernetes audit logs to monitor compliance. The audit and warn labels identify pods that violate policies without blocking them.

2. Supplement with OPA/Gatekeeper: PSS covers the basics, but you'll need Gatekeeper for custom policies like "no images from Docker Hub" or "all pods must have resource limits." I run 12 custom Gatekeeper constraints on top of PSS.

My migration path: Week 1: apply warn=restricted to all production namespaces. Week 2: collect and triage warnings. Week 3: move fixed namespaces to enforce=restricted, exceptions to enforce=baseline. Week 4: add CI validation with kube-score.

For dev namespaces, I use enforce=baseline (not privileged). Even in dev, you want to catch the most dangerous misconfigurations.

CI integration is non-negotiable: run kubectl --dry-run=server against a namespace with enforce=restricted in your pipeline. If the manifest would be rejected, fail the build.

Battle-Tested Strategies

• Integrate PSS into CI/CD pipelines: Shift security left by validating pod configurations during build. Tools like kube-score and kubesec analyze your manifests for security risks.
• Monitor pod activity: Use Falco to detect suspicious activity in real-time — shell commands, sensitive file access, unexpected network connections.
• Limit permissions: Follow least privilege. Avoid running pods as root and restrict access to sensitive resources using RBAC.

Use network policies to control traffic between pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-traffic
  namespace: secure-apps
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: trusted-app

Real incident: I've audited clusters where every pod was running as root with all capabilities because nobody set a SecurityContext. The default is insecure. PSS Restricted mode makes the secure configuration the default, not the exception.

Future Trends

Emerging security features: Kubernetes is introducing ephemeral containers and runtime security profiles to enhance pod security, reducing attack surfaces and improving isolation.

seccomp and AppArmor profiles are graduating from beta. I'm already running custom seccomp profiles that restrict system calls per workload type — web servers get a different profile than batch processors. This is the next layer beyond PSS.

Strengthening Security with RBAC

RBAC is a cornerstone of Kubernetes security. Define roles and bind them to users or service accounts to control access:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: secure-apps
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

From experience: Run kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:default for every namespace. If the default ServiceAccount can list secrets or create pods, you have a problem. I strip all permissions from default ServiceAccounts and create dedicated ones per workload.

Key Takeaways

• Pod Security Standards provide a declarative way to enforce security policies in Kubernetes
• Common pod vulnerabilities include excessive permissions, insecure images, and unbounded resource limits
• Use OPA, Gatekeeper, and Falco to automate enforcement and monitoring
• Integrate PSS into CI/CD pipelines to shift security left
• Start with warn mode, then move to enforce — never skip the audit phase

Have you implemented Pod Security Standards in your clusters? Share your experiences or horror stories — I'd love to hear them.

---

Originally published at orthogonal.info