Mastering Pod Security Standards in Kubernetes
Pod Security Standards exist to address the critical need for security in Kubernetes environments. As containerized applications grow, so do the risks associated with misconfigurations and privilege escalations. These standards provide a framework to enforce security policies that can help you mitigate these risks effectively.
The Pod Security Standards define three distinct policies: Privileged, Baseline, and Restricted. The Privileged policy is wide open, allowing for known privilege escalations, which is useful in specific scenarios but risky in production. The Baseline policy strikes a balance, preventing known privilege escalations while allowing a default pod configuration that is easy to adopt. Finally, the Restricted policy enforces stringent hardening best practices, which may limit compatibility but significantly enhance security. Key configuration parameters include disallowing HostProcess containers in the Baseline policy and forbidding HostPath volumes entirely. You can configure security contexts at the container level, ensuring that all containers in a pod adhere to the specified security standards.
In production, be aware that if any container within a pod fails to meet the security requirements, the entire pod will fail validation. This means you must ensure all containers are compliant, which can complicate deployments. The standards are stable as of Kubernetes v1.26, so make sure your clusters are up to date to leverage these features effectively.
Key takeaways
- →Understand the differences between Privileged, Baseline, and Restricted policies.
- →Disallow HostProcess containers in the Baseline policy to prevent privilege escalations.
- →Forbid HostPath volumes to enhance pod security.
- →Ensure all containers in a pod meet security requirements to avoid validation failures.
- →Apply the RuntimeDefault AppArmor profile on supported hosts for added security.
Why it matters
Implementing Pod Security Standards can drastically reduce the attack surface of your Kubernetes clusters, protecting sensitive workloads from unauthorized access and privilege escalation.
Code examples
spec.containers[*].securityContextspec.volumes[*].hostPathspec.securityContext.seccompProfile.typeWhen NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsUnified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.
Try Better Stack free →Runtime Supply Chain Verification with NRI: Securing Your Kubernetes Deployments
In a world where supply chain attacks are rampant, ensuring the integrity of your container images is crucial. The Node Resource Interface (NRI) allows you to enforce supply chain verification at runtime, leveraging plugins to validate image attestations before they even start. Dive into how this mechanism works and what you need to watch out for in production.
Unlocking Data Security: Confidential Containers in Kubernetes
Confidential Containers are revolutionizing data protection in cloud-native environments by leveraging Trusted Execution Environments (TEEs). This technology ensures that sensitive workloads can run securely on third-party infrastructure without exposing data to operators.
Making Kyverno Think It's in Production: A Practical Guide
Ever wondered how to test your Kubernetes policies without deploying them? Learn how to leverage Kyverno's CLI to simulate a production environment, ensuring your policies are battle-tested before they hit the cluster. This article dives into the mechanics of using resolveResourcesMockData for reliable policy evaluation.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.