/triage accepted
/sig auth
cc @liggitt @deads2k @munnerz

resourceNames don't support partial globs, so example.com/* is a different permission than example.com/foo, and is considered escalating

/remove-kind bug

I understand that, but since the authorizer for CSRs allows example.foo/* to approve for all signers under that domain, as a user I expect that to work...

As in, if the system:serviceaccount:csr-test:delegator service account were to attempt approving the CSR for example.foo/specific, it would be allowed - it is authorized. That's why it's a bug that the escalation check thinks that it's not authorized.

The CSR admission plugin does two subject access review checks to check for the wildcard permission and the specific permission.

example.com/* covering example.com/specific is a semantic specific to the CSR admission plugin, it is not part of the authorization API or RBAC.

Explaining for people wondering why, "can't you just make * glob for name?". Because our authorizer doesn't interpret names or require referenced resources to exist, it's entirely possible that some entity is actually using "" for "something/" for a meaning we don't control. The only fully safe way to make a change is introduce a new field.

I think the point is less that the generic RBAC implementation of escalation detection should be different - or that it should honor any generic admission plugin or any custom verb, etc, and that if we choose to ship Kubernetes with this custom logic around CSRs, it might be beneficial if that logic were more fully supported / more self-consistent and had fewer rough edges.

However, I know better than to try convince you two that "just this one time" we need a one-off codepath to support something ;)

Consider the issue a documentation of the limitation.

After some more conversation @deads2k showed me every way that an actor with no signer name restriction on CSR approval could abuse the system to get CSR creation rights (given that the actor has other privileges), since those are not super locked down, and then they'd be able to create and self-approve a CSR for system:master credentials. @liggitt maybe you'd be open to a feature request for something in this space? Seems like we should be able to do better here.

While we try to figure out a better solution in this space, you could try restricting what such an actor could do via a CEL admission policy. It is not that different from letting users create pods but then preventing them from creating privileged pods.

How we might solve this: CEL authz where one rule definition covers both authz and the admission stage. Not for the faint hearted, I think.

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

If you want to either:

• document how to do this (eg ValidatingAdmissionPolicy?)
• file an issue asking that somebody document how to do this (eg ValidatingAdmissionPolicy?)
• propose a blog article about how to delegate specific CSR approval / signing permissions

then any of those would be champion, @stevekuznetsov

@sftim would you want to see something more broadly scoped than a blog that answers the question of "how do you give some identity the ability to delegate CSR approval and signing using VAP"? I can certainly write something like that.

@stevekuznetsov that sounds ideal