kubernetes
KEP-4601: authorize with field and label selectors
Still in progress, but the bones are here.
/assign @liggitt /assign @micahhausler /cc @enj
- One-line PR description:
- Issue link:
- Other comments:
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: deads2k
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~keps/prod-readiness/OWNERS~~ [deads2k]
- ~~keps/sig-auth/OWNERS~~ [deads2k]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
@deads2k: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:
| Test name | Commit | Details | Required | Rerun command |
|---|---|---|---|---|
| pull-enhancements-verify | 936e9146520ee12ef2f29787f1745f1de5829068 | link | true | /test pull-enhancements-verify |
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.
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. I understand the commands that are listed here.
[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
- ~~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
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.
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