To debug RBAC for users/groups in kubernetes, I always used kubectl auth can-i --as <user> --as-grop <group> without actually knowing what --as options actually do. After many years of my ignorance for this option, I finally learned what it does.
First of all, --as, --as-group, --as-uid are global kubectl options used for impersonation.
--as='':
Username to impersonate for the operation. User could be a regular user or a service account in a namespace.
--as-group=[]:
Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
--as-uid='':
UID to impersonate for the operation.
The important thing to realize, is that authenticated user is replaced by impersonated user for the authorization.
Technicaly, the --as* options add Impersonate-* HTTP headers for requests to Kubernetes API server.
The API authenticates the user sending the request and checks whether the user is allowed to use impersonation.
If yes, information about the user are replaced with impersonation values provided by the HTTP headers and requests then acts on impersonated user info.
In real world, many Kubernetes admins tend have more open RBAC for some limited group of developers (let’s say seniors) without realizing that impersonation permisions are accidentally allowed by very open verbs (*) and resource names.
This small accident allows everybody with such role to escalate priviliges. Even though I am just “developer”, with misconfigured impersonation I act as admin kubectl -n kube-system --as evil-user --as-group admin <not allowed action>.
Therefore, to avoid potentional situation where developer with bad intentions can harm your environment, try to always implement very strict RBAC policies and avoid * as much as possible. Like in my case, there might be always something you don’t know about.