Tag: Kubernetes Pod Security Standards

Kubernetes Pod Security Standards

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.

Pod Security Standards are 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.

Kubernetes security policies have evolved significantly over the years. From PodSecurityPolicy (deprecated in Kubernetes 1.21) to the introduction of 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 is about enabling teams to adopt a “security-first” mindset. This means not only protecting your cluster from external threats but also mitigating risks posed by internal misconfigurations. By enforcing security policies at the namespace level, PSS ensures that every pod deployed adheres to predefined security standards, reducing the likelihood of accidental exposure.

For example, consider a scenario where a developer unknowingly deploys a pod with an overly permissive security context, such as running as root or using the host network. Without PSS, this misconfiguration could go unnoticed until it’s too late. With PSS, such deployments can be blocked or flagged for review, ensuring that security is never compromised.

Key Challenges in Securing Kubernetes Pods

Pod security doesn’t exist in isolation—network policies and service mesh provide the complementary network-level controls you need.

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. These misconfigurations can lead to privilege escalation, denial-of-service attacks, or even full cluster compromise.

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.

Consider the infamous Tesla Kubernetes breach in 2018, where 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.

Another challenge is the dynamic nature of Kubernetes environments. Pods are ephemeral, meaning they can be created and destroyed in seconds. This makes it difficult to apply traditional security practices, such as manual reviews or static configurations. Instead, organizations must adopt automated tools and processes to ensure consistent security across their clusters.

For instance, a common issue is the use of default service accounts, which often have more permissions than necessary. Attackers can exploit these accounts to move laterally within the cluster. By implementing PSS and restricting service account permissions, you can minimize this risk and ensure that pods only have access to the resources they truly need.

Implementing Pod Security Standards in Production

Before enforcing pod-level standards, make sure your container images are hardened—start with Docker container security best practices.

So, how do you implement Pod Security Standards effectively? Let’s break it down step by step:

1. Understand the PSS levels: Kubernetes defines three Pod Security Standards levels—Privileged, Baseline, and Restricted. Each level represents a stricter set of security controls. Start by assessing your workloads and determining which level is appropriate.
2. Apply labels to namespaces: PSS operates at the namespace level. You can enforce specific security levels by applying labels to namespaces. For example:

   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
   

3. Audit and monitor: Use Kubernetes audit logs to monitor compliance. The audit and warn labels help identify pods that violate security policies without blocking them outright.
4. Supplement with OPA/Gatekeeper for custom rules: 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.” Deploy Gatekeeper’s constraint templates for the rules PSS doesn’t cover — in my clusters, I run 12 custom Gatekeeper constraints on top of PSS.

The migration path I use: Week 1: apply warn=restricted to all production namespaces. Week 2: collect and triage warnings — fix pod specs that can be fixed, identify workloads that genuinely need exceptions. Week 3: move fixed namespaces to enforce=restricted, exception namespaces to enforce=baseline. Week 4: add CI validation with kube-score to catch new violations before they hit the cluster.

For development namespaces, I use enforce=baseline (not privileged). Even in dev, you want to catch the most dangerous misconfigurations. Developers should see PSS violations in dev, not discover them when deploying to production.

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. This catches violations at PR time, not deploy time.

Battle-Tested Strategies for Security-First Kubernetes Deployments

Over the years, I’ve learned a few hard lessons about securing Kubernetes in production. Here are some battle-tested strategies:

• Integrate PSS into CI/CD pipelines: Shift security left by validating pod configurations during the build stage. Tools like kube-score and kubesec can analyze your manifests for security risks.
• Monitor pod activity: Use tools like Falco to detect suspicious activity in real-time. For example, Falco can alert you if a pod tries to access sensitive files or execute shell commands.
• Limit permissions: Always follow the principle of least privilege. Avoid running pods as root and restrict access to sensitive resources using Kubernetes RBAC.

Security isn’t just about prevention—it’s also about detection and response. Build solid monitoring and incident response capabilities to complement your Pod Security Standards.

