Have you ever used kubectl auth can-i --as <user> --as-group <group> to debug RBAC permissions in Kubernetes? I certainly have, but for years I never truly understood what these --as flags actually do under the hood. Today, let’s dive into the mechanics of Kubernetes impersonation and uncover a potential security risk that many administrators might be overlooking.
What is Kubernetes Impersonation?
The --as, --as-group, and --as-uid flags are global kubectl options that enable impersonation functionality:
--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.
When you use these flags, something crucial happens: the authenticated user’s identity is completely replaced by the impersonated user for authorization purposes. This happens through a mechanism where kubectl adds Impersonate-* HTTP headers to requests sent to the Kubernetes API server.
The Security Implications
Here’s where things get interesting - and potentially dangerous. Many Kubernetes administrators, in an effort to be helpful, create overly permissive RBAC policies for certain developer groups.
I once encountered a scenario where a company granted very open privileges for the core API group:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: developer
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["*"]
While this approach might already seem excessive, the intention was to grant developers flexibility within the cluster while restricting only third-party API groups, which the company considered the only risk group.
The problem is that when you grant wildcard permissions (*) on resources and verbs, you’re also inadvertently granting impersonation capabilities. Developers with this role can easily exploit impersonation to escalate their privileges:
kubectl -n kube-system --as cluster-admin --as-group system:masters delete <thing we wanted to protect>
Suddenly, a regular developer could act as a cluster administrator, completely bypassing the intended access controls.
Best Practices
To protect your Kubernetes cluster from such security vulnerabilities:
- Implement strict RBAC policies
- Avoid using
*wildcards in permissions - Regularly audit RBAC configurations
- Be especially careful with impersonation-related permissions
Always take the time to understand the implications of the permissions you grant, and when in doubt, follow the principle of least privilege.