search

kubernetes / enhancements

Enhancements tracking repo for Kubernetes
Apache License 2.0
3.45k stars 1.49k forks source link

Support resource/* Pattern Matching in RBAC Policy Rules #4961

Closed changhyuni closed 6 days ago

changhyuni commented 1 week ago

Enhancement Description

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

changhyuni commented 1 week ago

/assign @changhyuni

changhyuni commented 1 week ago

/sig auth

sftim commented 1 week ago

/sig security likely to be interested here too

liggitt commented 6 days ago

This is intentionally not supported. Creating a role which allows pods/* grants access to all future subresources that are added to pod as well. Just because current subresources are acceptable to grant does not mean future ones would be. Enumerating the subresources you want to grant is safer and more future proof

enj commented 6 days ago

Closing per https://github.com/kubernetes/enhancements/issues/4961#issuecomment-2478982214

/close

k8s-ci-robot commented 6 days ago

@enj: Closing this issue.

In response to [this](https://github.com/kubernetes/enhancements/issues/4961#issuecomment-2479261501): >Closing per https://github.com/kubernetes/enhancements/issues/4961#issuecomment-2478982214 > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
changhyuni commented 5 days ago

@liggitt @enj Could we discuss this a bit further? I’m curious to understand more about why supporting pods/ would be difficult, especially since is already allowed. People often use to avoid listing numerous subresources, and having a pods/ option could enable slightly more explicit and secure configurations. Of course, it ultimately depends on the user's choice.

enj commented 5 days ago

People often use to avoid listing numerous subresources, and having a pods/ option could enable slightly more explicit and secure configurations.

We expect users to explicitly enumerate the sub resources they want to use. Wildcards are expected to only be used when the actual permission cannot be represented in any other way. For example, the GC controller needs to be able to delete any resource (including resources that aren't known in advance), hence its RBAC uses a wildcard. It is not a convenience feature to save some typing.

changhyuni commented 5 days ago

We expect users to explicitly enumerate the sub resources they want to use. Wildcards are expected to only be used when the actual permission cannot be represented in any other way. For example, the GC controller needs to be able to delete any resource (including resources that aren't known in advance), hence its RBAC uses a wildcard. It is not a convenience feature to save some typing.

Thank you for your reply. I agree with your opinion that should indeed be used only when absolutely necessary. However, it's already possible to use freely in any API group; it's not restricted to specific cases like the GC Controller. I don't think the and /subresource features were developed solely for special situations (if they were, they should be enforced to be used only in those cases). Personally, I thought the development team considered a balance between security and usability when creating these features. In the same vein, supporting subresource aliases is similar.

sftim commented 4 days ago

Bear in mind that the Kubernetes process for enhancements recommends an initial discussion before opening the tracking issue.

If we'd had that discussion, I'm afraid this would have been rejected before reaching GitHub.

@changhyuni you are welcome to discuss further on Slack.