KEP-4601: authorize with field and label selectors

[deads2k]

Still in progress, but the bones are here.

/assign @liggitt
/assign @micahhausler
/cc @enj

• One-line PR description:

• Issue link:

• Other comments:

[liggitt]

update looks pretty good to me, a couple more questions / some maybe-stale docs

[luxas]

Thanks @deads2k for writing this!

Very excited to get this going, happy to help out on some of the implementation as well 👍

I'm concerned about the sprawl of having two almost-identical representations, but not really in the SAR body. I'm all for making good, canonical client-/server-side libraries instead that wrap the complexity, and contain it there. Just such a thing as anding all requirements together into something that is equivalent but easily comparable/understandable is non-trivial unless one thinks a little bit deeper about the set theoretics.

[liggitt]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, liggitt

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

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/prod-readiness/OWNERS [deads2k]
• keps/sig-auth/OWNERS [deads2k,liggitt]

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

[mtaufen]

Exploring this further: If authorizers could inject label selectors, instead of just checking them, and if label selectors were supported on ALL verbs, then would it essentially become possible to write label-based RBAC, without client changes?

I think at least one remaining issue would be list/watch consistency across RBAC policy changes, as it's dangerous for that to be transparent to clients since it would be similar to "missed" events, and could desync informers. It would open up some really interesting policy use cases if we can solve that problem though.

[liggitt]

If authorizers could inject label selectors

I'm not sure I understand this... authorizers do not modify requests, they authorize attributes of the request... what you're describing does not sound like an authorizer but a mediating client or proxy of some kind