4. Privilege Escalation of the Kubernetes Cluster – ATT&CK® Matrix
MITRE’s ATT&CK®
Privileged Container
A privileged container is a container that has all the capabilities of the host machine. It removes all the limitations regular containers have. Substantially, this means that privileged containers can do almost every action that can be performed directly on the host. Attackers who gain access to a privileged container have permissions to create a new privileged container (by using the compromised pod’s service account. For Instance, they can get access to the host’s resources.
Cluster-Admin Binding
Role-based access control (RBAC) is a crucial security feature in Kubernetes. RBAC can restrict the allowed actions of the various identities in the cluster. Cluster-admin is a built-in high privileged role in Kubernetes. Attackers who have permissions to create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin ClusterRole or to other elevated privileges roles.
Access Cloud Resources
If the Kubernetes cluster is deployed in the cloud, in some cases attackers can leverage their access to a single container in order to get access to other cloud resources outside the cluster. For example, in AKS each node contains service principal credential that is stored in /etc/kubernetes/azure.json. AKS uses this service principal to create and manage Azure resources that are needed for the cluster operation.
By default, the service principal has contributor permissions in the cluster’s Resource Group. Attackers who get access to this service principal file (by hostPath mount, for example) can use its credentials to access or modify the cloud resources.
By default, the service principal has contributor permissions in the cluster’s Resource Group. Attackers who get access to this service principal file (by hostPath mount, for example) can use its credentials to access or modify the cloud resources.