Proactive EKS Security: Detecting Threats with Honeytokens

Amazon EKS, a managed Kubernetes service, simplifies containerized application deployment, but it introduces unique security risks due to its deep AWS integration. Misconfigured resources like overly permissive roles, exposed ConfigMaps, or insecure service accounts can leak sensitive data and enable lateral movement. EKS clusters are high-value targets, often running production workloads with access to powerful IAM roles via IRSA. If compromised, attackers can pivot into broader AWS services like S3 or RDS, making EKS not just an entry point, but a critical target for exploitation.

For example, In August 2024, Eager Enigma Enterprises suffered a security breach where a production EKS cluster was breached through a command injection flaw in a public web app. The attacker gained container access, extracted AWS credentials from a misconfigured secret, and launched high-cost EC2 instances for crypto mining, leading to a full workload compromise. [1]

These attacks need to be actively monitored within the EKS environment. Common strategies include Kubernetes audit logs, which provide detailed visibility into API activity like get, list, or patch operations, though they require external tools that are not enabled by default. RBAC hardening and Pod Security Policies enforce the least privilege but are preventive in nature and can be complex to configure. Runtime threat detection tools such as Falco, GuardDuty, and Sysdig offer real-time insights into system behavior, but they can be noisy and resource-intensive. [2]

In contrast, honeytokens provide a lightweight and active detection layer. These are intentionally crafted fake AWS resources that are designed to trigger alerts upon interaction. Since legitimate workloads should never touch them, any access is a high-confidence indicator of compromise. Honeytokens integrate seamlessly into the AWS environment, turning the attacker’s reconnaissance and lateral movement into your early warning system, enabling faster detection before critical resources are compromised. The deceptions are made attractive for the attackers to perform exploitation.

AWS recommends the use of honeytokens as they behave like real resources but hold no real data or functionality. These honey tokens are completely isolated from production systems, ensuring that any interaction with them reveals malicious intent without risking real assets. They are cost effectiv,e and they can be monitored with AWS native loggers. [3]

These Honeytokens are instrumented to detect unauthorized access in real-time by monitoring for any interaction, such as reading or modifying them, without exposing actual resources. When a honeytoken is triggered, it serves as a high-confidence indicator of compromise, allowing immediate action to contain the threat and prevent further lateral movement within the environment.

While traditional EKS security measures like RBAC, audit logging, and runtime threat detection are essential, they often react after damage has begun. The honeytokens will shift this paradigm by offering an active, high-fidelity detection layer that triggers alerts the moment an attacker engages in reconnaissance. By strategically placing these honeytokens in the EKS environment, we can turn the passive infrastructure into an active defense system.

To learn more about this active defense for AWS EKS security, please read our white paper.