Repository navigation
[epic] Ability to configure user/group permissions to an Operator's provided APIs #383
Description
Activity
- converted this from a draft issue
on Aug 31, 2023 - changed the title
[-]Ability to configure user/group permissions to an Operator's provided APIs[/-][+][epic] Ability to configure user/group permissions to an Operator's provided APIs[/+]on Apr 4, 2024 This is not a high priority yet. This was written atleast year back and we need to examine this again to find where it fits in our priority. However we will be happy to get feedback on use-cases on this.
Will the admin/edit/view roles be retained in OLM v1? We are using these roles in OLM v0, so we still hope to use them in OLM v1
Issues go stale after 90 days of inactivity. If there is no further activity, the issue will be closed in another 30 days.
This issue has been closed due to inactivity.
I'm not seeing any additional work beyond the Brief and RFC.
I see this slack conversation: https://kubernetes.slack.com/archives/C0181L6JYQ2/p1698418131157899
But it doesn't indicate what happened; although there's a reference to Carvel that we ended up abandoning, so it likely got lost in that shuffle.It looks like we are not performing v0 role aggregation in v1, plus this approach was predicated on carvel adoption, which we also moved away from.
For now, closing this and we can re-open if we find related work.
Summary
When you install an operator with OLM v0, OLM adds the operator’s provided APIs to the admin/edit/view roles for all namespaces. This means that any user with admin, edit, or view permission in any namespace has access to the operator’s APIs, and there is no way to change this.
Users have asked for a finer-grained permissions configuration for operator APIs. In addition to continuing to support the v0 model described above, v1 gives you more flexibility with new options:
Design Docs
Task List