EKS honeytokens expose the gap in Kubernetes threat detection

At a glance

What this is: This is a blog analysis of EKS honeytokens as an active detection method for Kubernetes environments, with the key finding that decoy AWS resources can surface reconnaissance and lateral movement with high confidence.

Why it matters: It matters because IAM, NHI, and cloud security teams need earlier compromise signals inside EKS, where misconfigured service accounts and AWS roles can turn a cluster into a launch point for broader access.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Acalvio's analysis of proactive EKS security with honeytokens

Context

EKS security depends on how Kubernetes identities, AWS roles, and secrets are stitched together at runtime. When service accounts, ConfigMaps, or IRSA-linked roles are too permissive, a single foothold can turn into AWS-wide access rather than a contained container issue.

The problem is not just prevention. Kubernetes audit logs, RBAC hardening, and runtime monitoring all help, but they often detect activity after an attacker has already touched sensitive resources. Honeytokens change that by creating decoys that should never be accessed by legitimate workloads, which gives defenders a clearer compromise signal.

For teams managing machine identities, this is a reminder that visibility and privilege boundaries have to extend beyond the cluster itself. The same governance discipline that applies to service accounts and secrets also shapes how quickly a compromised workload can move into S3, RDS, or other AWS services.

Key questions

Q: How should security teams use honeytokens in EKS environments?

A: Use honeytokens as a high-confidence tripwire for compromise, not as a replacement for RBAC or runtime security. Place decoy credentials and resources where compromised pods are likely to search, then correlate any trigger with Kubernetes audit logs, pod identity, and AWS role mappings to speed containment.

Q: Why do EKS workloads create broader cloud risk than a normal container compromise?

A: EKS workloads often inherit AWS permissions through service accounts, IRSA, and shared secrets, so a single pod can become a path into S3, RDS, or other services. That makes the identity boundary wider than the cluster boundary and increases the impact of one exposed credential.

Q: What breaks when EKS secrets are exposed to workloads that do not need them?

A: The control assumption breaks at the point where any compromised pod can read credentials that should have been isolated. Once that happens, reconnaissance becomes credential theft, and credential theft becomes lateral movement into broader AWS resources.

Q: How do organisations reduce the blast radius of a compromised EKS pod?

A: Remove unnecessary service account permissions, narrow IRSA role scope, and separate high-value secrets from routine workloads. Then add detection that can spot unusual access quickly, because the fastest containment is the one that limits what the pod can reach in the first place.

Technical breakdown

How EKS identity sprawl creates attack paths

Amazon EKS inherits identity from both Kubernetes and AWS, which means the attack surface includes service accounts, IAM roles for service accounts, Secrets, ConfigMaps, and node-level permissions. If a workload can read an over-permissive secret or assume a broad AWS role through IRSA, container compromise becomes cloud compromise. The issue is not Kubernetes alone, but the coupling of cluster credentials to broader AWS privileges. In practice, the cluster becomes a credential distribution layer unless those permissions are tightly scoped and monitored.

Practical implication: audit EKS service accounts and IRSA mappings for standing privilege that lets a container pivot outside the cluster.

Why honeytokens work as a detection control

Honeytokens are deliberately fake AWS resources placed where an attacker is likely to look for useful credentials or configuration. Because legitimate workloads have no reason to access them, any interaction is a high-confidence indicator of compromise. This makes honeytokens different from noisy behavioural analytics: they are not trying to infer intent from patterns, they are waiting for an unauthorized touchpoint. In EKS, that can reveal reconnaissance, credential harvesting, or early lateral movement before production systems are reached.

Practical implication: place decoy credentials and resources in paths that compromised pods are likely to enumerate first.

How runtime detection complements RBAC and audit logging

RBAC and audit logs are necessary, but they are fundamentally control and evidence layers, not always early detection layers. RBAC reduces what a pod can do, audit logs record what happened, and runtime tools watch for suspicious behaviour once execution is underway. Honeytokens add a trap-based signal that can fire earlier than post-compromise log review. In a clustered AWS environment, that matters because a brief window between initial access and lateral movement can be enough to spin up resources, exfiltrate data, or expand permissions.

Practical implication: treat honeytokens as a tripwire alongside RBAC and logging, not as a replacement for either.

Threat narrative

Attacker objective: The attacker wants usable cloud credentials and a trusted foothold that can be monetised through resource abuse, lateral movement, or broader AWS compromise.

1. Entry begins when a public web application or exposed workload flaw gives the attacker a foothold inside the EKS environment.
2. Credential access follows when the attacker extracts AWS credentials from a misconfigured secret or similarly exposed identity object.
3. Impact occurs when the stolen access is used to create high-cost instances, pivot into broader AWS services, or compromise the workload estate.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

