KEP-5284: Constrained Impersonation #5285

qiujian16 · 2025-05-07T02:49:08Z

One-line PR description: Introduce authorization rules to restrict impersonating on specified resource with specified actions.

Issue link: Constrained Impersonation #5284

Other comments:

Signed-off-by: Jian Qiu <[email protected]>

k8s-ci-robot · 2025-05-07T02:49:17Z

Hi @qiujian16. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

liggitt · 2025-05-07T19:57:32Z

cc @ahmedtd @vinayakankugoyal

aramase · 2025-05-12T16:14:38Z

/assign enj

lmktfy · 2025-05-13T23:04:50Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+should be approved by the remaining approvers and/or the owning SIG (or
+SIG Architecture for cross-cutting KEPs).
+-->
+# KEP-NNNN: Limit Impersonate Permission


nit: use the actual number here

lmktfy · 2025-05-13T23:05:25Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+
+## Summary
+
+This is to add additional access control over the existing impersonation action. An impersonator


Is this a change to RBAC? If so, the summary should mention RBAC.

This does not change RBAC in any way.

lmktfy · 2025-05-13T23:18:19Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+-->
+
+## Alternatives
+


A couple of alternative ideas come to mind:

• permission boundaries, AWS style

In that story, a principal is constrained and cannot perform some actions. Done right - which isn't trivial - the principal can create new principals, grant permission to those principals, and impersonate (act as) those principals, but only within a bounding set of allowed actions.

CEL. The constraint on impersonation could be done through an access-granting mechanism that evaluates an expression before permitting it. Clients would explicitly declare which access rule they intend to rely on.

For example, the SubjectAccessReview might look like:

{ "apiVersion": "authorization.k8s.io/v1beta1", "kind": "SubjectAccessReview", "spec": { "resourceAttributes": { "namespace": "default", "verb": "get", "group": "example.org", "resource": "something" }, "accessRule": { "kind": "ClusterAccessRule", "group version": "example.org/v1", "name": "elevation-of-privilege" }, "user": "lmktfy", "group": [] ] } }

In this story, the ClusterRoleBinding allows impersonate only with a particular Access Rule name (similar, or identical to, the existing resourceNames mechanism).

However an access rule might day you can impersonate that principal but only to perform deletes.

We file alternatives we think of, so long as they are reasonable, even when we plan to pick the original proposal.

I do not see us expanding SAR / authz for this KEP. The approach described in the KEP is far simpler.

added this as an alternative.

enj

First pass.

enj · 2025-05-08T13:48:25Z

keps/sig-auth/5284-limit-impersonate-permission/kep.yaml

Please complete this.

enj · 2025-05-08T13:49:29Z

keps/sig-auth/5284-limit-impersonate-permission/kep.yaml

+# The following PRR answers are required at alpha release
+# List the feature gate name and the components for which it must be enabled
+feature-gates:
+  - name: ImpersonateAccessControl


This feature gate name feels too vague. Some ideas:

ScopedImpersonation

ConstrainedImpersonation

LimitedImpersonation

ConditionalImpersonation

I prefer ConstrainedImpersonation :)

enj · 2025-05-08T13:50:27Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

Please update all examples to include binding(s) in addition to the role.

enj · 2025-05-08T13:52:11Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+- `impersonate:scheduled-node` that limits the impersonator to impersonate the node the
+impersonator is running on. The resource must be `nodes`.
+
+For the imperonsonator, two permissions will be required:


Include the exact YAML of the subject access review that will be sent to the authorizer chain.

enj · 2025-05-08T15:34:56Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+This proposal is to introduce additional permissions for impersonation, so that any 
+impersonator can impersonate in a more restricted way.


I assume this would be an opt-in feature such that existing impersonation flows keep working as-is. If so, highlight that in the Goals section.

enj · 2025-05-12T15:06:02Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+Some concerns on using this approch:
+- impersonating on any APIGroup is hard to describe.
+- core APIGroup has to be specially treated.
+- the APIGroup might be too long for a CRD, e.g. cluster.x-k8s.io.imperonsation.k8s.io


While I am fine with the verb based approach described in this KEP, I don't really find any of these concerns to be compelling. At the end of the day we are just talking about different string based options here.

I would say the most compelling reason is that the existing impersonation flows are verb based, so making the new flow verb based as well feels more consistent.

makes sense, updated

