Security researchers just confirmed what many cloud engineers suspected: Kubernetes clusters running in production environments are actively exposing sensitive credentials, API keys, and internal service data right now. The question isn’t whether your infrastructure is vulnerable — it’s whether you’ve already been hit.
Here’s the direct answer: A misconfiguration flaw in Kubernetes’ default RBAC (Role-Based Access Control) settings allows unauthenticated or low-privilege users to query the API server and extract secrets stored as environment variables or mounted volumes. Combined with Docker image layer exposure, the attack surface is wider than most AWS-hosted organizations realize.
What’s Actually Happening Inside These Clusters
Wiz Research published findings in 2024 showing that over 60% of publicly scanned Kubernetes API endpoints had at least one misconfigured RBAC policy. That’s not a theoretical risk number — those are live clusters, some serving Fortune 500 workloads.
The core problem sits in how Kubernetes handles service account tokens. By default, every pod gets auto-mounted with a service account token, even when it doesn’t need one. Attackers who compromise a single container can use that token to query the Kubernetes API and escalate privileges laterally across namespaces.
Docker compounds this problem significantly. When engineers build images without scrubbing intermediate layers, secrets baked in during build time remain retrievable via docker history commands — even after the final image appears clean on the surface.
The Attack Chain: Step by Step
Step 1 — Entry Through an Exposed Workload
Attackers typically enter through a vulnerable web application running inside a pod. CVE-2023-44487 (HTTP/2 Rapid Reset) and similar application-layer vulnerabilities give initial container access without requiring Kubernetes-specific knowledge.
Once inside a container, the attacker reads /var/run/secrets/kubernetes.io/serviceaccount/token — a file present in virtually every default Kubernetes deployment. This isn’t exploitation in the traditional sense; it’s reading a file that’s simply sitting there.
Step 2 — API Server Enumeration
With that token, the attacker queries the internal Kubernetes API at https://kubernetes.default.svc. Misconfigured RBAC policies frequently grant get, list, and watch permissions on secrets cluster-wide — permissions that were never meant to exist but were copy-pasted from Stack Overflow tutorials into production configs.
Researchers at Aqua Security documented real attack campaigns in 2023 where automated bots specifically hunted for these token files within minutes of initial container compromise. The automation is sophisticated and fast.
Step 3 — AWS Credential Extraction
Many AWS-hosted Kubernetes workloads use IRSA (IAM Roles for Service Accounts) or store AWS credentials as Kubernetes Secrets. Once an attacker has API access, pulling those credentials takes a single kubectl get secrets -o json command — base64-encoded values that decode instantly.
From there, the blast radius expands beyond the cluster entirely. AWS console access, S3 bucket exfiltration, RDS connection strings — the original Kubernetes misconfiguration becomes a full cloud account compromise within hours, sometimes minutes.
Why AWS Configurations Make This Worse
AWS EKS clusters inherit a specific trust problem: IAM entity mappings live inside the aws-auth ConfigMap, and overly permissive entries there can grant cluster admin rights to entire AWS account roles. Security firm Datadog reported in 2023 that 1 in 5 EKS clusters they analyzed had critically misconfigured aws-auth entries.
IMDS (Instance Metadata Service) access from within pods is another understated risk. Pods that can reach 169.254.169.254 can query the EC2 instance metadata endpoint and retrieve temporary IAM credentials for the underlying node role — unless IMDSv2 with hop limits is explicitly enforced.
Most teams don’t enforce it. AWS doesn’t enforce it by default either, though they strongly recommend it. The gap between recommendation and default configuration is where real breaches live.
The Docker Layer Problem Nobody Talks About Enough
Docker image security gets discussed in terms of base image vulnerabilities, but the layer history problem is arguably more immediately dangerous. Engineers routinely run commands like RUN export API_KEY=xyz123 during build stages and assume ENV variables disappear in production images.
They don’t. Tools like docker history –no-trunc and dive expose every layer command, including deleted files and environment variables set during build. Public registries on Docker Hub contain thousands of images with AWS keys, GitHub tokens, and database passwords sitting in plain layer history.
TruffleHog and GitGuardian both maintain continuous scans of public registries and consistently find active credentials — not just old ones — embedded in recently pushed images.
How to Actually Fix This
The remediation path is clear, but it requires deliberate action rather than assumptions. Start with these concrete controls:
- Disable auto-mounting of service account tokens by setting automountServiceAccountToken: false in pod specs that don’t require API access.
- Audit RBAC bindings immediately using tools like rbac-audit or kubectl-who-can to identify any wildcard permissions or cluster-admin bindings attached to default service accounts.
- Enforce IMDSv2 with hop count 1 on all EKS node groups to prevent pods from querying instance metadata.
- Scan Docker images for secrets in CI/CD pipelines using TruffleHog or Trivy before images reach any registry.
- Enable Kubernetes Audit Logging and ship logs to a SIEM — unusual API calls from service account tokens are detectable if you’re actually watching.
FAQ
Does using a managed Kubernetes service like EKS automatically protect against these flaws?
No. EKS manages the control plane but RBAC configuration, pod security settings, and Docker image hygiene remain entirely the customer’s responsibility. Managed services reduce operational overhead, not security responsibility.
How quickly can attackers move from initial container compromise to full cluster access?
Aqua Security’s honeypot research showed automated attackers completing container-to-cluster escalation in under 60 seconds when default service account tokens were present and RBAC was misconfigured. Speed is the defining characteristic of modern cloud attacks.
Are Kubernetes Secrets actually encrypted at rest on AWS EKS?
Not by default. Encryption at rest for Kubernetes Secrets on EKS requires explicitly enabling envelope encryption using AWS KMS — a step that AWS documents but does not enable automatically during cluster creation.
The One Thing You Should Do Today
Run kubectl get rolebindings,clusterrolebindings -A -o json right now and pipe the output through kubectl-who-can or review it manually for any service account holding cluster-admin or wildcard secret permissions. That single audit command has caught critical misconfigurations in organizations that were otherwise certain their clusters were locked down — because assumption is not a security control.