AWS EKS Security for SOC 2: Endpoint Access, Audit Logs, and Kubernetes Versions
The specific EKS security controls SOC 2 auditors look for, how to implement them, and how SecureSpect automates EKS evidence collection for CC6.6 and CC7.1.
Why EKS Is a SOC 2 Focus Area
Amazon EKS (Elastic Kubernetes Service) is increasingly common in startup stacks, but it introduces specific SOC 2 risks that simpler compute architectures don't have. The Kubernetes API server can be publicly exposed. Audit logging may not be enabled by default. Cluster versions go unsupported faster than teams expect. Secrets can leak through environment variables.
If you're running EKS, auditors will ask about it. Here's what they're looking for and how to satisfy it.
The Two Core EKS SOC 2 Controls
CC6.6 — Boundary Protection: Requires that logical access points are monitored and protected against unauthorized access. For EKS, this means the Kubernetes API server endpoint should not be publicly unrestricted.
CC7.1 — Monitoring: Requires continuous monitoring of system components. For EKS, this means Kubernetes audit logging must be enabled so you have a record of who did what to your cluster.
SecureSpect checks both:
aws.eks.endpoint_access — CC6.6
Checks that the EKS cluster API server endpoint is not publicly unrestricted.
A PUBLIC endpoint with no IP whitelist is a finding.
aws.eks.audit_logging — CC7.1
Verifies that the api and audit log types are enabled for the cluster.
EKS API Endpoint Configuration for SOC 2
EKS clusters have three endpoint access modes:
Public only (default): The API server is accessible from the internet. Anyone with valid credentials and network access can reach the API. This fails CC6.6 unless you have IP-based restriction.
Public with IP restriction: The API server is public but restricted to specific CIDR blocks. Acceptable for CC6.6 if the allowed CIDRs are tightly controlled and documented.
Private only: The API server is only accessible from within your VPC. The most secure configuration; passes CC6.6 without additional controls.
For most startups, the practical path is "Public with IP restriction" — private-only clusters require additional VPN or Direct Connect infrastructure for developer access.
# Check your current cluster endpoint configuration
aws eks describe-cluster --name your-cluster-name --query 'cluster.resourcesVpcConfig.{public:endpointPublicAccess,private:endpointPrivateAccess,cidrs:publicAccessCidrs}'
# Restrict public endpoint to specific CIDRs (your VPN/office IPs)
aws eks update-cluster-config --name your-cluster-name --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true,publicAccessCidrs='["203.0.113.0/32","198.51.100.0/24"]'
Enabling EKS Audit Logging
EKS provides five log types: api, audit, authenticator, controllerManager, and scheduler. For SOC 2, you need at minimum api and audit.
# Enable API and audit logging for an existing cluster
aws eks update-cluster-config --name your-cluster-name --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
Logs are sent to CloudWatch Logs under /aws/eks/your-cluster-name/cluster. Set a retention policy — keeping EKS logs for 12 months covers a full Type II audit period.
Kubernetes Version Currency for SOC 2
Auditors increasingly ask about Kubernetes version currency under CC7.1 (monitoring and response to vulnerabilities). EKS supports a minor version for approximately 14 months after release. Running an end-of-life version is a finding because it means you're running unpatched Kubernetes.
Check your current version:
aws eks describe-cluster --name your-cluster-name --query 'cluster.version'
As of mid-2026, EKS supports 1.28 through 1.32. If you're on 1.27 or earlier, schedule an upgrade.
EKS Secrets Management
A common EKS audit finding is plaintext secrets in environment variables. The SOC 2 requirement (CC6.1) is that secrets should not be hardcoded or passed in plaintext.
The correct pattern for EKS:
SecureSpect checks ECS for plaintext environment variables — the same principle applies to EKS. Review your deployment manifests for env: blocks with credentials.
FAQ
Does EKS need to be private to pass SOC 2? No. Public endpoint with IP restriction is acceptable. What fails is public access with no CIDR restriction (open to 0.0.0.0/0).
Are Kubernetes-level RBAC policies checked? Not by SecureSpect directly, but auditors may ask about your Kubernetes RBAC configuration as part of CC6.1. Document your cluster roles and role bindings.
What if my EKS version is end-of-life? Plan and execute an upgrade. It's a CC7.1 finding if you have unpatched software running in production.
