DET0572: Suspicious RoleBinding or ClusterRoleBinding Assignment in Kubernetes
This detection strategy is about spotting suspicious Kubernetes RoleBinding or ClusterRoleBinding assignments. The business issue is not the binding object...
Analyst context for executives and security teams
This detection strategy is about spotting suspicious Kubernetes RoleBinding or ClusterRoleBinding assignments. The business issue is not the binding object itself; it is whether a user or service account has been granted roles that could preserve access or raise privileges inside a container cluster. For leaders, this is a control-validation topic for container security, identity governance, and incident readiness.
Executive priority
Treat this as a priority where Kubernetes or container orchestration supports critical services. Role and cluster-role assignments are administrative identity changes, so they affect business continuity, audit evidence, and incident containment. Security leaders should ask whether teams can prove who created or changed bindings, which account received access, what role was granted, and whether the change was expected through an approved deployment or access process.
Technical view
The supplied ATT&CK relationship says this detection strategy detects T1098.006, Additional Container Cluster Roles, associated with persistence and privilege escalation on Containers. SOC and detection teams should validate monitoring for RoleBinding and ClusterRoleBinding creation or modification, especially assignments to user or service accounts that grant elevated or unusual permissions. Because the detection strategy object does not include official detection logic, teams should tune against local baselines: approved CI/CD changes, cluster administration activity, namespace ownership, and expected service-account bindings.
Likely telemetry
- Kubernetes audit logs for RoleBinding and ClusterRoleBinding create, update, patch, and delete events
- Identity context for the actor making the RBAC change, such as user, group, or service account
- Kubernetes RBAC object details, including subject, roleRef, namespace, and cluster scope
- Change-management or deployment pipeline records showing whether the binding was expected
- Cluster configuration or inventory data identifying sensitive namespaces, privileged roles, and service accounts
Detection direction
- Confirm Kubernetes audit logging is enabled and retained for RBAC object changes; without this, coverage will depend on incomplete configuration snapshots or deployment records.
- Alert on new or modified RoleBinding or ClusterRoleBinding assignments that bind powerful roles to unexpected users or service accounts, particularly at cluster scope.
- Compare RBAC changes against approved automation, known administrators, and expected namespace ownership to reduce false positives from legitimate operations.
- Correlate suspicious binding changes with authentication events, service-account activity, and subsequent access to sensitive cluster resources.
- Account for blind spots where clusters are not centrally logged, where audit policy excludes RBAC resources, or where legitimate CI/CD systems make broad RBAC changes.
Mitigation priorities
- Enforce least-privilege RBAC for users and service accounts, prioritizing cluster-scoped permissions and sensitive namespaces.
- Require review and approval for RoleBinding and ClusterRoleBinding changes outside trusted automation paths.
- Limit who can create or modify RBAC bindings and regularly review accounts with rights to grant roles.
- Maintain an auditable inventory of expected Kubernetes roles, bindings, service accounts, and privileged subjects.
- During incidents, review recent RBAC binding changes as part of persistence and privilege-escalation scoping.
Analyst notes and limits
The strongest decision value is in validating identity-change visibility for Kubernetes. This object is a detection strategy with no official description or detection text supplied, so the recommended direction is derived from the object name and its ATT&CK relationship to T1098.006. Local cluster architecture, RBAC model, audit policy, and deployment workflows will determine practical signal quality.
Platforms and tactics are not specified on the detection strategy itself. The related technique provides Containers, persistence, and privilege-escalation context. No official analytic logic, thresholds, data components, mitigations, or procedure examples were supplied, so this take should be treated as guidance for validation rather than a claim of detection coverage.
Suspicious RoleBinding or ClusterRoleBinding Assignment in Kubernetes
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1098.006 | Additional Container Cluster Roles Sub-technique | This object detects Additional Container Cluster Roles. |
All related ATT&CK context
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 | b04d24e6b4bf… |
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 DET0572Open 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.