There is a version of a Kubernetes security baseline that exists in almost every growing engineering organization. It is technically correct. It references the right standards. It probably came from a CIS benchmark, a compliance audit, or a well-intentioned security review. And it is functionally useless.
Nobody enforces it consistently. Developers do not know it exists. The platform team knows it exists but cannot explain all of it. Exceptions accumulate informally. When someone asks “what is our current security posture?”, the honest answer is “somewhere between the baseline document and whatever is actually running.”
This is not a rare situation. It is the default outcome when a baseline is designed to satisfy an external requirement rather than to be adopted by a real engineering team.
This article is about the difference between a baseline that exists and a baseline that works.
Why most baselines are not actually usable
A baseline becomes unusable when it is built the wrong way — starting from a comprehensive list of security controls and working backwards to what the team might accept.
The CIS Kubernetes Benchmark has over 200 checks. The NSA/CISA Kubernetes Hardening Guide covers everything from API server flags to node security. These are valuable reference documents. But they are not baselines. They are catalogs. Treating a catalog as a baseline is one of the most common mistakes teams make.
When you start from a catalog, you get a baseline that:
- Contains controls that nobody on the team can explain in plain language
- Contains controls that are technically correct but have no clear owner
- Includes everything, which means prioritizing nothing
- Is immediately overwhelming to any developer who encounters it
The first time a developer hits an enforcement block from a control they have never heard of, explained by a policy document they have never been shown, the policy program loses credibility. And credibility lost this way is genuinely hard to recover.
What a usable baseline is actually built on
A usable baseline starts from a different question. Not “what does the benchmark say?” but “what can we enforce consistently, explain clearly, and maintain over time?”
That question has three parts, and all three matter.
Enforce consistently means the control applies everywhere it should, with no silent exceptions, no namespaces that were quietly left out, no workloads that are technically in scope but practically exempt. Inconsistent enforcement is worse than no enforcement in some ways — it creates a false picture of posture and makes exceptions invisible.
Explain clearly means any developer on the team can understand what the control requires and why. If the explanation requires reading a 40-page benchmark document, the control is not ready to be in the baseline. The test is simple: can a platform engineer explain this control in two sentences to a backend developer who has never worked on a security project?
Maintain over time means when a new cluster is created, when a team ships a new service, when Kubernetes releases a new version — the baseline still applies without significant manual effort. Controls that require constant manual review or that break on minor version upgrades are not sustainable.
A baseline built on these three constraints will be smaller than a CIS benchmark. That is intentional. A narrow baseline that is actually enforced is dramatically more valuable than a comprehensive baseline that exists mostly on paper.
The controls that belong in a first baseline
There is no universal answer here, but there is a useful heuristic: start with the controls that are independently justified. These are controls where, if someone asks “why does this exist?”, the answer is specific and concrete, not “because the benchmark says so.”
The controls that tend to meet this bar consistently:
No containers running as root. The reason is specific: a process running as root inside a container that escapes the container boundary has immediate root access on the node. This is explainable. The fix is a specific change to the security context. The impact on developers is contained.
No privilege escalation via allowPrivilegeEscalation: false. Related to the above, and equally explainable. Prevents a non-root process from gaining root through setuid binaries.
Read-only root filesystem where possible. Limits the blast radius of a compromised container. The developer impact is real — applications that write to local disk need to be updated to use mounted volumes — but the ask is concrete.
No hostPath volume mounts. A container with access to the host filesystem has a path to a wide range of sensitive data. There are legitimate exceptions for infrastructure components, but for application workloads, this is straightforward to enforce.
Image tag pinning (no latest). Not strictly a security control, but it makes security controls more effective. If you cannot reproduce the exact container that is running, you cannot reason about what vulnerabilities it contains.
Resource limits defined. Not a security control in the traditional sense, but a baseline dependency — workloads without resource limits can be used as a vector for noisy neighbor attacks and denial of service within a cluster.
Notice what is not on this list: a long tail of API server configuration flags, network policies, RBAC controls, and admission controller settings. Those matter. They are not in a first baseline because a first baseline needs to be something a team can actually implement and enforce in a realistic timeframe.
Pod Security Standards: the default starting point for most teams
If you are building a baseline from scratch in 2026, Pod Security Standards (PSA) should be your first consideration before reaching for Kyverno or OPA Gatekeeper.
PSA is built into Kubernetes. It requires no external admission controller, no webhook dependency, no additional tooling to maintain. It provides three levels — Privileged, Baseline, and Restricted — that correspond to meaningful security posture tiers.
The Baseline level covers most of what was listed above: no privileged containers, no host namespace access, no hostPath volumes, restricted capabilities, no privilege escalation. For many teams, enforcing PSA Baseline across non-system namespaces is a complete first baseline.
The Restricted level adds read-only root filesystem requirements, drops all capabilities, requires running as non-root. This is a meaningful security improvement over Baseline, but it has more developer impact and requires more careful rollout.
The practical approach: apply PSA Baseline in warn mode first across all application namespaces. Let it surface what would fail. Fix the fixable things. Document the legitimate exceptions. Then move to enforce. This can be done without any additional tooling and gives you a real, enforced baseline in a timeline measured in weeks, not months.
The exception model is part of the baseline
A baseline without an exception model is incomplete. In every real environment, there are workloads that have a legitimate reason not to comply with one or more baseline controls. Infrastructure components, legacy services being migrated, third-party tools with specific requirements.
The mistake is handling these informally. A comment in a ticket. A namespace that was quietly excluded. An undocumented label that disables a policy.
Informal exceptions have two problems. First, they are invisible — over time, nobody knows which workloads are exempt or why. Second, they accumulate — once the pattern of informal exceptions is established, it becomes the path of least resistance for every new exception.
A minimal exception record has four fields:
- What is exempt (specific namespace or workload, not cluster-wide)
- Why it cannot comply (specific technical reason, not “legacy”)
- Who owns the exception (named individual or team)
- Review date — when will this be revisited
This is five minutes of work per exception. But those five minutes mean the exception is a tracked artifact rather than invisible technical debt.
How to know if your baseline is actually working
A baseline that is working has a few observable properties.
Developers know it exists and know what it requires. Not because they read a policy document, but because when they ship a new service, they get feedback in CI before anything reaches the cluster.
Violations are rare and understood. Not because the baseline is lenient, but because the baseline is clear enough that developers can comply with it without special guidance.
Exceptions are visible and tracked. Anyone on the platform team can list the current exceptions and explain each one.
The baseline has not grown significantly since it was first defined. A baseline that is constantly expanding is a baseline that is being used as a catch-all rather than a deliberate standard.
If your current baseline fails any of these tests, the problem is almost certainly not that it needs more controls. It is that the controls that are there are not actually enforced and understood in the way described above.
The harder question
The technical content of a Kubernetes security baseline is actually the easier part of the problem. The harder part is the organizational work: getting alignment on what belongs in it, getting developer buy-in before enforcement, making exceptions visible, and maintaining it as the environment changes.
Most teams that have a struggling baseline have a technical artifact that is fine and an organizational process that is missing. The artifact says what to do. The process — who owns it, how it gets communicated, how exceptions get handled, how it gets updated — was never built.
That is the work that actually determines whether a baseline is usable. And it is also the work that most security tools and benchmark documents do not address at all.
ClarifyIntel helps engineering teams build Kubernetes security baselines that their teams can actually adopt — with clear policy direction, structured exception models, and rollout plans that reduce friction. If your current baseline is not working the way it should, send us a note.