Kubernetes Impersonation: A Hidden Security Risk

2 min read

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 clever 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 (often seniors). They might use broad permissions like * for verbs and resource names, not realizing they're inadvertently granting impersonation capabilities.

This creates a serious security risk. Consider this scenario: A developer with misconfigured impersonation permissions could potentially execute:

kubectl -n kube-system --as evil-user --as-group admin <not allowed action>

Suddenly, a regular developer could act as an admin, bypassing intended access controls.

Best Practices

To protect your Kubernetes cluster from such security vulnerabilities:

  1. Implement strict RBAC policies
  2. Avoid using * wildcards in permissions, especialy in verbs
  3. Regularly audit your RBAC configurations
  4. Be especially careful with impersonation-related permissions

Remember: In Kubernetes security, it's often the features you don't fully understand that can lead to the most significant vulnerabilities. Always take the time to understand the implications of the permissions you grant, and when in doubt, follow the principle of least privilege.