EKS Authentication Configuration Modified

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

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.

Rule type: query

Rule indices:

logs-kubernetes.audit_logs-*

Severity: high

Risk score: 73

Runs every: 5m

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

Maximum alerts per execution: 100

References:

Tags:

Data Source: Kubernetes
Domain: Kubernetes
Use Case: Threat Detection
Tactic: Persistence
Tactic: Privilege Escalation
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating 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.

Rule query

edit

data_stream.dataset:"kubernetes.audit_logs" and
kubernetes.audit.objectRef.resource:"configmaps" and
kubernetes.audit.objectRef.name:"aws-auth" and
kubernetes.audit.verb:("update" or "patch" or "delete") and
kubernetes.audit.objectRef.namespace:"kube-system" and
kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
not user.name:"eks:kms-storage-migrator"

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Persistence
- ID: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
Technique:
- Name: Account Manipulation
- ID: T1098
- Reference URL: https://attack.mitre.org/techniques/T1098/
Sub-technique:
- Name: Additional Container Cluster Roles
- ID: T1098.006
- Reference URL: https://attack.mitre.org/techniques/T1098/006/
Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
Technique:
- Name: Account Manipulation
- ID: T1098
- Reference URL: https://attack.mitre.org/techniques/T1098/
Sub-technique:
- Name: Additional Container Cluster Roles
- ID: T1098.006
- Reference URL: https://attack.mitre.org/techniques/T1098/006/

« Dynamic Linker Creation ESXI Discovery via Find »