Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1098.006: Additional Container Cluster Roles

An adversary may add additional roles or permissions to an adversary-controlled user or service account to maintain persistent access to a container orchestration system. For example, an adversary with sufficient permissions may create a RoleBinding or a ClusterRoleBinding to bind a Role or ClusterRole to a Kubernetes account.[1][2] Where attribute-based access control (ABAC) is in use, an adversary with sufficient permissions may modify a Kubernetes ABAC policy to give the target account additional permissions.[3] This account modification may immediately follow Create Account or other malicious account activity. Adversaries may also modify existing Valid Accounts that they have compromised.

Note that where container orchestration systems are deployed in cloud environments, as with Google Kubernetes Engine, Amazon Elastic Kubernetes Service, and Azure Kubernetes Service, cloud-based role-based access control (RBAC) assignments or ABAC policies can often be used in place of or in addition to local permission assignments.[4][5][6] In these cases, this technique may be used in conjunction with Additional Cloud Roles.

EnterpriseT1098.006Sub-techniqueObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This technique matters because Kubernetes permissions can become a persistence mechanism. If an attacker or misused account can bind extra Roles or ClusterRoles to a user or service account, they may preserve or increase access inside a container cluster even after the initial entry point is addressed. In cloud-hosted Kubernetes, local cluster permissions may also intersect with cloud IAM assignments, making identity governance and cluster auditability central to resilience.

Executive priority

Treat Kubernetes role assignment changes as high-value identity events, not routine administration only. Leaders should ask whether cluster RBAC or ABAC changes are logged, reviewed, and tied to approved change processes across self-managed and managed services such as GKE, EKS, and AKS. This is relevant to incident decision-making, least-privilege programs, privileged access reviews, and audit evidence for who can grant access inside production container environments.

Technical view

For SOC, detection engineering, and IR teams, validate visibility into creation or modification of Kubernetes RoleBinding and ClusterRoleBinding objects, changes to ABAC policy where ABAC is used, and permission changes affecting users or service accounts. Because ATT&CK provides no official detection text for this sub-technique, use the related detection strategy, DET0572: Suspicious RoleBinding or ClusterRoleBinding Assignment in Kubernetes, as a starting point. Triage should consider whether the actor, target account, namespace, role scope, and timing align with expected administrative activity. Also evaluate related account activity such as Create Account or use of existing Valid Accounts, and cloud IAM role assignments where Kubernetes is deployed in cloud environments.

Likely telemetry

  • Kubernetes API server audit logs for RoleBinding and ClusterRoleBinding create, update, patch, and delete events
  • Kubernetes RBAC objects, including Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, users, groups, and service accounts
  • ABAC policy change records where Kubernetes ABAC authorization is in use
  • Cloud provider IAM audit logs for managed Kubernetes identity mappings or service account role assignments
  • Change management records or infrastructure-as-code history for expected cluster permission changes

Detection direction

  • Baseline normal Kubernetes RBAC administration by cluster, namespace, actor, and target service account to reduce false positives from legitimate platform operations.
  • Alert on unexpected RoleBinding or ClusterRoleBinding assignments, especially broad ClusterRole grants or bindings to newly created, rarely used, or externally authenticated accounts.
  • Correlate RBAC changes with account creation, recent authentication events, and cloud IAM changes when the cluster runs in a managed cloud service.
  • Review ABAC policy modification monitoring if ABAC is enabled; environments that only monitor RBAC objects may miss ABAC-based permission expansion.
  • Validate that audit logging captures both local Kubernetes authorization changes and cloud IAM assignments that can influence cluster access.

Mitigation priorities

  • Enforce user account management practices for Kubernetes users and service accounts, including lifecycle controls, ownership, periodic review, and removal of unused or over-privileged accounts.
  • Apply least privilege to Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, and cloud IAM roles associated with managed Kubernetes clusters.
  • Require multi-factor authentication for human access paths to critical cluster and cloud administration interfaces where supported.
  • Use approval and review workflows for permission changes, especially cluster-wide bindings and service account role assignments.
  • Regularly compare live RBAC or ABAC configuration against expected policy or infrastructure-as-code definitions to identify drift.
Analyst notes and limits

This object is a sub-technique of Account Manipulation and is scoped to Containers with persistence and privilege-escalation tactics. The supplied relationship to DET0572 gives a specific defensive focus on suspicious RoleBinding or ClusterRoleBinding assignments. The supplied mitigation relationships support account lifecycle management and MFA, but local least-privilege design and cloud IAM governance determine practical effectiveness.

ATT&CK does not provide official detection text for this technique, and the supplied data does not establish active exploitation, specific adversary attribution, or guaranteed detection coverage. Cloud-provider examples are included only because the official description references GKE, EKS, and AKS identity/RBAC interactions. Final severity and coverage depend on local Kubernetes configuration, whether RBAC or ABAC is used, cloud IAM integration, audit log retention, and administrative change patterns.

Official MITRE ATT&CK definition

Additional Container Cluster Roles

An adversary may add additional roles or permissions to an adversary-controlled user or service account to maintain persistent access to a container orchestration system. For example, an adversary with sufficient permissions may create a RoleBinding or a ClusterRoleBinding to bind a Role or ClusterRole to a Kubernetes account.[1][2] Where attribute-based access control (ABAC) is in use, an adversary with sufficient permissions may modify a Kubernetes ABAC policy to give the target account additional permissions.[3] This account modification may immediately follow Create Account or other malicious account activity. Adversaries may also modify existing Valid Accounts that they have compromised.

Note that where container orchestration systems are deployed in cloud environments, as with Google Kubernetes Engine, Amazon Elastic Kubernetes Service, and Azure Kubernetes Service, cloud-based role-based access control (RBAC) assignments or ABAC policies can often be used in place of or in addition to local permission assignments.[4][5][6] In these cases, this technique may be used in conjunction with Additional Cloud Roles.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1098 Account Manipulation This object subtechnique of Account Manipulation.
Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
dc4704bd5d62b950...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle dc4704bd5d62…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Kubernetes RBAC

    Kubernetes. (n.d.). Role Based Access Control Good Practices. Retrieved March 8, 2023.

    Open source URL
  2. [2]
    Aquasec Kubernetes Attack 2023

    Michael Katchinskiy, Assaf Morag. (2023, April 21). First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters. Retrieved July 14, 2023.

    Open source URL
  3. [3]
    Kuberentes ABAC

    Kuberenets. (n.d.). Using ABAC Authorization. Retrieved July 14, 2023.

    Open source URL
  4. [4]
    Google Cloud Kubernetes IAM

    Google Cloud. (n.d.). Create IAM policies. Retrieved July 14, 2023.

    Open source URL
  5. [5]
    AWS EKS IAM Roles for Service Accounts

    Amazon Web Services. (n.d.). IAM roles for service accounts. Retrieved July 14, 2023.

    Open source URL
  6. [6]
    Microsoft Azure Kubernetes Service Service Accounts

    Microsoft Azure. (2023, April 28). Access and identity options for Azure Kubernetes Service (AKS). Retrieved July 14, 2023.

    Open source URL
  7. [7]
    mitre-attack T1098.006
    Open source URL
Source and licensing

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.