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.
\nThe User Impersonation documentation is the primary reference.
\nA 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.
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.
\nDSE 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.
\nReview 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.
\nDefine 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.
\nFor 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.
\nProposed 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.
\nFirst 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe User Impersonation documentation is the primary reference.\nA 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich real caller submits the request and protects its credentials?\nWhich exact user and groups are intended after impersonation?\nWho approved the caller’s impersonation grant and permitted values?\nWhich harmless operation should the resulting identity be allowed to perform, and which should remain denied?\n\nDSE recommendation: draw the two identity checkpoints\nDSE 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.\nReview 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.\nDefine 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.\nFor 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.\nVerification and evidence\nProposed 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.\nFirst 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.\nOfficial references\n\nUser Impersonation — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [User Impersonation](https://kubernetes.io/docs/reference/access-authn-authz/user-impersonation/) documentation is the primary reference.\n\nA 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which real caller submits the request and protects its credentials?\n\n- Which exact user and groups are intended after impersonation?\n\n- Who approved the caller’s impersonation grant and permitted values?\n\n- Which harmless operation should the resulting identity be allowed to perform, and which should remain denied?\n\n## DSE recommendation: draw the two identity checkpoints\n\nDSE 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.\n\nReview 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.\n\nDefine 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.\n\nFor 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.\n\n## Verification and evidence\n\nProposed 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.\n\nFirst 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.\n\n## Official references\n\n- [User Impersonation](https://kubernetes.io/docs/reference/access-authn-authz/user-impersonation/) — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/separate-caller-permission-from-impersonated-identity-in-kubernetes-requests/", "url": "https://update.dsesecurity.com/updates/separate-caller-permission-from-impersonated-identity-in-kubernetes-requests/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/separate-caller-permission-from-impersonated-identity-in-kubernetes-requests/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Separate caller permission from impersonated identity in Kubernetes requests", "item": "https://update.dsesecurity.com/updates/separate-caller-permission-from-impersonated-identity-in-kubernetes-requests/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/separate-caller-permission-from-impersonated-identity-in-kubernetes-requests/#article", "identifier": "https://update.dsesecurity.com/updates/separate-caller-permission-from-impersonated-identity-in-kubernetes-requests/", "url": "https://update.dsesecurity.com/updates/separate-caller-permission-from-impersonated-identity-in-kubernetes-requests/", "headline": "Separate caller permission from impersonated identity in Kubernetes requests", "description": "Trace the authenticated caller, impersonation grant and effective user as separate checkpoints for traditional Kubernetes impersonation.", "abstract": "Trace the authenticated caller, impersonation grant and effective user as separate checkpoints for traditional Kubernetes impersonation.", "articleBody": "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.\nSource fact: documented behavior\nThe User Impersonation documentation is the primary reference.\nA 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich real caller submits the request and protects its credentials?\nWhich exact user and groups are intended after impersonation?\nWho approved the caller’s impersonation grant and permitted values?\nWhich harmless operation should the resulting identity be allowed to perform, and which should remain denied?\n\nDSE recommendation: draw the two identity checkpoints\nDSE 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.\nReview 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.\nDefine 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.\nFor 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.\nVerification and evidence\nProposed 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.\nFirst 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.\nOfficial references\n\nUser Impersonation — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:04:32+00:00", "dateModified": "2026-10-30T06:05:14+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/separate-caller-permission-from-impersonated-identity-in-kubernetes-requests/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/separate-caller-permission-from-impersonated-identity-in-kubernetes-requests/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Separate caller permission from impersonated identity in Kubernetes requests" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 512, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes — User Impersonation", "url": "https://kubernetes.io/docs/reference/access-authn-authz/user-impersonation/" } } ] } }