EKS security fails when workload identity is treated as a cluster-only problem. EKS joins Kubernetes execution to AWS identity, so a pod compromise is often also an IAM problem. The governance mistake is assuming the container boundary is the security boundary. In practice, IRSA, secrets, and ConfigMap exposure can make a single workload the shortest path into wider cloud access.

Honeytokens create a high-confidence control point because they exploit a governance assumption, not just attacker behaviour. Legitimate workloads are not supposed to touch decoy credentials or fake AWS resources. That makes the first interaction more useful than a heuristic alert because it indicates unauthorized discovery or misuse. For practitioners, the value is not deception theater but a cleaner compromise signal inside noisy Kubernetes estates.

Standing access inside EKS turns reconnaissance into lateral movement very quickly. When a pod can read secrets or assume broad AWS privileges, there is little separation between discovery and impact. This is exactly why NHI governance has to include service account scope, secret exposure, and cloud role mapping in the same review loop. The practical conclusion is that access paths, not only clusters, need governance.

Identity blast radius is the right concept for EKS because one exposed credential can span multiple control planes. A container issue can become an AWS issue, then a data and cost issue, in a single chain. That pattern aligns with OWASP-NHI and NIST-CSF thinking about least privilege, visibility, and rapid detection. Practitioners should measure how far one compromised pod can move before a human notices.

Decoy-based detection is strongest when paired with lifecycle discipline for NHI secrets. Honeytokens can tell you that reconnaissance happened, but they do not fix why a secret was reachable in the first place. The broader governance lesson is that secrets visibility, rotation, and offboarding still define the blast radius. Teams that ignore lifecycle controls will keep relying on detection to cover preventable exposure.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For lifecycle remediation context, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that reduce exposed-secret dwell time.

What this signals

Identity blast radius will matter more than perimeter visibility in EKS programmes. When a workload can read cloud credentials, the key question is no longer whether the cluster is monitored but how far the compromise can travel before the first trigger. Teams should design detection around reachability, not just logging volume, and use honeytokens to expose the shortest path to privileged cloud resources.

Decoy-based detection needs lifecycle support to stay credible. Honeytokens can identify unauthorized access, but the surrounding programme still has to remove stale secrets, narrow service account permissions, and offboard access that no longer maps to a real workload need. The operational signal is whether a triggered decoy can be followed by quick isolation, not whether the alert was loud.

For teams aligning with Top 10 NHI Issues, the important shift is from static policy to runtime proof. A control that only exists on paper will not help when a containerized identity is abused in minutes. What matters is whether the environment can prove access boundaries continuously, especially where NIST Cybersecurity Framework 2.0 detective and respond functions have to work together.

For practitioners

• Map EKS identity pathways end to end Inventory which service accounts, ConfigMaps, Secrets, and IRSA roles can be reached from each workload. Focus on the paths that let a compromised pod assume broader AWS permissions or read credentials intended for other services.
• Seed decoy resources where attackers enumerate first Place honeytokens in locations that a compromised pod would naturally inspect, such as fake AWS keys, mock S3 targets, or decoy configuration objects. The goal is to create a tripwire before the attacker reaches real production resources.
• Correlate honeytoken triggers with Kubernetes audit data Use audit logs to determine which pod, service account, or namespace touched the decoy and what preceded it. That gives faster containment context than a raw alert and helps distinguish reconnaissance from accidental access.
• Reduce standing privilege in cloud-linked workloads Review whether any EKS workload can access secrets or AWS roles that are broader than its runtime task requires. Tighten those bindings first, because honeytokens detect compromise but do not reduce the attacker's usable blast radius.

Key takeaways

• EKS creates a cloud identity problem as much as a container security problem, because a compromised pod can inherit meaningful AWS reach.
• Honeytokens improve detection quality by turning unauthorized access into a high-confidence signal, but they do not reduce the original exposure.
• The practical control lesson is to narrow service account scope, separate secrets, and use decoys as early warning, not as the primary defence.

Key terms

• Honeytoken: A honeytoken is a deliberately fake credential, resource, or data object placed to detect unauthorized access. In cloud and Kubernetes environments, any interaction with it is a strong indicator of compromise because legitimate workloads should never need to read or use it.
• IRSA: IAM Roles for Service Accounts is the AWS pattern that lets Kubernetes pods assume AWS permissions through their service account identity. It reduces the need for shared node credentials, but it also means workload identity scope must be tightly controlled to avoid broad cloud access.
• Identity blast radius: Identity blast radius is the amount of access, systems, and data a compromised identity can reach before containment. In EKS, it spans the cluster, AWS roles, and downstream services, so minimizing it requires careful scoping of service accounts, secrets, and cloud permissions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Acalvio: Proactive EKS Security: Detecting Threats with Honeytokens. Read the original.