Constrained Impersonation

[qiujian16]

Enhancement Description

• One-line enhancement description (can be used as a release note): Introduce new authorization rules to restrict impersonating on specified resources with specified actions.
• Kubernetes Enhancement Proposal: KEP
• Discussion Link:
  • Finish implementing Acting-As kubernetes#27152
  • https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/edit?tab=t.0#heading=h.j07vugxmibh2
  • https://groups.google.com/g/kubernetes-sig-auth/c/gCJ95N3wyZ0
• Primary contact (assignee): @qiujian16
• Responsible SIGs: sig-auth
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.34
  • Beta release target (x.y):
  • Stable release target (x.y):
• Alpha
  • KEP (k/enhancements) update PR(s): KEP-5284: Constrained Impersonation #5285
  • Code (k/k) update PR(s): KEP-5284: Implement Constrained Impersonation kubernetes#134803
  • Docs (k/website) update PR(s): KEP-5284 Add constrained impersonation doc website#52907

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[qiujian16]

/sig auth

[lmktfy]

I think the title of this KEP should be Constrained Impersonation.

You can already restrict impersonation (eg: deny the verb in your custom authz code), but you can't allow a principal to use only some of the permissions of the principal they impersonate.

The word constrain implies a bounding form restriction (eg you can impersonate this principal but only to perform actions in namespace kube-heptagon. That's different from conditions (eg: you can impersonate this principal, but only if the moon is waning at the time you submit the request).

[qiujian16]

I think the title of this KEP should be Constrained Impersonation.

You can already restrict impersonation (eg: deny the verb in your custom authz code), but you can't allow a principal to use only some of the permissions of the principal they impersonate.

The word constrain implies a bounding form restriction (eg you can impersonate this principal but only to perform actions in namespace kube-heptagon. That's different from conditions (eg: you can impersonate this principal, but only if the moon is waning at the time you submit the request).

that makes sense, thanks. The title is updated to Constrained Impersonation

[stmcginnis]

Hi @qiujian16 👋, v1.34 Enhancements team here.

This is a reminder of the upcoming PRR Freeze on Thursday 12th June 2025.

By this date, there must be a PR open in k/enhancements with:

• The KEP's PRR questionnaire filled out.
• The kep.yaml updated with the stage, latest-milestone, and milestone struct filled out.
• A PRR approval file with the PRR approver listed for the stage the KEP is targeting.

Having the PRR questionnaire filled out by this deadline will help ensure that the PRR team has enough time to review your KEP before Enhancements Freeze on Friday 20th June 2025. For more information on the PRR process, see here.

If you could also confirm assignment for the primary owner, that would be great. Thanks!