SOC 2 controls for Kubernetes you can automate
SOC 2 doesn’t name Kubernetes settings, but several controls auditors test show up as fields on Kubernetes objects. A policy engine can check those fields on Pods, Roles and images, at admission and in background scans, and keep the results as evidence. It can’t write your policies, run access reviews or approve exceptions.
Why SOC 2 controls need translating first
A SOC 2 examination tests the controls you describe against the AICPA Trust Services Criteria. The auditor measures them against the AICPA Trust Services Criteria, which describe outcomes such as restricting access and protecting systems from threats. They don’t mention pods, Secrets or RBAC. Automation starts when you rewrite an outcome as a setting a machine can read. Anything you can’t write as a setting stays a manual control, with an owner and a record.
Nirmata’s own SOC 2 Type II report is a separate question. Our April 2023 post, Nirmata earns SOC 2 Type II compliance, covers the company’s audit, not the controls on your clusters.
Which controls map to Kubernetes settings
Five control areas cover most of what a Kubernetes policy can test. The right-hand column is the part to put in front of the auditor, because it shows where the automation stops.
| Control area | What the policy checks | What it can’t show |
|---|---|---|
| Limit privileged workloads | privileged on any container, plus hostNetwork, hostPID, hostIPC, hostPath volumes and host ports |
Whether the node operating system is hardened |
| Restrict access to Secrets | Secret references by name, and Secret values passed as environment variables | Whether an application logs Secret data after it reads it |
| Least privilege for identities | Wildcard verbs or resources in Roles and ClusterRoles, and ServiceAccount tokens mounted by default | Whether a person should hold that role at all |
| Control what software runs | Image sources and image signatures | Whether a vulnerability in an approved image has been patched |
| Show the control ran | Check results per resource, from admission and background scans | Who approved an exception |
The Kubernetes Baseline Pod Security Standard already disallows privileged containers and host namespaces, so start there. Add the Secret, RBAC and image checks in the rows above as your scope requires. The Secret row needs one more step that a policy can’t do: applications have to avoid logging Secret data after they read it.
Automate the checks in report mode first
- List the clusters and namespaces in scope, and write down which control area each policy supports. Keep this list, because the auditor will ask for it.
- Write validate rules for the five areas. Kyverno validates resources through Kubernetes admission controls, and it also runs periodic background scanning.
- Run the rules without blocking and read the results for each resource. Group the failures by team so each one has an owner.
- Fix each failure, or record an exception with a named owner. Kyverno’s exception management is built for this.
- Turn enforcement on rule by rule, only after the report for that rule has no open failures.
Checked against the Kubernetes website (main branch) and the Kyverno README (main branch), both fetched 2026-10-25.
What the auditor will test, and what a policy can’t cover
A report is one record in a larger evidence set. Expect the auditor to ask for the policy definitions, the change history that added them, and the exception log. Kyverno only enforces the rules you define, and those rules need maintenance like any other security product. A rule you never wrote is a control you don’t have.
Kyverno also sits beside Kubernetes RBAC rather than replacing it. RBAC controls who can access what, and Kyverno adds checks that RBAC can’t express. Kyverno can’t protect against flaws in the API server itself, so cluster-level hardening stays in scope.
Some controls will stay manual no matter how many rules you write:
- Access reviews and joiner, mover and leaver approvals
- Change approval for work the admission path never sees
- Vendor and third-party risk reviews
- Incident response records and the drills that test them
- Log retention beyond what the cluster emits
Write these down as manual controls, name the owner of each and link to where the evidence lives.
Enforcing this with Kyverno
Nirmata’s nctl maps Kyverno policies to SOC 2, so Nirmata automates SOC 2 checks on Kubernetes. Use nctl’s mapping to see which criteria each policy supports before you cite it in a report. Treat the mapping as a starting point and confirm it with your auditor, because only the auditor can say whether a control satisfies a criterion.
For the wider program, read the continuous compliance hub to see how policy, evidence and audits fit together. The PCI DSS requirements post uses the same split between enforced checks and evidence, and the NIS2 guide covers a second framework. If you want Kyverno packaged for enterprise use, see Nirmata Enterprise for Kyverno.
Frequently asked questions
Does SOC 2 have Kubernetes-specific controls?
No. A SOC 2 examination tests controls against the AICPA Trust Services Criteria, which describe outcomes rather than tools. You translate each outcome into a Kubernetes setting that a policy can read. Auditors will still ask for process records such as access reviews, approvals and incident response, and a cluster policy can't produce those.
Can Kyverno reports serve as SOC 2 evidence?
They can show which resources were checked, what passed and what failed, from admission checks and periodic background scans. That proves a check ran. They don't prove that someone approved the policy, reviewed an exception or acted on a failure. Keep those records next to the reports, since an auditor will ask for them together.
Should SOC 2 policies block workloads or only report on them?
Start by reporting. Read the results for each resource, fix the failures, and record an exception with an owner for anything you can't fix yet. Turn on enforcement once the reports are clean for that rule. Enforcing first can block deployments that the team didn't know were out of policy.
Does Nirmata's own SOC 2 Type II report cover my clusters?
No. Nirmata's SOC 2 Type II report, described in our April 2023 post, covers the controls at Nirmata as a company. Your clusters fall inside your own SOC 2 scope, which you define and your auditor tests. Nirmata's tooling can automate checks inside that scope, but your report doesn't inherit Nirmata's audit, so your auditor still needs evidence from your own environment.