This rule detects Kubernetes API requests where the real actor attempts to impersonate a privileged cluster identity by populating Kubernetes audit impersonation fields (kubernetes.audit.impersonatedUser.username, kubernetes.audit.impersonatedUser.groups) and aligning them with privileged targets (e.g., system:masters, system:kube-controller-manager, system:admin, system:anonymous, cluster-admin). It compares the real actor context (user.name, groups, source IP, user_agent.original) with the impersonated target to determine whether impersonation is taking place and whether it is authorized. The detection looks at data_stream.dataset:kubernetes.audit_logs, requires an authorization decision of allow (kubernetes.audit.annotations.authorization_k8s_io/decision:allow) and a set of verbs that indicate operations (create, delete, get, list, patch, update) performed under impersonation. A broad set of not-user filters excludes known legitimate impersonation by certain service accounts or tooling (e.g., eks event service, AWS/EKS-native roles) to reduce noise. The rule triggers when impersonatedUser.username matches privileged identities (admin, cluster-admin, kubernetes-admin, system:admin, system:anonymous, system:apiserver, system:kube-controller-manager, system:kube-proxy, system:kube-scheduler, system:volume-scheduler, system:node:*, or system:serviceaccount:kube-system:*) or impersonatedUser.groups contains privileged groups (cluster-admin, system:cluster-admins, system:masters). This maps to MITRE ATT&CK techniques T1134 (Access Token Manipulation) under TA0004 (Privilege Escalation) and TA0005 (Defense Evasion), reflecting risks around token issuance, elevated access, and evading controls. The rule has a risk_score of 73 and is tagged as high severity. The accompanying triage guidance suggests verifying real vs impersonated identities, reviewing the scope of the operation (requestURI, objectRef), confirming whether impersonation rights are appropriate, and correlating with related activity (secrets, tokens, RBAC writes, CSR approvals). Response guidance includes revoking or tightening impersonate permissions, rotating credentials for involved accounts, auditing secrets exposure and RBAC drift, and escalating to incident response if unauthorized. False positives can arise from break-glass admin tooling or approved controllers; environments should map expected callers and refine not user.name filters accordingly.