enj · 2025-05-14T16:47:41Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+- `impersonate:user` limits the impersonator to impersonate users with 
+certain names/groups/userextras. The resources must be `users`/`groups`/`userextras`.
+The resource names must be user names, group names or values in the user extras accoringly.
+- `impersonate:scheduled-node` that limits the impersonator to impersonate the node the


Would be good to describe how the workload learns the node that it is scheduled on.

added more details in Design Details section

enj · 2025-05-14T16:49:57Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+- `impersonate:user` limits the impersonator to impersonate users with 
+certain names/groups/userextras. The resources must be `users`/`groups`/`userextras`.
+The resource names must be user names, group names or values in the user extras accoringly.
+- `impersonate:scheduled-node` that limits the impersonator to impersonate the node the


Include the exact set of impersonation headers the workload must set for the node case.

added more details in Design Details section

enj · 2025-05-14T16:50:52Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+
+## Summary
+
+This is to add additional access control over the existing impersonation action. An impersonator


This does not change RBAC in any way.

enj · 2025-05-14T16:52:42Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+-->
+
+## Alternatives
+


I do not see us expanding SAR / authz for this KEP. The approach described in the KEP is far simpler.

k8s-ci-robot · 2025-05-14T16:53:05Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: qiujian16
Once this PR has been reviewed and has the lgtm label, please ask for approval from enj. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

keps/sig-auth/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

lmktfy · 2025-05-14T17:58:35Z

keps/sig-auth/5284-limit-impersonate-permission/README.md

+
+## Proposal
+
+Introduce a set of verbs with prefix of `impersonate-on:`, e.g. `impersonate-on:create` and


Overall, I am wary of making verbs that you have to parse.

For example, the impersonate:user verb sets the scene for other verbs, such as list:metadata-only or proxy:port:443.

We should we sure what direction of travel we want if we are to establish this kind of precedent, and clearly indicate why the alternatives are overall less viable.

Signed-off-by: Jian Qiu <[email protected]>

lmktfy · 2025-05-16T07:57:30Z

keps/sig-auth/5284-constrained-impersonation/README.md

+- `impersonate:scheduled-node` that limits the impersonator to impersonate the node the 
+impersonator is running on. The resources must be `nodes`.
+
+For the imperonsonator, two permissions will be required:


Suggested change

For the imperonsonator, two permissions will be required:

For clusters that use RBAC authz mode, two permissions will be required for impersonation. For example:

lmktfy · 2025-05-16T08:00:35Z

keps/sig-auth/5284-constrained-impersonation/README.md

+- a search in the Kubernetes bug triage tool (https://storage.googleapis.com/k8s-triage/index.html)
+-->
+
+- SAR check on impersonate user with permission:


Suggested change

- SAR check on impersonate user with permission:

- SubjectAccessReview check on impersonating user. For RBAC authz mode, this might look like:

lmktfy · 2025-05-16T08:02:43Z

keps/sig-auth/5284-constrained-impersonation/README.md

+  name: impersonate-user
+rules:
+- apiGroups:
+  - auhtentications.k8s.io


lmktfy · 2025-05-16T08:03:16Z

keps/sig-auth/5284-constrained-impersonation/README.md

+  - The impersonator cannot impersonate on updating nodes
+
+- SAR check on impersonate scheduled node with permissions. The impersonator has the
+user extra info of `"authentication.kubernetes.io/node-name": "node1"`


Can any client provide this? What protects against abuse?

The important examples here are actually:
• a compromised node
• an attacker aiming to elevate privileges by impersonating a node

If an attacker intends to elevate privileges by impersonating a node, it needs to have an user extra "authentication.kubernetes.io/node-name": "someNode" in the userInfo, and it needs to have both permissions with verbs "impersonated:scheduled-nodes" and "impersonated:someVerb".

lmktfy · 2025-05-16T08:05:27Z

keps/sig-auth/5284-constrained-impersonation/README.md

+-->
+
+On upgrade to a version that enables the feature
+* the previous inpersonator with impersonate permission will still work, but it is highly


lmktfy · 2025-05-16T08:10:50Z

keps/sig-auth/5284-constrained-impersonation/README.md

+It is almost the same as the verb based approach in the proposal. However, since existing impersonation flows are
+verb based, so making the new flow verb based as well feels more consistent.
+
+### Check permission intersaction of impersonator and target user


lmktfy · 2025-05-16T08:11:33Z

keps/sig-auth/5284-constrained-impersonation/README.md

+in the proposed apporch, the impersonator's permission is clearer that it can only perform
+the action when impersonating.
+
+### Expand RBAC/SAR


If the cluster does not use RBAC, is this alternative still feasible?

lmktfy · 2025-05-16T08:12:27Z

keps/sig-auth/5284-constrained-impersonation/README.md

+      "name": "elevation-of-privilege"
+    },
+    "user": "lmktfy",
+    "group": []


