« AWS EFS File System Deleted AWS EKS Access Entry Granted Cluster Admin Policy »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

AWS EKS Access Entry Created Then Deleted by Same Identity

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS EKS Access Entry Created Then Deleted by Same Identity

edit

Detects the creation of an Amazon EKS access entry followed by its deletion by the same identity within a short time window. EKS access entries define Kubernetes RBAC-level permissions for IAM principals in an EKS cluster. An adversary with EKS administrative access may temporarily grant themselves cluster access, use those permissions to create Kubernetes RBAC resources (ClusterRoleBindings, ServiceAccounts with privileged roles), and then delete the access entry to hide the evidence of the initial grant while retaining access through the Kubernetes-level backdoor.

Rule type: eql

Rule indices:

  • logs-aws.cloudtrail-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-15m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Kubernetes
  • Platform: AWS
  • Platform: Kubernetes
  • Data Source: AWS CloudTrail
  • Service: AWS EKS
  • Rule Type: Event Correlation (EQL)
  • Tactic: Persistence
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating AWS EKS Access Entry Created Then Deleted by Same Identity

EKS access entries (introduced in EKS API mode) map IAM principals to Kubernetes access policies or allow associating Kubernetes groups to IAM principals. An adversary who obtains eks:CreateAccessEntry and eks:DeleteAccessEntry permissions can:

  1. Create an access entry for their own IAM principal with cluster-admin level access.
  2. Use that access to create persistent Kubernetes RBAC resources (ClusterRoleBindings, privileged ServiceAccounts, rogue DaemonSets).
  3. Delete the access entry, removing the CloudTrail evidence of the initial grant while retaining Kubernetes-level access.

This sequence is analogous to adding a backdoor user, using it, then deleting it to cover tracks. The deletion within a short window of creation is the key behavioral indicator.

Possible investigation steps

  • Identify the calling identity from aws.cloudtrail.user_identity.arn and the targeted cluster from aws.cloudtrail.request_parameters.
  • Review Kubernetes audit logs for the affected cluster in the time window between the CreateAccessEntry and DeleteAccessEntry events. Look for create verbs on ClusterRoleBindings, RoleBindings, ServiceAccounts, or DaemonSets.
  • Check the cluster’s current RBAC configuration for persistent backdoor resources.
  • Determine whether the identity had a legitimate reason to create an access entry for the targeted cluster.

False positive analysis

  • Infrastructure-as-code and CI/CD pipelines that create and tear down EKS access entries as part of cluster validation — Terraform or eksctl apply/destroy cycles, ephemeral test clusters — will produce this exact sequence. Correlate with the pipeline identity and change records before triaging further.
  • Short-lived break-glass or just-in-time administrative access that is granted and revoked by the same operator within minutes is legitimate; confirm against access-request tickets or change approvals.
  • Migration tooling that switches clusters between authentication modes may churn access entries in bulk under a single automation role.
  • The sequence correlates on the calling identity only, so confirm the CreateAccessEntry and DeleteAccessEntry events reference the same cluster and principal ARN in the request parameters before treating them as one grant-and-revoke cycle.
  • Scope any exceptions by the calling ARN or automation role rather than excluding the behavior globally.

Response and remediation

  • Audit all Kubernetes RBAC resources for unauthorized ClusterRoleBindings or privileged ServiceAccounts created in the suspect window.
  • Rotate credentials for the calling identity.
  • Apply IAM policies restricting eks:CreateAccessEntry and eks:DeleteAccessEntry to designated EKS administrative roles.

Setup

edit

The AWS integration must be ingesting management events into logs-aws.cloudtrail-*. EKS management events are logged by default.

Rule query

edit
sequence by aws.cloudtrail.user_identity.arn with maxspan=5m
  [any where data_stream.dataset == "aws.cloudtrail" and event.provider == "eks.amazonaws.com" and event.action == "CreateAccessEntry" and event.outcome == "success" and aws.cloudtrail.user_identity.arn != null]
  [any where data_stream.dataset == "aws.cloudtrail" and event.provider == "eks.amazonaws.com" and event.action == "DeleteAccessEntry" and event.outcome == "success" and aws.cloudtrail.user_identity.arn != null]

Framework: MITRE ATT&CKTM

« AWS EFS File System Deleted AWS EKS Access Entry Granted Cluster Admin Policy »