Kubernetes Frameworks: NIST vs CIS

A new Kubernetes cluster ships with the kubelet listening on an unauthenticated port, the dashboard reachable, anonymous API access enabled on some distributions, and pods free to run as root. None of that is a bug. It is the default, and defaults optimize for "it works," not "it is safe." The job of securing the cluster is the job of closing that gap, and the two documents teams reach for most are NIST SP 800-190 and the CIS Kubernetes Benchmark.

They get compared as if you pick one. You do not. NIST SP 800-190 is a risk guide: it tells you what can go wrong across container technology and why, in prose. The CIS Kubernetes Benchmark is a hardening checklist: it tells you the exact setting to change on the API server, the kubelet, and etcd, and gives you a pass or fail for each. One frames the problem. The other gives you the line-by-line fix. A serious container security program uses both.

This guide defines each framework against its primary source, lays them side by side, shows where they overlap and where they genuinely differ, and gives a straight answer on how to run them together to secure a real cluster.

What is NIST SP 800-190?

NIST SP 800-190, the Application Container Security Guide, is a NIST Special Publication that maps the security risks of container technology and the countermeasures for each. It was published in September 2017 by Murugiah Souppaya, John Morello, and Karen Scarfone. It is 63 pages, it is final, and as of 2026 it has not been revised or superseded. That stability is a feature: it describes the architecture of containers, not the syntax of one product, so the guidance has aged well even as Kubernetes itself moved many versions on.

It is guidance, not a checklist. SP 800-190 does not give you a setting to toggle or a score to chase. It explains what a container image is, how a registry is exposed, what an orchestrator does, and where each one fails. You read it to understand the threat model. You cannot run a scanner against it.

The document is general to containers, not specific to Kubernetes. It names Kubernetes, Mesos, and Docker Swarm as examples of orchestrators and then talks about orchestration generically. Kubernetes appears only a handful of times in the whole document; the word "orchestrator" appears throughout. That is deliberate. The risks SP 800-190 describes apply to any container platform, and Kubernetes is the one most readers happen to run.

SP 800-190 organizes container risk into five components, each with its own risks and its own countermeasures:

• Image risks. Vulnerabilities in the image, embedded malware, plaintext secrets baked into layers, use of untrusted base images, and configuration defects.
• Registry risks. Insecure connections to the registry, stale images that still ship known-vulnerable code, and weak authentication and authorization on who can push or pull.
• Orchestrator risks. Unbounded administrative access, unauthorized access to the cluster, poorly separated inter-container network traffic, mixing workloads of different sensitivity on the same host, and orchestrator node trust.
• Container risks. Vulnerabilities in the runtime, unbounded network access from a container, insecure container runtime configurations, app vulnerabilities, and rogue containers.
• Host OS risks. A large attack surface on the host, shared kernel exposure, host OS component vulnerabilities, improper user access rights, and tampering with the host file system.

That five-part map is the value of SP 800-190. It is the structure a defender uses to make sure no layer of the stack went unconsidered. It tells you to control registry access. It does not tell you which TLS flag on which binary enforces it. For that, you need the second document.

What is the CIS Kubernetes Benchmark?

The CIS Kubernetes Benchmark is a prescriptive, configuration-level hardening standard for Kubernetes, published by the Center for Internet Security. It is a consensus document built and reviewed by a community of practitioners, and it is one of dozens of CIS Benchmarks that cover operating systems, cloud platforms, databases, and applications. The latest version is v2.0.1, on the v2.x line that landed in 2026 and targets Kubernetes 1.34 and 1.35. It is free to download as a PDF after a short registration.

Where SP 800-190 describes, the CIS Benchmark instructs. Each recommendation is a specific, checkable change: the exact flag, the file path, the audit command to verify it, and the remediation to fix it. "Ensure that the --anonymous-auth argument is set to false" is the shape of a CIS recommendation. You can run it, score it, and prove it.

Recommendations are organized so you can apply them by risk tolerance and verify them by tooling:

• Level 1 and Level 2 profiles. Level 1 is a baseline that hardens the cluster with limited operational impact. Level 2 is for environments that need defense in depth and can absorb the tighter constraints and the reduced functionality that come with it.
• Automated and Manual assessment. Each recommendation is marked Automated (a tool can verify it programmatically) or Manual (a human must check it). The older editions called these Scored and Not Scored; the meaning is the same.