Try not to use real usernames in examples (people sometimes copy them verbatim!)

lmktfy · 2025-05-16T08:13:15Z

keps/sig-auth/5284-constrained-impersonation/kep.yaml

+
+# The following PRR answers are required at beta release
+metrics:
+  - my_feature_metric


(placeholder - please change)

lmktfy · 2025-05-16T08:17:25Z

keps/sig-auth/5284-constrained-impersonation/README.md

+of impersonated user and the requester.
+
+## Proposal
+


If a cluster had its own authn and splits principals into ServiceAccounts, ProjectRoles (not K8s RBAC) and ProjectUsers: does this mechanism prevent things working for that design?

We should not (almost must not) assume that clusters rely on K8s RBAC.

I do not think it prevent things working. This still work if it is not k8s RBAC, the external authorizer will receive subject access review call with the specified verb.

Signed-off-by: Jian Qiu <[email protected]>

stealthybox · 2025-05-20T22:52:10Z

keps/sig-auth/5284-constrained-impersonation/README.md

+- `impersonate:user-info` limits the impersonator to impersonate users with 
+certain names/groups/userextras. The resources must be `users`/`groups`/`userextras`/`uids`.
+The resource names must be user names, group names or values in the user extras accoringly.
+- `impersonate:serviceaccount` that limits the impersonator to impersonate the serviceaccount with
+the certain name/namespace. The resources must be `serviceaccounts`.


Does impersonate:serviceaccount for some resourceName imply access to the the system:serviceaccounts: groups associated with those serviceaccounts as well?
Does this verb behave differently than the current impersonate verb when serviceaccounts is supplied as the resource?

It is the same as impersonate verb with serviceaccount as the resource, but it will require additional impersonate-on:{action} verb. The reason that not to reuse the original impersonate verb is to make it unchanged for backward compatible.

Limit impersonate permissions

d63ca70

Signed-off-by: Jian Qiu <[email protected]>

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label May 7, 2025

k8s-ci-robot requested review from deads2k and enj May 7, 2025 02:49

enj added this to SIG Auth May 7, 2025

enj moved this to Needs Triage in SIG Auth May 7, 2025

liggitt mentioned this pull request May 7, 2025

Constrained Impersonation #5284

Open

4 tasks

aramase moved this from Needs Triage to In Review in SIG Auth May 12, 2025

k8s-ci-robot assigned enj May 12, 2025

lmktfy reviewed May 13, 2025

View reviewed changes

enj requested changes May 14, 2025

View reviewed changes

github-project-automation bot moved this from In Review to Changes Requested in SIG Auth May 14, 2025

lmktfy reviewed May 14, 2025

View reviewed changes

Resolve enj and lmktfy's comment

d80baa4

Signed-off-by: Jian Qiu <[email protected]>

qiujian16 changed the title ~~KEP-5284: Limit impersonate permissions~~ KEP-5284: Constrained Impersonation May 16, 2025

lmktfy reviewed May 16, 2025

View reviewed changes

Resolve lmktfy's comment

f19fe4d

Signed-off-by: Jian Qiu <[email protected]>

stealthybox reviewed May 20, 2025

View reviewed changes


		## Summary

		This is to add additional access control over the existing impersonation action. An impersonator

		This proposal is to introduce additional permissions for impersonation, so that any
		impersonator can impersonate in a more restricted way.


		## Proposal

		Introduce a set of verbs with prefix of `impersonate-on:`, e.g. `impersonate-on:create` and

	For the imperonsonator, two permissions will be required:
	For clusters that use RBAC authz mode, two permissions will be required for impersonation. For example:

	- SAR check on impersonate user with permission:
	- SubjectAccessReview check on impersonating user. For RBAC authz mode, this might look like:

		-->

		## Alternatives

		-->

		## Alternatives

KEP-5284: Constrained Impersonation #5285

Are you sure you want to change the base?

KEP-5284: Constrained Impersonation #5285

Uh oh!

Conversation

qiujian16 commented May 7, 2025

Uh oh!

k8s-ci-robot commented May 7, 2025

Uh oh!

liggitt commented May 7, 2025

Uh oh!

aramase commented May 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

enj left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

k8s-ci-robot commented May 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!