Kubernetes Creation of a RoleBinding Referencing a ServiceAccount

  1[metadata]
  2creation_date = "2026/02/04"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2026/02/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects the creation of RoleBindings or ClusterRoleBindings that reference a ServiceAccount,
 11which may indicate privilege delegation or potential RBAC misconfiguration leading to elevated access.
 12"""
 13index = ["logs-kubernetes.audit_logs-*"]
 14language = "kuery"
 15license = "Elastic License v2"
 16name = "Kubernetes Creation of a RoleBinding Referencing a ServiceAccount"
 17note = """ ## Triage and analysis
 18
 19> **Disclaimer**:
 20> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 21
 22### Investigating Kubernetes Creation of a RoleBinding Referencing a ServiceAccount
 23
 24This rule detects creation of a RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, a common way to delegate access inside the cluster and a frequent precursor to stealthy privilege escalation or persistence. Attackers who gain the ability to create bindings often attach an over-privileged role (or cluster-wide role) to an existing ServiceAccount used by a workload, then use that workload’s token to operate with elevated rights without creating new user identities.
 25
 26### Possible investigation steps
 27
 28- Identify the principal that created the binding (user/service account), along with the source IP, user-agent, and authentication method, to determine whether it originated from an expected controller, CI/CD system, or a suspicious client.
 29- Review the new RoleBinding/ClusterRoleBinding’s `roleRef` and subjects to determine what permissions were granted, and assess blast radius by inspecting the referenced Role/ClusterRole rules for high-impact verbs/resources (e.g., secrets, pods/exec, nodes, RBAC).
 30- Determine where the referenced ServiceAccount is used by enumerating pods/deployments in the namespace that run under it, checking whether service account tokens are mounted, and whether this SA is associated with privileged workloads or externally reachable services.
 31- Correlate nearby audit activity for additional RBAC or identity changes (new roles, bindings, service accounts, token requests) and for follow-on actions performed using the ServiceAccount that indicate attempted privilege escalation or persistence.
 32- Validate the change against approved deployment/change records and, if unauthorized or overly permissive, remove/roll back the binding and rotate or invalidate the ServiceAccount credentials while tightening RBAC to least privilege.
 33
 34### False positive analysis
 35
 36- A cluster administrator or GitOps-driven deployment legitimately creates or updates RoleBindings/ClusterRoleBindings to grant a workload ServiceAccount the minimal permissions required for a new release, namespace onboarding, or routine RBAC refactoring.
 37- Kubernetes controllers or automation running under authorized identities (e.g., internal operators, admission policies, or namespace provisioning jobs) create bindings for default or system ServiceAccounts as part of standard cluster bootstrap, reconciliation, or multi-tenant namespace setup.
 38
 39### Response and remediation
 40
 41- Immediately fetch and snapshot the created RoleBinding/ClusterRoleBinding manifest, its referenced Role/ClusterRole, and recent Kubernetes audit events around the creator and the ServiceAccount to preserve evidence and establish scope.  
 42- Contain potential misuse by deleting or scaling down workloads that use the referenced ServiceAccount and temporarily revoking the new binding (or applying an emergency deny policy via admission controls) until the change is validated.  
 43- Eradicate unauthorized privilege delegation by removing the binding, replacing it with a least-privilege Role/RoleBinding scoped to the required namespace/resources, and rotating credentials by recreating the ServiceAccount or forcing token/key rotation for any dependent workloads.  
 44- Recover safely by redeploying affected applications with the corrected RBAC, validating that required operations succeed without cluster-admin-equivalent rights, and monitoring for repeated binding creation or follow-on access to secrets, pod exec, or node-level resources.  
 45- Escalate to platform security/incident response immediately if the binding references a high-privilege ClusterRole (e.g., cluster-admin), targets a broadly used ServiceAccount, or is followed by suspicious actions such as secret reads, new token requests, or pod exec sessions from the same identity.  
 46- Harden by enforcing RBAC guardrails with admission policies that restrict who can create RoleBindings/ClusterRoleBindings and which roles may be referenced, disabling auto-mounting of service account tokens where not needed, and adopting GitOps-only RBAC changes with mandatory review.
 47"""
 48references = [
 49    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
 50]
 51risk_score = 47
 52rule_id = "fd00769d-b18d-450a-a844-7a9f9c71995e"
 53severity = "medium"
 54tags = [
 55    "Data Source: Kubernetes",
 56    "Domain: Kubernetes",
 57    "Use Case: Threat Detection",
 58    "Tactic: Persistence",
 59    "Tactic: Privilege Escalation",
 60    "Resources: Investigation Guide",
 61]
 62timestamp_override = "event.ingested"
 63type = "query"
 64query = '''
 65event.dataset: "kubernetes.audit_logs" and kubernetes.audit.requestObject.spec.serviceAccountName:* and
 66kubernetes.audit.verb:"create" and kubernetes.audit.objectRef.resource:("rolebindings" or "clusterrolebindings") and
 67kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
 68'''
 69
 70[[rule.threat]]
 71framework = "MITRE ATT&CK"
 72
 73[[rule.threat.technique]]
 74id = "T1098"
 75name = "Account Manipulation"
 76reference = "https://attack.mitre.org/techniques/T1098/"
 77
 78[[rule.threat.technique.subtechnique]]
 79id = "T1098.006"
 80name = "Additional Container Cluster Roles"
 81reference = "https://attack.mitre.org/techniques/T1098/006/"
 82
 83[rule.threat.tactic]
 84id = "TA0003"
 85name = "Persistence"
 86reference = "https://attack.mitre.org/tactics/TA0003/"
 87
 88[[rule.threat]]
 89framework = "MITRE ATT&CK"
 90
 91[[rule.threat.technique]]
 92id = "T1098"
 93name = "Account Manipulation"
 94reference = "https://attack.mitre.org/techniques/T1098/"
 95
 96[[rule.threat.technique.subtechnique]]
 97id = "T1098.006"
 98name = "Additional Container Cluster Roles"
 99reference = "https://attack.mitre.org/techniques/T1098/006/"
100
101[rule.threat.tactic]
102id = "TA0004"
103name = "Privilege Escalation"
104reference = "https://attack.mitre.org/tactics/TA0004/"