The benchmark is organized by the part of the cluster each control protects, which maps cleanly onto Kubernetes architecture:

• Control plane components. The API server, controller manager, scheduler, and etcd: authentication, authorization, admission control, encryption of secrets at rest, and audit logging.
• Worker nodes. The kubelet and its configuration files: disabling anonymous auth, enforcing authorization modes, and locking down file permissions.
• Policies. Role-based access control (RBAC), pod security standards, network policies, and secrets management.

CIS also ships the supporting machinery: CIS-CAT, a tool that audits a system against the benchmark and reports a score, and CIS Hardened Images, prebuilt images configured to the benchmark. CIS Benchmarks also map to other frameworks, which is the bridge back to the strategic layer.

NIST SP 800-190 vs CIS Kubernetes Benchmark

Both aim at the same outcome, a container platform that is hard to attack. They sit at different altitudes. SP 800-190 is the risk model. The CIS Benchmark is the hardening procedure. The difference is what each one is for.

Read the table top to bottom and the split is consistent. SP 800-190 answers the strategic questions: which layers exist, what threatens each, what classes of control reduce the risk. The CIS Benchmark answers the tactical ones: which flag, which file, which command, pass or fail. Neither row competes with the other. They stack.

Where they overlap, and where they actually differ

The overlap is real, and it is what makes people think they have to choose. Both cover the orchestrator. Both care about access control to the cluster, about isolating workloads, about protecting the control plane, about keeping images and the host clean. If you mapped SP 800-190's orchestrator risks against the CIS control-plane and policy sections, you would find the same concerns: limit admin access, authenticate everything, separate sensitive workloads. They agree on what matters.

The differences start with what each one hands you.

Description versus instruction. SP 800-190 says unbounded administrative access to the orchestrator is a risk and you should enforce least privilege. The CIS Benchmark says set the API server --authorization-mode so it does not include AlwaysAllow, and here is the command to check it. One names the goal. The other names the keystroke.

General versus specific. SP 800-190 is true for Docker Swarm, Mesos, and Kubernetes alike, which is why it never tells you a Kubernetes flag. The CIS Kubernetes Benchmark is only about Kubernetes, down to the version, which is why it can. That specificity is also why it expires: a benchmark tied to Kubernetes 1.34 and 1.35 has to be reissued as the platform moves. SP 800-190 has not needed a new edition since 2017 because it never depended on a version.

Auditable versus not. This is the difference that matters most in operations. You can point CIS-CAT at a cluster and get a number: 78 of 120 controls passing, here are the 42 that failed, here is how to fix each. You cannot do that with SP 800-190. It has no controls to score. It is the document you read once to understand the field and return to when you scope a program, not the one you run every night in DevSecOps pipeline checks.

Strategy versus execution. SP 800-190 is where a security architect starts: it defines the five layers and forces coverage of each. The CIS Benchmark is where an engineer works: it turns "harden the kubelet" into 20 concrete, verifiable changes. The gap between those two is exactly the gap between knowing what to do and having done it.

None of this makes either one redundant. SP 800-190 without the CIS Benchmark is a threat model with no remediation. The CIS Benchmark without SP 800-190 is a list of fixes with no map of whether the list is complete. The risk of running only the checklist is real: you can pass every CIS control and still have an exposed registry or an over-permissioned service account, because the checklist's frame is the cluster, not the whole container supply chain. The risk of running only the guide is the opposite: a perfect understanding and an unhardened cluster.

How to use both to secure a cluster

Run them in sequence, not in competition. The two documents are designed to hand off to each other.

Start with NIST SP 800-190 to set scope. Walk the five components, image, registry, orchestrator, container, and host OS, and decide which apply to your environment and which are your highest risk. This produces the threat model and tells you what "secure" has to cover. It catches the layers a config checklist alone would miss, like an exposed registry or an untrusted base image, because those live outside the cluster the benchmark scores.

