Description
The impersonate permission allows requests as authorized users, groups or service accounts. If the target identity has greater privileges, the caller may perform actions beyond their original permissions.
This permission affects both access control and audit interpretation. Restrict it carefully in production.
Potential impact
- Users may make requests with another user’s or service account’s permissions.
- Privilege escalation may occur; audits must consider both the original caller and the impersonated identity.
- A compromised account may quickly gain access to higher privileges.
Remediation
- Do not grant
impersonateto ordinary accounts. - Allow it only for administrators who require it, and limit target identities with controls such as
resourceNames. - Monitor impersonation requests in audit logs.
Examples
Bindings that grant the role are omitted. The revised example retains read access only to ServiceAccounts, which are actual API resources. Normal users and groups are not Kubernetes API objects that can be retrieved.
Before
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: impersonator-role
rules:
- apiGroups: [""]
resources: ["users", "groups", "serviceaccounts"]
verbs: ["impersonate"]
After
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: impersonator-role-neg
rules:
- apiGroups: [""]
resources: ["serviceaccounts"]
verbs: ["get"]
Explanation:
- Before:
impersonateallows acting as other identities, creating a privilege escalation risk. - After: This role permits ServiceAccount reads without impersonation. Check impersonate permissions granted by other roles too.