Pod Security

Understand Pod Security controls, securityContext, privileged containers, root users, capabilities, host access, and admission policy.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: Pod Security controls reduce what containers can do on nodes and inside the cluster.

🔍 What Is It?

Pod Security is the set of Kubernetes controls and policies that limit risky Pod behavior.

It includes Pod Security Admission, securityContext, non-root execution, capabilities, seccomp, host namespace restrictions, and admission policy tools.

🎯 Why Do We Need It?

Containers share node kernels. Risky Pod settings can expose host files, privileged operations, credentials, or neighboring workloads.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

A platform labels namespaces with restricted Pod Security standards. Application Pods must run as non-root, drop Linux capabilities, avoid hostPath, and use read-only root filesystems where practical.

⚙️ How It Works

Admission controllers validate Pod specs before creation. securityContext settings define runtime user, privileges, capabilities, seccomp profile, and filesystem behavior.

💻 Example

Restricted security context — A safer container runtime baseline.

yaml
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: api
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

🤔 Common Confusions

❓ Is Pod Security the same as NetworkPolicy?

No. Pod Security controls runtime privileges. NetworkPolicy controls network traffic.

❓ Can all apps run with read-only root filesystem?

Not all without changes. Apps may need writable tmp volumes or code changes.

❓ Are privileged Pods always bad?

Some platform agents need elevated permissions, but they require strict ownership and review.

🚨 Common Production Issues

**Privileged containers** can access host-level capabilities.

**Running as root** increases impact of container compromise.

**hostPath mounts** expose sensitive node files.

**No admission policy** lets risky specs reach production.

✅ Best Practices

Use restricted Pod Security standards for app namespaces

Run as non-root and drop capabilities

Avoid privileged and hostPath usage for application Pods

Use seccomp RuntimeDefault

Review exceptions centrally

🏛️ Architect's Note

Senior Architect's Perspective

Pod Security is a blast-radius control. The goal is not perfect isolation; it is making compromise harder and less damaging.

💬 Frequently Asked Questions

Interview: How would you explain Pod Security in a real Kubernetes project?

Pod Security should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with Pod Security?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

🎯 Key Takeaways

1Pod Security limits risky container behavior
2securityContext is central
3Admission policy enforces standards
4Exceptions need strong ownership

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages