EKS SOC 2 Readiness: What Auditors Actually Check
SOC 2 auditors increasingly ask about Kubernetes controls, and most engineering teams find out the hard way - usually a few weeks ahead of the audit kickoff, when a compliance lead forwards a request-for-information document full of expressions like "least privilege", "change management evidence," and "real-time monitoring." If your production workloads run on Amazon EKS, EKS SOC 2 readiness is not optional groundwork you can skip. It's the difference between a smooth audit and a scramble that eats a month of your platform team's time.
The panic is predictable. Teams that have spent years hardening EC2 instances and VPC boundaries suddenly realize their auditor doesn't fully understand Kubernetes, and their own engineers haven't translated cluster-level controls into language an auditor recognizes. The good news: this is a solvable, well-scoped problem once you know what auditors are actually looking for. This guide walks through why EKS complicates the audit, how SOC 2 trust service criteria map to concrete EKS controls, the eight tactics that get you audit-ready, and the mistakes that turn a routine review into a finding.
Why EKS Complicates SOC 2 Audits
Kubernetes doesn't fit neatly into the mental model most SOC 2 auditors built around traditional infrastructure, and that mismatch is where most of the friction comes from.
Shared responsibility gets murkier. AWS manages the EKS control plane - etcd, the API server, and the scheduler - but you remain responsible for worker node hardening, RBAC configuration, network policy, and everything running inside your pods. Auditors who understand the AWS shared responsibility model for EC2 or RDS often need it re-explained for EKS because the line between "AWS's job" and "your job" is drawn differently. If you can't articulate that boundary clearly, expect follow-up questions on every control.
Ephemeral workloads break assumptions. Traditional access reviews assume servers that persist for months. In EKS, pods can live for minutes, nodes get replaced by Karpenter or Cluster Autoscaler without warning, and the "system" an auditor is reviewing today may not exist tomorrow. Evidence collection has to account for that churn - a screenshot of a running pod is worthless six weeks later.
RBAC and IAM overlap in ways that confuse reviewers. Kubernetes RBAC controls what a user or service account can do inside the cluster. AWS IAM controls what can authenticate to the cluster and what AWS resources a workload can touch outside it. Getting audit-ready requires you to explain both layers and show they're consistent - a common failure point is IAM roles with broad permissions mapped to Kubernetes groups that appear locked down, which looks like a contradiction to an auditor who doesn't know to check both.
SOC 2 Trust Service Criteria Mapped to EKS Controls
Auditors evaluate you against the AICPA trust service criteria, not directly against Kubernetes concepts. Part of getting audit-ready is doing the translation work yourself, before the auditor asks for it.
|
Access Control (CC6)
|
Least-privilege access, MFA, timely deprovisioning |
IAM Roles for Service Accounts (IRSA), Kubernetes RBAC with namespaced roles, aws-auth ConfigMap or EKS access entries reviewed quarterly, SSO via IAM Identity Center
|
|
Change Management (CC8)
|
Controlled, reviewed, auditable changes to production | GitOps deployments (ArgoCD/Flux) with required PR approvals, Terraform/CDK for cluster and node group changes, signed commits, immutable container image tags |
|
Logging & Monitoring (CC7)
|
Detection of unauthorized activity, alerting, retention | EKS control plane logging (API, audit, authenticator) to CloudWatch, CloudTrail for management-plane API calls, centralized log aggregation with defined retention, GuardDuty EKS Protection |
|
Availability (A1)
|
Resilience, backup, capacity planning | Multi-AZ node groups, pod disruption budgets, cluster autoscaling, tested backup/restore for persistent volumes and etcd-backed state, documented RTO/RPO |
|
Confidentiality (C1)
|
Encryption, secrets handling, data segmentation | Secrets encrypted with AWS KMS envelope encryption for EKS, no plaintext secrets in manifests, network policies enforcing namespace segmentation, encryption in transit via TLS/mTLS |
This table is also the fastest way to brief an auditor who hasn't reviewed an EKS environment before - hand it over early, and you'll spend less time re-explaining Kubernetes concepts during fieldwork.
EKS SOC 2 Readiness Steps
These eight tactics address the gaps that most often appear in Kubernetes compliance reviews, roughly in the order we tackle them with clients.
1. Turn on full audit logging via CloudTrail and EKS control plane logs
Enable all five EKS control plane log types (API server, audit, authenticator, controller manager, scheduler) and ship them to CloudWatch or a SIEM with a retention period that fits your SOC 2 window - typically 12 months. Pair this with CloudTrail for the AWS-side API calls (cluster creation, IAM changes, node group updates). Without both layers, you can't prove who did what at the cluster or AWS account level.
2. Enforce least-privilege RBAC and IRSA
Audit every ClusterRoleBinding and remove wildcard permissions. Move workloads off shared node IAM roles and onto IAM Roles for Service Accounts (IRSA) or EKS Pod Identity so each workload gets only the AWS permissions it needs. This is the single highest-impact change for EKS SOC 2 readiness, since access control is almost always the first section an auditor tests.
3. Centralize secrets management
Stop storing secrets as plaintext Kubernetes Secret objects checked into manifests. Use AWS Secrets Manager or Parameter Store with the Secrets Store CSI Driver, or encrypt etcd secrets at rest with KMS envelope encryption. Auditors will ask for a walkthrough of how a secret gets from storage to a running pod - have a clean answer ready.
4. Implement network segmentation
Deploy Kubernetes NetworkPolicies (via Calico, Cilium, or the VPC CNI's native policy support) to restrict pod-to-pod traffic by namespace and label. Combine with security groups for pods and private EKS API endpoints where possible. This directly supports the confidentiality criteria and limits blast radius if a single service is compromised.
5. Add image scanning and supply chain attestation
Scan container images for vulnerabilities before deployment using Amazon ECR image scanning, Trivy, or Grype, and block deployment on critical findings. For stronger evidence, add image signing (Cosign) and SBOM generation so you can show provenance for every image running in production - this increasingly comes up as a change management control, not just a security nice-to-have.
6. Formalize change management through GitOps
Route all cluster and workload changes through pull requests with required reviewers, whether that's Terraform for infrastructure or ArgoCD/Flux for application manifests. The Git history itself becomes your change management evidence - commit author, reviewer, timestamp, and diff, all in one place an auditor can sample directly.
7. Write and test an incident response runbook for EKS
Auditors want to see a documented, Kubernetes-specific incident response plan that covers how you detect a compromised pod, isolate it (via network policies or node cordon/drain), preserve forensic evidence, and rotate credentials. A generic "AWS incident response" doc without EKS specifics is a common gap we find during readiness reviews.
8. Automate evidence collection
Manual screenshots don't scale against ephemeral Kubernetes resources. Employ tools such as AWS Config, Steampipe, or scheduled scripts to snapshot RBAC bindings, IRSA mappings, and NetworkPolicy configurations on a recurring basis and store the timestamped output in S3. This turns audit readiness from a pre-audit fire drill into a continuous, low-effort process.
Common Mistakes to Avoid
- Treating the EKS control plane as fully AWS's responsibility. AWS secures the control plane infrastructure, but RBAC, network policies, and workload security are your responsibility. Auditors will test this boundary directly.
- Leaving system:masters or cluster-admin bindings unused but present. Unused broad-access bindings are one of the most common findings - remove them even if nobody currently uses them.
- No mapping between IAM and Kubernetes RBAC. If you can't show how an IAM identity translates to in-cluster permissions, auditors will flag it as an access control gap.
- Point-in-time evidence for a moving target. A single screenshot of kubectl get rolebindings doesn't hold up when nodes and pods churn daily. Evidence needs to be continuous or clearly scoped to a sampling period.
- Skipping node-level hardening because "it's just Kubernetes." Unpatched AMIs, missing CIS Benchmark controls, and open SSH access on worker nodes remain in scope for SOC 2, even though the workloads run in containers.
FAQ
Does SOC 2 require a specific Kubernetes version? No. SOC 2 doesn't mandate a Kubernetes or EKS version, but auditors expect you to run a supported version and have a documented patching cadence. Running an EKS version past its extended support window without justification is common, as it signals an unmanaged patch management process rather than a specific version violation.
Can EKS pass SOC 2 without a dedicated platform team? Yes, but it takes a more deliberate process. Without a dedicated platform team, audit readiness depends on codifying controls - GitOps for changes, IRSA for access, automated evidence collection - so the controls don't rely on any one person's memory or manual effort. Smaller teams that skip this step tend to fail on consistency, not on any single missing control.
How long does EKS SOC 2 readiness typically take? For a team starting from scratch, expect 6-10 weeks to close the major gaps (RBAC cleanup, logging, secrets management) before a Type I audit, and a full observation period (usually 3-6 months) of continuous evidence collection before a Type II audit. Teams with existing GitOps and centralized logging can move faster.
Do we need a separate EKS cluster for SOC 2-scoped workloads? Not necessarily. Namespace-level isolation with NetworkPolicies, RBAC, and resource quotas can satisfy scoping requirements for many audits, though some auditors and some data sensitivity levels do warrant a dedicated cluster. This is worth confirming with your auditor early rather than assuming either way.
Tags:
Need help with this?
I offer hands-on consulting on exactly this — kubernetes & aws eks consulting .