NIST 800-53 controls for Kubernetes: a mapping guide

NIST SP 800-53 Rev. 5 is a catalog of security and privacy controls, and it does not describe Kubernetes settings. Kubernetes policy can check the configuration controls, such as privileged pods, host namespaces, RBAC wildcards and image sources. Approvals, access reviews and audit records stay outside the cluster.

What this mapping covers

This guide links a NIST control to a Kubernetes setting only where the NIST control text and a Kubernetes or Kyverno page both support the link. Treat the result as a starting point for your assessor, not a certification. It covers SP 800-53 only and says nothing about FedRAMP. This is a desk review: we have not run these rules on a cluster for this post, so no first-hand result is claimed here.

The control wording below comes from the release 5.2.0 OSCAL catalog. Short phrases are quoted exactly. Everything else is paraphrased.

The control-to-setting table

Each row names the control, the part of its statement that matters for a cluster, the setting a policy reads, and how far a policy gets you.

NIST control	What the statement asks for	Kubernetes setting a policy reads	Coverage
CM-6 Configuration Settings	Settings that reflect “the most restrictive mode consistent with operational requirements”	privileged, hostNetwork, hostPID, hostIPC, hostPath	Enforceable on fields
CM-7 Least Functionality	Provide “only” the functions the system needs	hostPath volumes, hostPort, capabilities added to containers	Enforceable on fields
CM-7(5) Authorized Software	A “deny-all, permit-by-exception policy” for software	Signature checks with verifyImages	Partial
SI-7 Software, Firmware, and Information Integrity	“Employ integrity verification tools to detect unauthorized changes”	verifyImages at admission	Partial
AC-6 Least Privilege	“allowing only authorized accesses” that are necessary for the task	verbs and resources wildcards in Roles and ClusterRoles	Partial
IA-5 Authenticator Management	“Protecting authenticator content from unauthorized disclosure”	Secret get, watch and list in RBAC, and Secret references in Pods	Partial
SC-39 Process Isolation	“a separate execution domain for each executing system process”	hostPID and hostIPC set to false	Our mapping, not sourced
AU-12 Audit Record Generation	Audit records for defined event types	Kyverno policy report results	Not mapped

The AU-12 row is not a match. Kyverno policy reports record the outcome of a policy check. They are not the system audit records that AU-12 describes, so don’t cite them for it.

Pod Security fields for CM-6 and CM-7

The Kubernetes Pod Security Standards page treats privileged pods as the first thing to block. Its Baseline level says: “Privileged Pods disable most security mechanisms and must be disallowed.” The same level requires privileged to be unset or false, hostNetwork, hostPID and hostIPC to be unset or false, and hostPath volumes to be absent.

Those are fields a policy reads on the Pod spec, so they can be checked at admission and in background scans. They cover the “most restrictive mode” wording in CM-6 for these settings. They do not cover every configuration setting on a node or in the control plane.

Host ports are a separate row in the Baseline table. Unset, 0 or a known list is allowed. For CM-7, that means a policy can restrict which host ports a workload uses, which is the “only” in the control text applied to ports.

RBAC and Secrets for AC-6 and IA-5

The Kubernetes RBAC good-practices page says: “Avoid providing wildcard permissions when possible, especially to all resources.” A wildcard in verbs or resources grants access to object types created later, so a policy can flag any Role or ClusterRole that uses one. It can’t tell whether a person needs the role at all.

For Secrets, the Kubernetes guidance says to restrict get, watch and list access to Secrets for humans, and to allow only cluster administrators to reach etcd. A policy can check the verbs in RBAC objects. It can’t check who is bound to them, or whether an application logs Secret data after it reads it.

Image checks for CM-7(5) and SI-7

CM-7(5) asks for an allow-by-exception policy for software. The closest setting in the pages we fetched is an image signature check, so a verifyImages rule can require a signature on each image.

Kyverno’s verifyImages rule checks signatures and attestations with attestors, such as Sigstore Cosign keys or keyless attestors. The page says required defaults to true, and it can also convert tags to digests with mutateDigest and enforce digests with verifyDigest. The rule runs in the mutation and validation webhooks, so the check happens at admission.

The page does not say what happens when verification fails. Test that on your Kyverno release before you describe it in an evidence pack.

SI-7 asks for tools that detect unauthorized changes. A signature check stops an unsigned image from being admitted, but the verifyImages rule runs at admission, so it doesn’t check what is already running. Treat SI-7 as partial.

Run the mapping in Audit mode first