Another effective strategy is to use network policies to control traffic between pods. By defining ingress and egress rules, you can limit communication to only what is necessary, reducing the attack surface of your cluster. For example:

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: Kubernetes default SecurityContext allows privilege escalation, running as root, and full Linux capabilities. 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 is the fix — it makes the secure configuration the default, not the exception.
Future Trends in Kubernetes Pod Security
Kubernetes security is constantly evolving, and Pod Security Standards are no exception. Here’s what the future holds:
Emerging security features: Kubernetes is introducing new features like ephemeral containers and runtime security profiles to enhance pod security. These features aim to reduce attack surfaces and improve isolation.
AI and machine learning: AI-driven tools are becoming more prevalent in Kubernetes security. For example, machine learning models can analyze pod behavior to detect anomalies and predict potential breaches.
Integration with DevSecOps: As DevSecOps practices mature, Pod Security Standards will become integral to automated security workflows. Expect tighter integration with CI/CD tools and security scanners.
Looking ahead, we can also expect greater emphasis on runtime security. While PSS focuses on pre-deployment configurations, runtime security tools like Falco and Sysdig will play a crucial role in detecting and mitigating threats in real-time.
💡 Worth watching: Kubernetes SecurityProfile (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 that will become standard for production hardening.
Strengthening Kubernetes Security with RBAC
RBAC is just one layer of a comprehensive security posture. For the full checklist, see our Kubernetes security checklist for production.
Role-Based Access Control (RBAC) is a cornerstone of Kubernetes security. By defining roles and binding them to users or service accounts, you can control who has access to specific resources and actions within your cluster.
For example, you can create a role that allows read-only access to pods in a specific namespace:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: secure-apps
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
By combining RBAC with PSS, you can achieve a full security posture that addresses both access control and workload configurations.
💡 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 ServiceAccounts per workload with only the verbs and resources they actually need.
🛠️ Recommended Resources:

Tools and books mentioned in (or relevant to) this article:

Kubernetes in Action, 2nd Edition — The definitive guide to deploying and managing K8s in production ($45-55)
Hacking Kubernetes — Threat-driven analysis and defense of K8s clusters ($40-50)


main points

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 tools like OPA, Gatekeeper, and Falco to automate enforcement and monitoring.
Integrate Pod Security Standards into CI/CD pipelines to shift security left.
Stay updated on emerging Kubernetes security features and trends.

Have you implemented Pod Security Standards in your Kubernetes clusters? Share your experiences or horror stories—I’d love to hear them. Next week, we’ll dive into Kubernetes RBAC and how to avoid common pitfalls. Until then, remember: security isn’t optional, it’s foundational.
Keep Reading
More Kubernetes security content from orthogonal.info:

Kubernetes Security Checklist for Production (2026) — The comprehensive checklist to audit your entire K8s deployment.
Secrets Management in Kubernetes: A Security-First Guide — Pod security is only half the battle — lock down your secrets too.
Master Docker Container Security: Best Practices for 2026 — Secure the containers before they ever reach your pods.

🛠️ Recommended Tools

Kubernetes Security (O’Reilly) — Essential reading for anyone managing production Kubernetes clusters.
Kubernetes: Up and Running (3rd Ed) — The foundational guide with solid security sections on RBAC and pod policies.
YubiKey 5 NFC Security Key — Protect your kubectl credentials and cluster admin access.

Frequently Asked Questions

What is Pod Security Standards: A Security-First Guide about?
Kubernetes Pod Security Standards 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
Who should read this article about Pod Security Standards: A Security-First Guide?
Anyone interested in learning about Pod Security Standards: A Security-First Guide and related topics will find this article useful.
What are the key takeaways from Pod Security Standards: A Security-First Guide?
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, an

References

Kubernetes Documentation — “Pod Security Standards”
Kubernetes Documentation — “Pod Security Admission”
OWASP — “Kubernetes Security Cheat Sheet”
NIST — “Application Container Security Guide”
GitHub — “Pod Security Policies Deprecated”

📦 Disclosure: Some links in this article are affiliate links. If you purchase through these links, I earn a small commission at no extra cost to you. I only recommend products I’ve personally used or thoroughly evaluated. This helps support orthogonal.info and keeps the content free.