Skip to content
SRE & DevOpsDeep Dive Published Updated 3 min readViews unavailable

Kubernetes RBAC Impersonation: Testing Authorization Without Sharing Credentials

How Kubernetes impersonation headers and RBAC verbs support least-privilege authorization tests while preserving identity, scope, and audit evidence.

Kubernetes administrators often need to answer, “Can this service account perform this operation?” Copying its token or granting temporary cluster-admin is both unnecessary and dangerous. The API server supports impersonation: an authenticated caller asks authorization to evaluate the request as another user, group, service account, UID, or selected extra attributes.

Impersonation is a privileged API operation

Clients send Impersonate-User and related headers. The API server first authenticates the real caller, verifies that caller is authorized to impersonate every requested attribute, then authorizes the underlying API request as the impersonated identity.

kubectl exposes this with --as and --as-group:

kubectl auth can-i create deployments.apps \
  -n payments \
  --as=system:serviceaccount:payments:deployer

This does not log in as the service account or retrieve its token. The administrator’s original identity remains available to API audit logging alongside the impersonated identity.

Grant the narrow impersonation verb

RBAC uses the impersonate verb. Users and groups live in the core API group; service accounts use the serviceaccounts resource. A role can constrain named targets with resourceNames:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: test-payments-deployer
rules:
  - apiGroups: [""]
    resources: ["serviceaccounts"]
    resourceNames: ["deployer"]
    verbs: ["impersonate"]

Resource-name constraints do not include namespace in this rule. Kubernetes service-account usernames include namespace (system:serviceaccount:namespace:name), while the RBAC impersonation resource semantics must be tested carefully for the intended target. Where precise scoping cannot be expressed with one binding, use a purpose-built authorization test service or admission boundary rather than grant broad user/group impersonation.

Impersonating groups is especially powerful. Adding system:masters effectively requests membership in the cluster’s privileged group and should not be available to routine testers. Do not grant wildcard impersonation over users, groups, UIDs, and extras as a convenience.

can-i is a SubjectAccessReview, not an execution test

kubectl auth can-i asks whether an action is authorized. It does not prove admission webhooks, quotas, schema validation, finalizers, external dependencies, or the application itself will allow a real request. Conversely, a denied operation may come from authorization, while an allowed SubjectAccessReview can still produce a later admission denial.

Test the complete tuple: verb, API group, resource, subresource, namespace, and optionally resource name. get pods does not imply get pods/log; create deployments does not imply update deployments/status; namespaced permission does not imply cluster scope.

kubectl auth can-i get pods/log \
  -n payments \
  --as=system:serviceaccount:payments:support

Non-resource URLs such as /metrics or /healthz use separate RBAC rules and should be included when relevant.

Authorization tests should be versioned

Create a matrix of expected allows and denies for each operational role. Run it against a disposable or policy-test cluster during RBAC changes, and fail when an expected deny becomes allowed. Negative tests matter: a deployer that can create workloads but also read every Secret is not least privilege.

Aggregated ClusterRoles can change when labels add new component roles. Admission controllers and custom authorizers can also supplement RBAC. Record the cluster version and enabled authorization chain when interpreting results.

Preserve audit identity

Enable an API audit policy that records impersonated user information at an appropriate level without collecting unnecessary Secret bodies. Send audit records to protected storage and alert on unusual impersonation targets, privileged groups, or high-volume use.

Human workflows should use short-lived real authentication, a narrowly scoped impersonation grant, and a ticketed reason. Automation should have a dedicated identity and fixed target set. Revocation means removing that grant—not rotating somebody else’s service-account token after it was copied into a shell.

Impersonation is useful precisely because it separates who performed the test from whose authorization was evaluated. Keep both identities visible and constrain the bridge between them.

Related:

Sources:

Comments