Kubernetes and SOC 2: controls for containerized environments
SOC 2 was not written with containers in mind, so the work is mapping its criteria onto Kubernetes-native mechanisms. Here is how RBAC, secrets, network policy, admission control, and GitOps line up with what auditors actually test.
Translating SOC 2 criteria to a cluster
SOC 2's Trust Services Criteria are deliberately technology-agnostic, which means the framework never mentions pods, namespaces, or admission webhooks. The compliance work in a cloud-native shop is translation: showing how each relevant criterion is satisfied by a Kubernetes mechanism. Logical access (CC6.1) maps to RBAC and authentication; system change management (CC8.1) maps to your deployment pipeline; monitoring (CC7.x) maps to audit and runtime logging. Auditors increasingly understand this stack, but the burden is on you to draw the mapping clearly and produce evidence that the cluster-level control operated, not just that it exists in a manifest.
Access: RBAC, least privilege, and admission control
Kubernetes RBAC is your primary answer to CC6.1's requirement to restrict logical access to system resources, so auditors will look for narrowly scoped Roles and RoleBindings rather than broad cluster-admin grants, and for service accounts that are not over-privileged or sharing tokens. Tie human access to your central identity provider with SSO and MFA rather than long-lived kubeconfig credentials. Admission control is the enforcement layer that keeps least privilege real: policy engines such as those built on the Kubernetes-native validating admission webhook model (for example OPA Gatekeeper or Kyverno) can block privileged pods, enforce non-root containers, and reject images from untrusted registries before they ever schedule. That preventive posture is far easier to evidence than after-the-fact cleanup.
Secrets, network segmentation, and image integrity
Native Kubernetes Secrets are only base64-encoded by default, so auditors examining CC6.x confidentiality controls will expect encryption at rest for etcd, integration with an external manager such as a cloud KMS or HashiCorp Vault, rotation schedules, and proof that plaintext secrets never land in logs or committed config. NetworkPolicies provide the segmentation story: default-deny between pods, explicit allow-lists, and namespaces separated by trust level so a compromised workload cannot move laterally. For supply-chain integrity, demonstrate image vulnerability scanning in the pipeline and in the registry, base-image hygiene, and ideally image signing with verification enforced at admission, since unscanned or unsigned images are a common source of findings.
Change management through GitOps and immutability
Change management (CC8.1) is often where Kubernetes shops have the strongest story, because a GitOps model maps almost perfectly to what auditors want. When desired state lives in version control and a reconciler such as Argo CD or Flux applies it, every change carries a reviewed pull request, an approver, and an immutable audit trail, which is precisely the authorization-and-tracking evidence the criterion calls for. Pair that with immutable infrastructure, where containers are replaced rather than patched in place and direct kubectl edits to production are blocked, and configuration drift largely disappears. The practical payoff is that your evidence is your Git history rather than a manually assembled change log.
Logging, monitoring, and what auditors actually inspect
The Kubernetes API server audit log is the spine of your monitoring evidence for CC7.x, capturing who did what against the control plane, and it should be shipped to tamper-resistant, retained storage outside the cluster alongside runtime and application logs. Auditors will want to see alerting on anomalous or privileged activity and evidence that someone reviews it on a defined cadence, not just that logs are collected. In a Type II engagement they sample across the observation window, so a single point-in-time snapshot of a hardened cluster is not enough; the RBAC reviews, scan results, policy denials, and log reviews have to recur. The cleanest path is to bake these checks into the platform itself so the operating evidence is generated as a byproduct of running the system.