1. List the controls in scope and the setting each one maps to, using the table above. Keep the list, because the assessor will ask for it.
2. Write validate rules for the settings you listed. Set failureAction to Audit so that violations are recorded without being blocked.
3. Let background scanning run, then read the results for each resource under the results[] object of its PolicyReport.
4. Fix each failure. For anything you can’t fix yet, record a PolicyException with a named owner.
5. Switch a rule to Enforce only after its report has no open failures. Repeat this rule by rule.

Checked against the kubernetes.io and kyverno.io docs, fetched 2026-10-28, and the NIST SP 800-53 Rev. 5 catalog, release 5.2.0. The steps in this post have not been run on a stated Kyverno version. They are desk-checked against the docs and must be run on a named Kyverno release before publish.

Gotchas from the fine print

Audit mode allows the resource and records the result. The Kyverno policy reports page says: “Because the rule is written with failureAction: Audit, resources are allowed to be created which violate the rule.” The violation then appears as a FAIL in the PolicyReport, so an auditor sees the record, but nothing was blocked.

Enforce doesn’t clean up what’s already there. The background scanning page says the scan “does not block any existing resources that match a rule, even in Enforce mode.” Existing violations are a separate decision, covered in the FAQ.

On the Kubernetes side, a service account token setting can be overridden. The docs say: “If both the ServiceAccount and the Pod’s .spec specify a value for automountServiceAccountToken, the Pod spec takes precedence.” Check the Pod field as well as the ServiceAccount.

Exceptions have their own version change. The Kyverno exceptions page says a PolicyException is a namespaced resource. The current version is in the policies.kyverno.io group and works with CEL-based policy types such as ValidatingPolicy and ImageValidatingPolicy. The legacy kyverno.io kind is deprecated as of v1.19 and slated for removal in v1.20.

Controls that stay manual

Several controls in this family are process controls, and no cluster setting satisfies them. Keep them in your evidence set with an owner and a link to where the record lives.

• AC-2 Account Management, which includes approvals for account creation and reviews of accounts.
• CM-3 Configuration Change Control, which requires review and approval of proposed changes.
• RA-5 Vulnerability Monitoring and Scanning. The Kyverno pages above cover signatures and attestations, not vulnerability scanning of images.
• AU-12 Audit Record Generation for system events. Collect these from the platform’s own logging, not from policy reports.

Enforcing this with Kyverno

Nirmata’s nctl maps Kyverno policies to NIST 800-53, so Nirmata automates NIST 800-53 checks on Kubernetes. The control-to-setting table in this post is our own desk mapping, not nctl’s mapping, so check it against your own rules before you cite it in an evidence pack. Treat the claim above as a starting point and confirm it with your assessor, because only the assessor can say whether a control is satisfied.

For the wider program, read the continuous compliance hub. The PCI DSS requirements post and the SOC 2 controls post follow the same split between enforced checks and evidence. The NIS2 guide and the NSA hardening post cover other frameworks. For packaged Kyverno for enterprise use, see Nirmata Enterprise for Kyverno.

Frequently asked questions

Does NIST 800-53 have Kubernetes-specific controls?

No. SP 800-53 Rev. 5 is a catalog of controls for information systems and organizations, and it does not describe Kubernetes settings. To use it on a cluster, you translate each control into a setting a policy can read, such as a privileged flag or an RBAC verb. The mapping in this guide is one way to do that, and your assessor may read a control differently.

Does a Kyverno policy make a cluster compliant with NIST 800-53?

No. A rule shows that one configuration check exists and gives you results to review. It does not satisfy a control on its own. Many controls depend on process records such as approvals, reviews and incident response. Only your assessor can say whether a control is satisfied, so cite each mapped rule as one piece of evidence.

Should NIST 800-53 policies block workloads or only report on them?

Start in Audit mode. Audit rules allow violating resources to be created and record each failure in a policy report. Read the results per resource, fix the failures, and record exceptions with an owner for the rest. Switch a rule to Enforce only after its report has no open failures, so you don't block deployments the team didn't know were out of policy.

Does enforcing a rule remove resources that already break it?

No. Kyverno's background scanning does not block existing resources that match a rule, even in Enforce mode. Enforce stops new violations at create and update. Setting allowExistingViolations to false also blocks later updates to resources that already violate the rule, so decide whether you want that before you turn it on.

Does this mapping cover FedRAMP?

No. This guide covers NIST SP 800-53 Rev. 5 only and says nothing about FedRAMP authorization. If you need to meet a FedRAMP baseline, confirm with the body that authorizes your system which controls apply, and which evidence it expects, before you rely on any mapping here.