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
- AWS EKS Client Certificate Signing Request Created or Approved
- AWS EKS Cluster-Admin Role Binding Created
- AWS EKS Creation of a RoleBinding Referencing a ServiceAccount
- AWS EKS Admission Webhook Created or Modified
- AWS EKS Creation or Modification of Sensitive Role