Pod Security Standards
Pod security standards set safety rules for how containers run inside Kubernetes. You turn them on by adding labels to a cluster namespace. Many teams start with wide permissions so new apps deploy fast. Broad permissions let a bad container touch the host machine. Attackers can use a wide role to read host files. Setting clear boundaries keeps workloads safe and limits blast radius. How pod security standards work in Kubernetes Kubernetes groups container safety rules into three clear levels
K8s Pod Security Standards: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Pod security standards set safety rules for how containers run inside Kubernetes. You turn them on by adding labels to a cluster namespace. Many teams start with wide permissions so new apps deploy fast. Broad permissions let a bad container touch the host machine. Attackers can use a wide role to read host files. Setting clear boundaries keeps workloads safe and limits blast radius.
How pod security standards work in Kubernetes
Kubernetes groups container safety rules into three clear levels. The first level is privileged and puts no limits on pods. Teams use this open level for system tools and network drivers. The second level is baseline and blocks known host exploits. Baseline stops pods from sharing host networks or host process spaces. It provides a good starting point for most daily workloads. The third level is restricted and follows strict container hardening steps. Restricted requires pods to drop root rights and limit system calls.
A built-in admission controller checks every new pod against these levels. You pick how the cluster reacts when a pod breaks a rule. Enforce mode blocks the bad pod from starting at all. Audit mode lets the pod run but writes a note in the log. Warn mode lets the pod run and shows a warning to the user. Teams often mix these modes on one namespace at the same time. You can enforce the baseline level while warning on restricted rules. This lets developers see future rule changes before pods get blocked.
What namespace rules solve and what they miss
Namespace rules solve the problem of unsafe pod settings at startup. They stop engineers from deploying root containers by mistake. They also block pods from mounting sensitive host disk paths. The admission controller catches these mistakes before a container ever starts. This gives platform teams a simple way to set cluster baselines. You do not need third-party policy engines just to block root pods.
Still, startup checks only look at the pod spec on creation. They do not watch what engineers do after the pod starts. An engineer with exec permissions can still open a shell inside a running pod. Once inside, that user can run commands or read app secrets. The cluster checks who logs in, not what commands run in flight. A restricted pod can still hold keys to a production database. Someone inside that pod can query customer emails or card numbers. Startup rules also do not mask sensitive data returned by terminal commands. Platform teams must pair pod creation rules with live command controls.
K8s Pod Security Standards: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Steps to roll out namespace rules safely
Start by checking your current workloads in a test cluster. Apply warn and audit modes for the baseline level first. Watch the warning messages when your team deploys their apps. Read the audit logs to find pods that need broad host rights. Move system pods that need host access into their own dedicated namespace. Once app pods pass the checks, turn on enforce mode for baseline.
Next, test the restricted level using warn mode on app namespaces. Update your deployment files so containers run as non-root users. Drop extra Linux kernel rights that your web apps do not need. When warnings stop appearing in your logs, switch restricted mode to enforce. Keep reviewing your namespaces so new projects follow the same path.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What happens to running pods when I enforce a stricter level?
Existing pods keep running when you change namespace labels. The admission controller only checks new pods during creation. Still, controllers like deployments will fail when they try to create replacement pods.
Can I apply different security levels to pods in the same namespace?
No, these rules apply to the whole namespace at once. If one app needs broad host rights, put it in a separate namespace. This keeps your main app namespace locked down.
Do pod security standards replace network policies?
No, these rules only control how a pod interacts with the host node. They do not block network traffic between pods. You still need network policies to control traffic flow across the cluster.