Then apply the CIS Kubernetes Benchmark to execute on the orchestrator layer. Pick the profile: Level 1 for most production clusters, Level 2 where the workload justifies the operational cost. Harden the control plane, the worker nodes, and the policies item by item, using the audit command in each recommendation to confirm the change took.

Automate the verification. Wire CIS-CAT or an equivalent scanner into the pipeline so the cluster is checked against the benchmark on a schedule, not once at go-live. Configuration drifts. A new node, a Helm chart, a quick fix at 2 a.m. all move the score. A passing audit is only true on the day it ran.

Re-scope on the cadence SP 800-190 sets and re-harden on the cadence CIS sets. SP 800-190 rarely changes, so the threat model is stable: revisit it when your architecture changes, not on a calendar. The CIS Benchmark changes with Kubernetes, so track it: when you upgrade the cluster, move to the matching benchmark version and re-audit.

The practical reading: SP 800-190 is the map, the CIS Benchmark is the route. Use the map to make sure you are securing the whole territory, including the parts outside the cluster. Use the route to get each part actually hardened, with proof. Skip the map and you harden the wrong things well. Skip the route and you know exactly what to do and have not done any of it. This pairing sits inside a broader cloud security program, where the cluster is one tenant among many.

Frequently Asked Questions

What is the difference between NIST SP 800-190 and the CIS Kubernetes Benchmark?

NIST SP 800-190 is descriptive risk guidance: it maps the security risks of container technology across five components (images, registries, orchestrators, containers, host OS) and the countermeasures for each, in prose. The CIS Kubernetes Benchmark is a prescriptive hardening checklist: it gives the exact Kubernetes settings to change, with an audit command and a pass or fail score for each. SP 800-190 frames the problem; the CIS Benchmark provides the line-by-line fix.

Do I have to choose between NIST and CIS for Kubernetes?

No. They operate at different layers and are complementary. NIST SP 800-190 sets the threat model and scope across the whole container stack, including parts outside the cluster like the image registry. The CIS Kubernetes Benchmark hardens and continuously verifies the cluster itself. A mature program uses SP 800-190 to decide what to secure and the CIS Benchmark to execute and prove it.

Is NIST SP 800-190 specific to Kubernetes?

No. SP 800-190 is general to all container technology. It names Kubernetes, Mesos, and Docker Swarm as example orchestrators and then discusses orchestration generically, so its guidance applies to any container platform. The CIS Kubernetes Benchmark is the Kubernetes-specific document, down to the targeted Kubernetes version.

Can I audit a cluster against NIST SP 800-190?

Not directly. SP 800-190 has no scored controls to test, so you cannot point a scanner at a cluster and get a SP 800-190 pass or fail. It is a guide you read to build a threat model. To get an auditable, scored result on a live cluster, use the CIS Kubernetes Benchmark with a tool like CIS-CAT, which checks the cluster against each recommendation and reports a score.

What version of the CIS Kubernetes Benchmark should I use?

Use the version that matches your Kubernetes release. The benchmark is versioned and tracks Kubernetes; the current line is v2.0.1, which targets Kubernetes 1.34 and 1.35. When you upgrade the cluster, move to the matching benchmark version and re-run the audit, because controls and defaults change between Kubernetes releases.

Are NIST SP 800-190 and the CIS Kubernetes Benchmark free?

Yes. NIST SP 800-190 is a public NIST Special Publication and downloads free from the NIST website. The CIS Kubernetes Benchmark is free to download as a PDF from the Center for Internet Security after a short registration. CIS also offers paid tooling and memberships, such as CIS-CAT Pro and CIS Hardened Images, on top of the free benchmark.

The bottom line

NIST SP 800-190 and the CIS Kubernetes Benchmark are not rivals. SP 800-190 is the risk map, stable since 2017, general to all container technology, organized into five layers you have to cover, and read to understand the problem. The CIS Kubernetes Benchmark is the hardening route, versioned to track Kubernetes, specific down to the flag, scored so you can prove the work, and run to fix the problem and keep it fixed.

Use SP 800-190 to scope what "secure" means across the whole container stack. Use the CIS Benchmark to harden and continuously audit the cluster against it. The map keeps you from securing the wrong things well; the route gets the right things actually done, with evidence. Run both, in that order, and re-run the CIS audit every time the cluster changes.