heroui logo

Kubernetes RBAC Wildcard Elevation on Existing Role

Elastic Detection Rules

View Source
Summary
Detects when an existing Kubernetes Role or ClusterRole is patched or updated to grant wildcard permissions (verbs and resources) across all API resources, effectively enabling cluster-admin-like access. The rule requires a RequestResponse audit and that the merged role after apply is visible in the response; loopback source IPs are ignored to reduce noise. It shines when the Kubernetes audit logs show updates/patches to roles/clusterroles with an authorization decision of allow, a ResponseComplete stage, and a response containing responseObject.rules.verbs:"*" and responseObject.rules.resources:"*". The detection uses the Kubernetes audit trail to identify who (user, client) performed the change, from which resource, and under what URI/action, enabling rapid containment and investigation. The rule maps to MITRE ATT&CK techniques Account Manipulation (T1098) and Additional Container Cluster Roles (T1098.006), reflecting privilege escalation risk. False positives include legitimate platform installers, GitOps controllers, or break-glass/admin overrides that intentionally widen access; these should be correlated with change records and baselined. Triage guidance emphasizes diffing the before/after Role/ClusterRole, identifying all resulting bindings (RoleBindings/ClusterRoleBindings), and checking for related sensitive actions (secret reads, exec, additional RBAC changes) from the same identity. Remediation steps include reverting the role, removing unintended bindings, rotating credentials for the actor, and enforcing future wildcard RBAC changes only through policy-as-code or PR-controlled pipelines to prevent ungoverned privilege expansion.
Categories
  • Kubernetes
Data Sources
  • Application Log
ATT&CK Techniques
  • T1098
  • T1098.006
Created: 2026-04-27