Container Security and SOC 2: Kubernetes in the Audit Room

Your infrastructure runs on pods, clusters, and GitOps pipelines. Your compliance framework, however, was written for physical servers, hardware firewalls, and manual change tickets.

This is the fundamental friction of SOC 2 Kubernetes audits. Kubernetes is the default deployment platform for modern SaaS, but SOC 2 was authored with an entirely different infrastructure paradigm in mind. Bridging the two requires translating what the framework demands into how containerized environments actually operate.

That gap between framework language and operational reality is exactly where audit surprises happen.

The Audit Scope Question

The first question an auditor will ask about your cluster is deceptively simple: what is it processing?

If your production workloads handle customer data on Kubernetes, your Kubernetes environment is in scope for your SOC 2 audit. There is no exemption for modern infrastructure.

What that means in practice

The controls that govern traditional production systems apply directly to SOC 2 container security:

• Change management: Applies to container image deployments
• Access control: Applies to your cluster
• Logging and monitoring: Applies to your containerized workloads
• Vulnerability management: Applies to your container images, and their base images

None of this is surprising once you map the concepts. The real challenge is proving you have actually implemented them.

Image Security and Vulnerability Management

SOC 2 CC7.1 requires you to monitor for and address system vulnerabilities.

In a containerized world, those vulnerabilities live at two distinct layers:

1. The base image: the OS and runtime libraries in your container image
2. Your application: your code and its dependencies

Container image scanning

Scanning is the mechanism of discovery. Tools like Trivy, Snyk Container, Aqua Security, and AWS ECR’s built-in scanning check container images against known vulnerability databases.

When you integrate these scans into your CI/CD pipeline before images are pushed to your registry, vulnerable images get flagged before they ever reach production.

What a complete control looks like

A complete control requires more than just turning a scanner on. For SOC 2, you must demonstrate three realities:

1. You are actively scanning
2. You have a defined remediation process with timelines
3. You are actually remediating findings within those timelines

Pipeline scanning plus a documented remediation SLA plus evidence of remediation equals a comprehensive control.

What auditors see in immature environments

The most common pitfalls are operational, not technical. Auditors frequently see scanning enabled with nobody reviewing the findings, base images that are years out of date because updating them is inconvenient, or a complete lack of documentation for the vulnerability management process.

Access Control in Kubernetes

SOC 2 CC6.1 governs logical access controls.

Kubernetes handles this through a sophisticated Role-Based Access Control (RBAC) system. Configured well, it provides surgical precision. Configured poorly, it creates massive, invisible access gaps.

The most common RBAC finding

The most frequent RBAC finding is overly permissive `cluster-admin` or cluster-level role bindings that give users or service accounts far more access than they need.

Developers should not hold cluster-admin rights in production, and service accounts must be restricted to the absolute minimum permissions their specific workload requires.

What auditors will check

Auditors will examine your RBAC configuration looking for:

• Least privilege in role definitions
• Separation of privileges between development and production
• Documented access review processes
• How cluster access is provisioned and deprovisioned as team members join and leave

Network policies: segmentation for containers

Network policies are the container-layer equivalent of network segmentation.

Here is something many teams do not realize: by default, Kubernetes allows every pod to talk to every other pod. Network policies restrict that traffic to intended communication patterns. Documenting this configuration satisfies the kubernetes network policies compliance requirements for SOC 2 logical access controls.

Logging and Monitoring

SOC 2 CC7.2 requires comprehensive monitoring of your environment.

Kubernetes generates logs at multiple levels, control plane, node, and container application, and each tells a different operational story.

The API audit log: your security record

The control plane audit log is your definitive security record.

The Kubernetes API audit log captures every single API call: who made it, what they did, to which resource, and when. It is the immutable ledger that SOC 2 change management and logical access controls rely upon. If someone changed a deployment in your production cluster, the API audit log captures it.

Achieving kubernetes audit log compliance requires three steps:

1. Enable API audit logging.
2. Ship it to your centralized log management system.
3. Retain it according to your log retention policy.

Don’t lose your container logs

Container application logs must also be captured and centralized. Because container filesystems are ephemeral, logs stored locally vanish the moment a pod restarts.

Running logging agents, such as Fluentd, Fluent Bit, or the Datadog Agent,as DaemonSets ensures these logs are captured and shipped to centralized storage. This is a non-negotiable prerequisite for any meaningful monitoring or incident investigation.

Change Management for Container Deployments

SOC 2 CC8.1 dictates change management.

In Kubernetes, changes to production workloads happen through image deployments. A new container image version is, by definition, a production change.

The GitOps advantage

Mature Kubernetes environments manage production deployments through GitOps pipelines like ArgoCD or Flux:

• Configuration is defined in git.
• Production deployment happens only when code is merged to the deployment repository through an approved pull request.
• The pipeline handles the deployment. No engineer manually applies Kubernetes manifests to production.

Change management, built in

This architecture creates a flawless, built-in change management control.

Every production change requires a git commit, which requires a pull request, which requires a review approval. The audit trail lives natively in version control.

The red flag: kubectl in production

The red flag for auditors is the use of manual `kubectl` commands in production. This creates a severe change management gap, making it nearly impossible to reconstruct what changed, when, and who authorized it.

The solution is not to write better documentation after the fact. The solution is to route all deployments through version-controlled pipelines.

Secrets Management

Here is an uncomfortable truth for teams new to the ecosystem: Kubernetes Secrets, in their default form, are merely base64-encoded. They are not encrypted, and they are stored in etcd.

If etcd is not encrypted at rest, your secrets are effectively sitting in plaintext. Many organizations do not realize this when they start storing API keys, database credentials, and certificates in Kubernetes Secrets.

What proper secrets management looks like

For SOC 2, secrets management falls under encryption and access control requirements. Doing it right means:

• etcd encryption at rest enabled
• RBAC restricting secret access strictly to the pods and personnel who need it
• Integration with an external secrets manager (such as AWS Secrets Manager or HashiCorp Vault) for centralized rotation

Document your secrets management approach. Auditors will ask about it.

Translation, Not Friction

Kubernetes and SOC 2 are not fundamentally incompatible; they simply require translation. Kubernetes compliance requirements make perfect sense once mapped to the framework’s underlying intent.

At Regodit, our engineering-led compliance methodology covers container environments natively, with specific control mappings for SOC 2 and ISO 27001. We built it because treating modern infrastructure like a black box doesn’t create security. It just creates a well-written lie.

If you want compliance that actually understands how your clusters work, explore Regodit and schedule a demo with the team.