Pod security standards are one of the few Kubernetes controls that can reduce real risk without turning your cluster into a maze. If you run shared clusters, regulated workloads, or just enough services to make one bad manifest expensive, pod security standards deserve a close look.

This is not about checkbox compliance. It is about stopping obvious abuse paths: privileged containers, writable root filesystems, host namespace access, and workloads that can mutate the node beneath them. Those are the mistakes that turn a small app bug into a cluster problem.

At Champlin Enterprises, we write about this from the operator side. Kevin has been shipping production software since 1998, and the lesson never changes: the easiest security control is the one engineers can keep on by default.

Table of Contents

What Pod Security Standards Actually Do

Kubernetes Pod Security Standards are a built-in policy framework for controlling how pods are allowed to run. They replaced the older PodSecurityPolicy model, which was more flexible but also more painful to operate. The standards are simple by design: privileged, baseline, and restricted.

That simplicity is the point. Most teams do not need a custom policy language on day one. They need a clear answer to questions like: can this workload run as root, can it use the host network, can it mount the Docker socket, can it write to the root filesystem, can it add Linux capabilities? Pod security standards answer those questions at the namespace boundary.

A practical mental model helps. Treat pod security standards as a seatbelt, not a firewall. They do not replace image scanning, runtime detection, network policy, or RBAC. They remove a large class of dangerous defaults before the pod ever starts. If you want a deeper look at access control inside the cluster, pair this post with our Kubernetes RBAC: Managing Access Control Effectively article.

The main value is consistency. Without a standard, every team makes its own judgment call, and those calls drift. One service ends up privileged because a developer needed a quick file permission workaround. Another mounts a hostPath because a sidecar wanted logs. That is how technical debt sneaks into the security posture.

Use pod security standards to make the safe path the default path. Then make exceptions rare, visible, and temporary.

Baseline vs Restricted: Choosing the Right Level

The first real decision is which level to enforce. Baseline blocks the most obvious escalation paths while still allowing many practical workloads. Restricted goes further and is the right end state for most mature application namespaces. Privileged should be reserved for infrastructure components that truly need it, and even then only with tight scope.

If you are early in the rollout, start by auditing in baseline mode. That gives you signal without breaking every deployment. Once you understand the exceptions, move application namespaces to restricted and keep system namespaces separate. A cluster with a single policy tier is usually a cluster with hidden risk.

Here is the trade-off in plain English:

  • Baseline: good for migration, legacy workloads, and mixed maturity teams.
  • Restricted: good for modern app namespaces, especially stateless services.
  • Privileged: for CNI plugins, node agents, and other infrastructure components that need elevated access.

Restricted is not always free. Some older container images still run as root by default. Some build tools expect writable home directories. Some sidecars assume they can write to arbitrary paths. That does not mean restricted is wrong. It means the workload needs cleanup.

In practice, the decision often comes down to one question: can the workload function with runAsNonRoot, readOnlyRootFilesystem, and no extra Linux capabilities? If yes, restricted is usually the right answer. If not, fix the image or isolate the exception.

A useful pattern is to pair policy enforcement with a manifest checklist in code review. For teams using Next.js, API services, or worker pods, the same standards should apply. The app type changes; the attack surface does not.

Admission Controls and Rollout Strategy

Pod security standards are enforced through namespace labels and admission control. That means rollout strategy matters. If you flip every namespace to restricted on a Monday morning, you will spend the day reading failed deploy logs and undoing the change.

Use a staged rollout. Start with audit or warn mode in a handful of namespaces, then move to enforce once you know what breaks. Kubernetes supports labels such as pod-security.kubernetes.io/enforce, warn, and audit. That makes it possible to learn before you block.

A simple progression looks like this:

  1. Label one non-critical namespace with warn=restricted.
  2. Fix the obvious violations in CI and manifests.
  3. Move the namespace to audit=restricted and watch for noisy exceptions.
  4. Switch to enforce=restricted once the failure rate is low.

