What happens when an attacker gains admin access in EKS and starts listing secrets?

Once an attacker can create privileged pods and list secrets, they can move from access to exposure. Secrets may reveal credentials, tokens, or service account material that enables deeper compromise in the cluster and adjacent cloud services. At that point, the incident is no longer just account abuse. It becomes a broader compromise of identity, workload, and data.

Why This Matters for Security Teams

When an attacker gets admin access in EKS, the immediate problem is not just privilege. It is the combination of cluster control, secret visibility, and the ability to turn one foothold into many. In Kubernetes, listing secrets often exposes service account tokens, database credentials, API keys, and cloud access material that was never meant to be broadly reachable. That means a single compromised administrative path can become a path into adjacent services, CI/CD systems, or even the broader cloud environment. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Guide to the Secret Sprawl Challenge both point to the same operational reality: hidden credential sprawl is what makes the blast radius so large. The risk is amplified when teams rely on long-lived secrets instead of workload-bound identities and short-lived tokens. In practice, many security teams only discover how many paths a single admin can unlock after secrets have already been enumerated and reused.

How It Works in Practice

Once admin rights are obtained, the attacker typically pivots in stages. First, they enumerate namespaces, pods, ConfigMaps, and Secrets objects. Next, they inspect mounted credentials, environment variables, and service account material. If the cluster uses broad RBAC, static secrets, or permissive node access, the attacker can often move from one workload to another with little friction. This is why current guidance suggests treating cluster admin as a catastrophic identity event, not just a permissions issue.

• Secret listing can reveal credentials for databases, message queues, object storage, and third-party APIs.
• Service account tokens may let the attacker call the Kubernetes API or assume workload permissions elsewhere.
• Leaked cloud keys can extend compromise beyond EKS into IAM, storage, and serverless services.
• Admission controls and secret encryption help, but they do not help if the attacker already holds broad admin rights.

Practitioners should pair least privilege with workload identity, short token lifetimes, and tight secret scoping. The relevant control objective is to prevent “admin can see everything” from becoming true in the first place. The OWASP NHI Top 10 and NHIMG’s 52 NHI Breaches Analysis both reinforce that exposed identities are usually followed by lateral movement, not isolated misuse. These controls tend to break down in clusters where legacy applications depend on static secrets mounted across many namespaces because secret reuse erases containment.

Common Variations and Edge Cases

Tighter secret controls often increase operational overhead, requiring organisations to balance rapid delivery against reduced exposure. Not every EKS compromise looks the same, and there is no universal standard for this yet. Some environments use external secret stores, sealed secrets, or service mesh identity, which can shrink what “listing secrets” reveals. Others have node-level access, overly broad RBAC, or inherited IAM permissions that make secret enumeration only the first step.

One important edge case is that listing secrets is not always the most damaging action. If the attacker can create privileged pods, mount host paths, or reach the kubelet, they may bypass secret objects entirely and still extract equivalent material. Another is that some secrets are actually short-lived tokens, which reduces dwell time but does not eliminate risk if rotation and revocation are weak. NHIMG research on the The State of Secrets in AppSec shows how secret remediation often lags exposure, so the practical question is not just “can secrets be listed?” but “how quickly can they be rotated, revoked, and traced once exposure is suspected?”

Related resources from NHI Mgmt Group

• What happens when filesystem access is attempted without proper symlink handling in an MCP server?
• What happens when attackers use valid employee credentials to access internal systems?
• What is secrets exposure in NHI security?
• How should teams respond when CI or developer secrets are exposed?