Separate caller permission from impersonated identity in Kubernetes requests

Bottom line: Write both identities into the access review: the caller submitting the request and the user information used after impersonation. Approve the permitted impersonation relationship before using it as a troubleshooting shortcut.

Source fact: documented behavior

The User Impersonation documentation is the primary reference.

A Kubernetes impersonation request authenticates the caller with the caller’s credentials, checks impersonation privileges, replaces request user information and authorizes using the impersonated information. In kubectl, --as supplies the impersonated username and --as-group supplies an impersonated group. Traditional impersonation requires the impersonate verb for the relevant identity attribute, and RBAC resourceNames can restrict the allowed attribute values.

What the source does not establish

This article follows traditional impersonation for user and group access review. It excludes the separate constrained-impersonation extension, UID and extra-field version details, and production node-maintenance examples. It does not approve an identity or grant administrative access.

Applicability questions

• Which real caller submits the request and protects its credentials?
• Which exact user and groups are intended after impersonation?
• Who approved the caller’s impersonation grant and permitted values?
• Which harmless operation should the resulting identity be allowed to perform, and which should remain denied?

DSE recommendation: draw the two identity checkpoints

DSE recommends an access record with separate fields for caller authentication, permission to impersonate and the intended effective identity. Ask the access owner to name the operational need before constructing a grant. Keep copied credentials and reusable tokens outside the record.

Review user and group choices together. Compare each requested impersonation value with the approved relationship and the actual RBAC configuration. Avoid adopting the documentation’s powerful demonstration identity merely because its example command succeeds. Use a dedicated harmless test identity and retain only sanitized configuration evidence.

Define an allowed action and an excluded action for the effective identity. Make their resource and scope explicit before invoking the client. Record the ordinary caller’s intended access separately, so the reviewer can distinguish a missing impersonation grant from an authorization decision made after the identity change.

For an unexpected denial, identify which checkpoint produced the result before broadening permissions. Have the responsible administrator inspect the applicable grant and value restrictions through the established access-management process. Keep removal or expiry of the temporary troubleshooting arrangement in the same review, with an owner for verifying that routine access still uses the intended identity.

Verification and evidence

Proposed verification, not performed: use a permitted test caller and a separately approved low-privilege target identity. Prepare a harmless read operation and an explicitly excluded action on disposable resources. Write the expected caller, impersonated user and groups for each request.

First examine the ordinary caller path, then the approved impersonated path. Include a deliberately unapproved impersonation value only in the authorized test plan. Retain redacted request settings, the applicable grant, actual authorization results and identity observations available through approved tooling. Resolve a failure at its observed checkpoint rather than treating every denial as a reason to grant broader target permissions.

Official references

• User Impersonation — Kubernetes.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.