The important part is that policy should fail fast in the cluster, not surprise engineers after a deployment reaches production. Good teams catch this in GitOps, admission review, or pre-merge validation. If you already use a deployment pipeline, this is a natural place to add checks alongside image scanning and signed artifacts. Our post on CI/CD Security Hardening: Protecting Your Pipeline pairs well with that work.

One concrete tool recommendation: use Kyverno or OPA Gatekeeper only when you need policy beyond the built-in standards. Do not reach for them first. Pod security standards handle a lot of the basics with less operational overhead. Extra policy engines are useful, but every additional controller is another thing to debug when deploys fail.

In a real rollout, I like to keep a short exception register. Namespace, owner, reason, expiry date. If an exception has no expiry date, it is not an exception. It is policy drift with paperwork.

Common Manifest Mistakes to Fix First

The fastest way to improve pod security is to fix the manifest patterns that show up everywhere. Most of them are not subtle. They are the defaults people inherit from examples, Helm charts, or old internal templates.

Start with these fields:

  • runAsNonRoot: true
  • readOnlyRootFilesystem: true where possible
  • allowPrivilegeEscalation: false
  • Drop unnecessary Linux capabilities
  • Avoid hostNetwork, hostPID, and hostIPC
  • Do not mount the Docker socket unless you absolutely mean it

Here is a minimal example of a safer container security context:

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: ghcr.io/example/api:1.2.3
      securityContext:
        runAsNonRoot: true
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

This looks small. It is not small in effect. Dropping capabilities and forbidding privilege escalation eliminates a lot of accidental exposure. If an exploit lands inside the process, the container has fewer paths outward.

The usual failure mode is not malicious intent. It is app code that assumes it can write temp files, generate cache entries, or modify configuration in place. The fix is architectural discipline: mount writable volumes only where needed, keep ephemeral state in memory or Redis, and stop treating the container filesystem like a laptop. For teams doing API work, the storage pattern often matters more than the language runtime.

Another common issue is running init containers with broad permissions because someone wanted a one-time setup step. That is often a smell. If an init container needs elevated rights, ask whether the task belongs in the image build, a migration job, or a separate admin tool. This is the same kind of judgment we use when weighing Build vs Buy Decision Framework for CTOs: do the smallest thing that solves the actual problem.

Operating Pod Security Standards Over Time

Security policy is not a one-time project. It is an operating habit. Once pod security standards are in place, the real work is keeping them from decaying under the pressure of urgent fixes, vendor charts, and one-off exceptions.

I recommend three recurring practices. First, add policy checks to CI so broken manifests fail before they ship. Second, review namespace labels quarterly and remove anything that no longer belongs in privileged mode. Third, keep a short list of approved exceptions with owners and expiry dates. If you cannot explain why a namespace is privileged, it probably should not be.

It also helps to track the cost of violations. Not in abstract risk language. In actual time. How long does it take to debug a blocked deploy? How often do teams ask for exceptions? Which base images keep tripping restricted mode? Those answers tell you whether your policy is well tuned or just noisy. Good security work reduces load on the team; bad security work just relocates it.

For larger environments, separate workload classes. Infrastructure namespaces can stay more permissive. Application namespaces should be restricted by default. Batch jobs and migration jobs may need specific carve-outs. That separation keeps the blast radius small when a chart or operator behaves badly.

If you want to see how we think about operational discipline beyond Kubernetes, our Choosing the Right CI/CD Pipeline for Microservices post covers the same principle from the delivery side. The details change. The discipline does not.

Pod security standards are not glamorous, but they are one of the cleanest ways to reduce cluster risk without slowing the team to a crawl. If your manifests still assume root, writable filesystems, and broad namespace access, you are paying for that assumption somewhere else.

That cost shows up as incident time, audit friction, and hidden operational drag. If this is the kind of problem you need to get out of the way, you can apply for an engagement; the application takes ten minutes. We take three engagements a quarter, and a focused Sprint is often the right shape when the outcome is a hardened namespace policy, a manifest audit, or a clean rollout plan.