AN1579: Analytic 1579
Detects assignment of high-privilege roles to user or service accounts via Kubernetes RoleBinding or ClusterRoleBinding objects, especially outside of CI/CD automation or from unknown IPs.
Analyst context for executives and security teams
This analytic matters because Kubernetes RoleBinding and ClusterRoleBinding changes can turn an ordinary user or service account into a highly privileged actor in a container environment. For leaders, the practical question is whether privilege changes in Kubernetes are governed, logged, and explainable—especially when they happen outside expected CI/CD automation or originate from unfamiliar IP addresses.
Executive priority
Prioritize this as a cloud/container governance and incident-readiness control point. High-privilege Kubernetes role assignments can affect operational resilience because they may expand access to workloads, namespaces, and cluster resources. Executives and risk owners should ask whether privileged role grants require approval, whether exceptions are auditable, and whether the SOC can rapidly distinguish approved automation from suspicious manual or unknown-source changes.
Technical view
For SOC, detection engineering, and IR teams, validate monitoring for Kubernetes RoleBinding and ClusterRoleBinding object creation or modification on the Containers platform. The key analytic focus is assignment of high-privilege roles to user or service accounts, with added scrutiny when the actor, source IP, or execution path does not match known CI/CD automation. Because no official detection logic is supplied, local teams must define what counts as high privilege, expected automation, trusted source ranges, and approved service accounts.
Likely telemetry
- Kubernetes audit logs for RoleBinding and ClusterRoleBinding create, update, or patch events
- Subject details for bound users, groups, and service accounts
- Referenced Role or ClusterRole names and permissions context
- Actor identity performing the binding change
- Source IP address associated with the API request
Detection direction
- Baseline legitimate RoleBinding and ClusterRoleBinding activity by namespace, cluster, actor, service account, source IP, and CI/CD workflow.
- Alert on high-privilege role assignments to user or service accounts when performed by unexpected identities, from unknown IPs, or outside approved automation paths.
- Tune carefully for administrative maintenance and deployment automation to reduce false positives while preserving visibility into privilege expansion.
- Correlate Kubernetes audit events with CI/CD logs and change records so analysts can quickly determine whether a privileged binding was approved.
- Validate that audit logging is enabled and retained for the relevant Kubernetes control plane events; without it, this analytic may have limited value.
Mitigation priorities
- Define and document which Kubernetes Roles or ClusterRoles are considered high privilege in the local environment.
- Restrict who can create or modify RoleBinding and ClusterRoleBinding objects, especially for cluster-wide privileges.
- Use controlled CI/CD or approved administrative workflows for privileged binding changes and preserve audit evidence.
- Review existing high-privilege bindings for unnecessary user or service account access.
- Ensure incident response playbooks include steps to investigate and revoke suspicious Kubernetes privilege assignments.
Analyst notes and limits
This object is a detection analytic, not a technique description. The supplied ATT&CK fields identify the platform as Containers and describe the analytic focus, but do not provide tactic mapping, detection pseudocode, related techniques, or relationship context. The strongest operational value comes from combining Kubernetes audit evidence with known CI/CD and change-management context.
Official detection content is not provided, and no relationships are supplied. Any definition of high privilege, unknown IP, expected automation, or suspicious assignment must be derived from the organization’s Kubernetes architecture, identity model, and operating procedures. This take does not imply active exploitation, attribution, or guaranteed detection coverage.
Analytic 1579
Detects assignment of high-privilege roles to user or service accounts via Kubernetes RoleBinding or ClusterRoleBinding objects, especially outside of CI/CD automation or from unknown IPs.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | b0e571abfa1c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1579Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.