Additional Container Cluster Roles (T1098.006) is a sub-technique of Account Manipulation. MITRE places it under persistence and privilege escalation, and the platform is containers.
In short, someone with enough permissions adds more permissions to an account they control, so they keep a foothold in the cluster even if the original entry point is closed. Kubernetes makes this easy to do and easy to miss, because role bindings are ordinary API objects.
How attackers use it
MITRE describes the pattern like this. An adversary with sufficient permissions may create a RoleBinding or a ClusterRoleBinding to bind a Role or ClusterRole to a Kubernetes account. Where attribute-based access control (ABAC) is in use, they may instead modify the ABAC policy to give the target account additional permissions.
A few details from MITRE are worth keeping in mind:
- The change may immediately follow account creation or other suspicious account activity.
- It may also be applied to an existing valid account that the adversary has already compromised, which means no new account appears to alert on.
- In managed Kubernetes services, cloud role assignments or ABAC policies can be used in place of, or alongside, local permission assignments. MITRE names Google Kubernetes Engine, Amazon Elastic Kubernetes Service and Azure Kubernetes Service as examples. In those cases the technique may be paired with added cloud roles, so you need to watch both layers.
How to detect it
The MITRE detection strategy is Suspicious RoleBinding or ClusterRoleBinding Assignment in Kubernetes. The analytic looks for high-privilege roles being assigned to user or service accounts through RoleBinding or ClusterRoleBinding objects, especially when the change comes from outside your CI/CD automation or from an unknown address.
To act on that, turn on Kubernetes audit logging and send it somewhere searchable. Then look for:
- Create and update events on rolebindings and clusterrolebindings.
- Bindings that reference powerful roles such as cluster-admin.
- Changes made by an identity that is not your deployment pipeline.
- Changes from a source address you do not recognize.
- Bindings to a service account that has just been created.
Compare against a baseline. Most clusters change role bindings rarely and through a known path, so anything else stands out.
How to reduce the risk
MITRE lists two mitigations:
- Require multi-factor authentication for user accounts integrated into the cluster through cloud deployments or through authentication protocols such as LDAP or SAML. A stolen password alone should not reach the API server.
- Use user account management so that low-privileged accounts cannot add permissions to accounts or update cluster roles. In RBAC terms, tightly limit who holds the rights to create or modify bindings and roles.
Keep the number of people and service accounts that can edit RBAC objects small, and keep cluster-admin out of day to day use.
Check your own environment
These are read-only checks using kubectl:
# Kubernetes (kubectl): list all cluster-wide bindings with their roles and subjects
kubectl get clusterrolebindings -o wide
# Kubernetes (kubectl): list namespaced bindings across all namespaces
kubectl get rolebindings --all-namespaces -o wide
# Kubernetes (kubectl): list what the current identity is allowed to do
kubectl auth can-i --list
Review the output for bindings you cannot explain, especially to cluster-admin, and for subjects that are service accounts with broad rights. Then confirm that audit logging is enabled on your control plane and that binding changes reach your monitoring.
Try it yourself
Seeing every cluster and cloud account in one inventory is the first step to knowing which role changes are normal. This demo walks through asset discovery.
Click through it at your own pace, or open it full screen.
Quick check
Which Kubernetes objects does MITRE name for this technique?
RoleBinding and ClusterRoleBinding, which bind a Role or ClusterRole to an account. Where ABAC is used, a modified ABAC policy can do the same job.
Why watch cloud role assignments as well as cluster bindings?
In managed Kubernetes services, cloud RBAC assignments can be used in place of or together with local ones, so a change in either layer can grant access.
