AWS EKS Authentication Configuration Modified

Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects. Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and updated only during node group or access configuration changes.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/08/03"
  3integration = ["aws"]
  4maturity = "production"
  5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
  6min_stack_version = "9.6.0"
  7updated_date = "2026/10/09"
  8
  9[rule]
 10author = ["Elastic"]
 11description = '''
 12Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and
 13users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a
 14mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node
 15replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects.
 16Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and
 17updated only during node group or access configuration changes.
 18'''
 19false_positives = [
 20    '''
 21    Legitimate node group lifecycle, cluster upgrades, or infrastructure-as-code (Terraform, CloudFormation, eksctl) may
 22    update aws-auth during expected change windows. Baseline automation identities and expand exclusions beyond
 23    eks:kms-storage-migrator if your environment uses additional known controllers.
 24''',
 25]
 26from = "now-9m"
 27index = ["logs-aws.eks_audit-*"]
 28language = "kuery"
 29license = "Elastic License v2"
 30name = "AWS EKS Authentication Configuration Modified"
 31note = '''
 32## Triage and analysis
 33
 34### Investigating AWS EKS Authentication Configuration Modified
 35Confirm who changed the mapping (user.name, groups, source.ip, user_agent.original) and whether the change aligns with
 36approved cluster or node-group operations. Compare the new aws-auth mapRoles/mapUsers content to the prior revision if
 37request/response capture is available in audit.
 38
 39### Possible investigation steps
 40
 41- Identify any new IAM role ARNs or users bound to system:masters or other privileged Kubernetes groups.
 42- Correlate the timestamp with AWS CloudTrail for related EKS or IAM API activity and with GitOps or pipeline commits.
 43- Review subsequent API activity from newly mapped IAM principals for secret access, RBAC changes, or workload deployment.
 44- If Access Entries are enabled, also review CloudTrail for eks:CreateAccessEntry, eks:AssociateAccessPolicy, and similar
 45  API calls around the same window.
 46
 47### Response and remediation
 48
 49- If unauthorized, revert aws-auth from a known-good backup, remove rogue map entries, and rotate or restrict IAM that
 50  could have performed the change.
 51- Audit IAM policies that allow eks:UpdateClusterConfig or broad ConfigMap write access to kube-system.
 52- Escalate per incident policy when system:masters mappings appear from unexpected IAM identities.'''
 53references = [
 54    "https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html",
 55    "https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html",
 56]
 57risk_score = 73
 58rule_id = "95a73f83-f6bf-573b-8d8f-114a6d6d56e1"
 59setup = '''
 60This rule reads EKS control-plane audit logs collected by the AWS integration
 61into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 62pipelines normalize each audit record under `aws.eks.audit.*`.
 63
 64Enable the `audit` control-plane log type on the EKS cluster, send its
 65CloudWatch log group through the AWS integration, and confirm events carry
 66`data_stream.dataset: aws.eks_audit` and
 67`cloud.provider: aws` before enabling this rule.
 68'''
 69severity = "high"
 70tags = [
 71    "Domain: Cloud",
 72    "Domain: Containers",
 73    "Platform: AWS",
 74    "Platform: Kubernetes",
 75    "Data Source: AWS",
 76    "Data Source: Amazon Web Services",
 77    "Data Source: Kubernetes API Server Audit Logs",
 78    "Service: AWS EKS",
 79    "Use Case: Threat Detection",
 80    "Tactic: Persistence",
 81    "Tactic: Privilege Escalation",
 82    "Rule Type: Custom Query (KQL)",
 83    "Resources: Investigation Guide",
 84    "Profile: Beta",
 85]
 86timestamp_override = "event.ingested"
 87type = "query"
 88query = '''
 89data_stream.dataset:"aws.eks_audit" and
 90aws.eks.audit.objectRef.resource:"configmaps" and
 91aws.eks.audit.objectRef.name:"aws-auth" and
 92aws.eks.audit.verb:("update" or "patch" or "delete") and
 93aws.eks.audit.objectRef.namespace:"kube-system" and
 94aws.eks.audit.annotations.authorization_k8s_io/decision:"allow" and
 95not user.name:"eks:kms-storage-migrator"
 96'''
 97
 98[[rule.threat]]
 99framework = "MITRE ATT&CK"
100
101[rule.threat.tactic]
102id = "TA0003"
103name = "Persistence"
104reference = "https://attack.mitre.org/tactics/TA0003/"
105
106[[rule.threat.technique]]
107id = "T1098"
108name = "Account Manipulation"
109reference = "https://attack.mitre.org/techniques/T1098/"
110
111[[rule.threat.technique.subtechnique]]
112id = "T1098.006"
113name = "Additional Container Cluster Roles"
114reference = "https://attack.mitre.org/techniques/T1098/006/"
115
116[[rule.threat]]
117framework = "MITRE ATT&CK"
118
119[rule.threat.tactic]
120id = "TA0004"
121name = "Privilege Escalation"
122reference = "https://attack.mitre.org/tactics/TA0004/"
123
124[[rule.threat.technique]]
125id = "T1098"
126name = "Account Manipulation"
127reference = "https://attack.mitre.org/techniques/T1098/"
128
129[[rule.threat.technique.subtechnique]]
130id = "T1098.006"
131name = "Additional Container Cluster Roles"
132reference = "https://attack.mitre.org/techniques/T1098/006/"

Triage and analysis

Investigating AWS EKS Authentication Configuration Modified

Confirm who changed the mapping (user.name, groups, source.ip, user_agent.original) and whether the change aligns with approved cluster or node-group operations. Compare the new aws-auth mapRoles/mapUsers content to the prior revision if request/response capture is available in audit.

Possible investigation steps

  • Identify any new IAM role ARNs or users bound to system:masters or other privileged Kubernetes groups.
  • Correlate the timestamp with AWS CloudTrail for related EKS or IAM API activity and with GitOps or pipeline commits.
  • Review subsequent API activity from newly mapped IAM principals for secret access, RBAC changes, or workload deployment.
  • If Access Entries are enabled, also review CloudTrail for eks:CreateAccessEntry, eks:AssociateAccessPolicy, and similar API calls around the same window.

Response and remediation

  • If unauthorized, revert aws-auth from a known-good backup, remove rogue map entries, and rotate or restrict IAM that could have performed the change.
  • Audit IAM policies that allow eks:UpdateClusterConfig or broad ConfigMap write access to kube-system.
  • Escalate per incident policy when system:masters mappings appear from unexpected IAM identities.

References

Related rules

to-top