| Horizontal privilege escalation via cluster nodes (multi-tenancy) |
- Configure a role allowed to create and access pods in its own namespace only
- Since this role can create arbitrary pods, the users bound to that role can access other namespaces by creating a privileged pod and accessing the host through that pod
- Once on the host, other namespaces' pods can be accessed and compromised (e.g. by reading out service account tokens from victim pods)
|
| Vertical privilege escalation via create pod privilege |
- Users with the permission to create pods can escalate privileges
- This is because any service account can be provided in the pod specification
- So, the create pod privilege implicitly allows to impersonate any service account within the same namespace
|
Privilege escalation via impersonate permissions |
kubectl –as=system:admin get secrets
|
Privilege escalation via bind or escalate permissions |
- For the
bind verb on (cluster)rolebindings or the escalate verb on (cluster)roles - Having modify and escalate permission on role resources allows users to add arbitrary permissions to their roles
- Writeups:
- Getting into a bind with Kubernetes: The
bind verb is a useful piece of Kubernetes RBAC configuration, but it's also one of the lesser known. As it can enable privilege escalation, it's an important thing to check for when creating or auditing roles
|
Privilege escalation via list |
- With
list you can actually access resources (e.g., secrets) - Writeups:
- When LIST is a Lie in Kubernetes: For the Secrets resource, the "list" verb is a lie. When you "list" a secret, it goes out to the Kubernetes API, pulls down all the secrets including individual secret values themselves. This is a known and documented issue but I see lots of environments that continue to rely on LIST to prevent access to secrets, compared to the GET verb
|