impersonate groups
Assume any group's privileges via the Impersonate-Group header.
Kubernetes requires Impersonate-User alongside it, since group/extra/uid impersonation is rejected without a user header.
Impersonating system:masters is T0, since that built-in group bypasses RBAC and webhook authorization entirely.
In v1.36+, constrained impersonation can scope new-style grants, but legacy impersonate rules still work.
- API Group
- (core)
- Scope
- cluster
- Audit Level
- RequestResponse
Escalation Paths
Send Impersonate-User together with Impersonate-Group: system:masters.
Kubernetes rejects group impersonation without an impersonated user.
The API server authorizes the request as a member of system:masters, a built-in group with unrestricted API-server access that bypasses RBAC/Webhook restrictions.
Perform any cluster-wide action.
Additional rights needed:
· both; the API server rejects a group header with no user header
Note:
In v1.36+, constrained impersonation may require action-scoped permissions for new-style grants, but legacy impersonate RBAC rules still work.
Mitigation is to remove the RBAC grant, fix IdP/IAM mapping, or rotate the CA only if the source is a leaked non-revokable system:masters client certificate.