[all][operator][policy] Operator feedback on 'Consistent and Secure RBAC" (new design for RBAC)
Hello Everyone,
As you might know, we are redesigning the OpenStack default RBAC. The new design target two things:
1. 'new defaults (reader role)' 2. "Scope" concept
It is hard to explain the details in email but the below doc is a good place to start understanding this: - https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba...
We as a community think 1st target (reader role) is a good thing to do and it will definitely be useful in many cases.
But we need feedback on the "Scope" concept. To understand what it is and how it can impact your existing use case/deployment, please ref the documentation mentioned in the etherpad[1] (if there is any question about its design/usage we are planning, feel free to reply here or contact us in #openstack-tc IRC channel).
* If you are an operator, we really need your feedback if the 'Scope' concept is a useful thing for your deployment/use-case or not.
* If you are attending events have operators also attending (for example, project operator feedback (like nova[2]), forum sessions in berlin summit, ops meetup or any local operator event), please communicate about the required feedback.
* Due to various reasons, many of us involved in RBAC work are not travelling to Berlin and we have this topic to be discussed in Berlin ops meetup[3] but we require someone knowing RBAC new design moderate this topic. Please reach out to us if you would like to help.
Central Etherpad to collect feedback (this can be used to collect from various forums/places):
* https://etherpad.opendev.org/p/rbac-operator-feedback
[1] https://etherpad.opendev.org/p/rbac-operator-feedback [2] https://etherpad.opendev.org/p/nova-berlin-meet-and-greet [3]https://etherpad.opendev.org/p/ops-meetup-berlin-2022-planning#L74
-gmann
On Tue, Jun 7, 2022 at 8:10 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:
Hello Everyone,
As you might know, we are redesigning the OpenStack default RBAC. The new design target two things:
- 'new defaults (reader role)'
- "Scope" concept
It is hard to explain the details in email but the below doc is a good place to start understanding this:
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba...
We as a community think 1st target (reader role) is a good thing to do and it will definitely be useful in many cases.
But we need feedback on the "Scope" concept. To understand what it is and how it can impact your existing use case/deployment, please ref the documentation mentioned in the etherpad[1] (if there is any question about its design/usage we are planning, feel free to reply here or contact us in #openstack-tc IRC channel).
- If you are an operator, we really need your feedback if the 'Scope'
concept is a useful thing for your deployment/use-case or not.
- If you are attending events have operators also attending (for example,
project operator feedback (like nova[2]), forum sessions in berlin summit, ops meetup or any local operator event), please communicate about the required feedback.
- Due to various reasons, many of us involved in RBAC work are not
travelling to Berlin and we have this topic to be discussed in Berlin ops meetup[3] but we require someone knowing RBAC new design moderate this topic. Please reach out to us if you would like to help.
I previously volunteered to facilitate this at the operators meet up and given others have had to drop out, I discussed it with the ops meetup leaders and will be facilitating a session with the interested operators on Friday.
I know from previous discussions I’ve had, there was quite an interest in the system level of scope access to be able to see everything across a system, so I suspect there is tons of value there, but our developer perception is obvious different if we’re questioning it at this point.
Central Etherpad to collect feedback (this can be used to collect from various forums/places):
[1] https://etherpad.opendev.org/p/rbac-operator-feedback [2] https://etherpad.opendev.org/p/nova-berlin-meet-and-greet [3]https://etherpad.opendev.org/p/ops-meetup-berlin-2022-planning#L74
-gmann
On Wed, 2022-06-08 at 07:49 +0200, Julia Kreger wrote:
On Tue, Jun 7, 2022 at 8:10 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:
Hello Everyone,
As you might know, we are redesigning the OpenStack default RBAC. The new design target two things:
- 'new defaults (reader role)'
- "Scope" concept
It is hard to explain the details in email but the below doc is a good place to start understanding this:
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba...
We as a community think 1st target (reader role) is a good thing to do and it will definitely be useful in many cases.
But we need feedback on the "Scope" concept. To understand what it is and how it can impact your existing use case/deployment, please ref the documentation mentioned in the etherpad[1] (if there is any question about its design/usage we are planning, feel free to reply here or contact us in #openstack-tc IRC channel).
- If you are an operator, we really need your feedback if the 'Scope'
concept is a useful thing for your deployment/use-case or not.
- If you are attending events have operators also attending (for example,
project operator feedback (like nova[2]), forum sessions in berlin summit, ops meetup or any local operator event), please communicate about the required feedback.
- Due to various reasons, many of us involved in RBAC work are not
travelling to Berlin and we have this topic to be discussed in Berlin ops meetup[3] but we require someone knowing RBAC new design moderate this topic. Please reach out to us if you would like to help.
I previously volunteered to facilitate this at the operators meet up and given others have had to drop out, I discussed it with the ops meetup leaders and will be facilitating a session with the interested operators on Friday.
I know from previous discussions I’ve had, there was quite an interest in the system level of scope access to be able to see everything across a system, so I suspect there is tons of value there, but our developer perception is obvious different if we’re questioning it at this point.
the system level of scope does not allow you to see everything across the system it only allows you to see the non project related resouces
so you can see the flavors and host aggreates but not the instances as instances are project scoped. and project scoped resouces like ports, instances, images and volumes cannot be accessed with a system scope token if you enabel scope enforcement.
that is one of the things we want to get clarity on form operators. is the disticntion between system level resouces and project level resouces useful.
Central Etherpad to collect feedback (this can be used to collect from various forums/places):
[1] https://etherpad.opendev.org/p/rbac-operator-feedback [2] https://etherpad.opendev.org/p/nova-berlin-meet-and-greet [3]https://etherpad.opendev.org/p/ops-meetup-berlin-2022-planning#L74
-gmann
the system level of scope does not allow you to see everything across the system it only allows you to see the non project related resouces
so you can see the flavors and host aggreates but not the instances as instances are project scoped. and project scoped resouces like ports, instances, images and volumes cannot be accessed with a system scope token if you enabel scope enforcement.
that is one of the things we want to get clarity on form operators. is the disticntion between system level resouces and project level resouces useful.
Yep, exactly this. Given the amount of breakage it brings for things like Heat and Tacker, as well as the potential workflow annoyance for human admins, I really want to measure whether any operators see a benefit here. The persona roles, things like a standardized service role, and getting out of this current situation of having two sets of defaults are priorities for me.
--Dan
Is that Nova's interpretation, specifically the delineation that non-project owned should only be viewable by system, or was system scope changed at some point? I interpreted it differently, but haven't circled back recently. I guess interpretation and evolution in specific pockets after initial implementation work started ultimately resulted in different perceptions.
I'll make sure operators are aware there may be significant nuances and perception differences since they are using their own etherpads and their own communications flow. i.e. we're unlikely to see many find/use our own etherpads as they have their own. And yes, this is a problem, but it is a higher level community/communications feedback issue under active discussion.
Granted, I get that the system scope ideas were breaking for some projects in specific use patterns since not everything would be the same nor possible (which is actually a good thing, context of use and all), but it was in theory perfect for a lot of the external audit tooling use cases which arise in so many different ways.
Anyway, off to the next $thing with my scattered brain.
On Wed, Jun 8, 2022 at 6:53 AM Dan Smith dms@danplanet.com wrote:
the system level of scope does not allow you to see everything across the system it only allows you to see the non project related resouces
so you can see the flavors and host aggreates but not the instances as instances are project scoped. and project scoped resouces like ports, instances, images and volumes cannot be accessed with a system scope token if you enabel scope enforcement.
that is one of the things we want to get clarity on form operators. is the disticntion between system level resouces and project level resouces useful.
Yep, exactly this. Given the amount of breakage it brings for things like Heat and Tacker, as well as the potential workflow annoyance for human admins, I really want to measure whether any operators see a benefit here. The persona roles, things like a standardized service role, and getting out of this current situation of having two sets of defaults are priorities for me.
--Dan
Julia Kreger juliaashleykreger@gmail.com writes:
Is that Nova's interpretation, specifically the delineation that non-project owned should only be viewable by system, or was system scope changed at some point? I interpreted it differently, but haven't circled back recently. I guess interpretation and evolution in specific pockets after initial implementation work started ultimately resulted in different perceptions.
Nope, not a Nova thing. Here's the relevant course correction from two PTGs ago:
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba...
Mohammed is going to be there and primed to discuss this as well. I think he's pretty well caught up on the current state of things. Having your experience with what it means in Ironic, as well as his context from the sticky implementation issues in the other projects should mean we have pretty good coverage.
Thanks!
--Dan
---- On Wed, 08 Jun 2022 09:43:59 -0500 Dan Smith dms@danplanet.com wrote ----
Julia Kreger juliaashleykreger@gmail.com writes:
Is that Nova's interpretation, specifically the delineation that non-project owned should only be viewable by system, or was system scope changed at some point? I interpreted it differently, but haven't circled back recently. I guess interpretation and evolution in specific pockets after initial implementation work started ultimately resulted in different perceptions.
Nope, not a Nova thing. Here's the relevant course correction from two PTGs ago:
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba...
Mohammed is going to be there and primed to discuss this as well. I think he's pretty well caught up on the current state of things. Having your experience with what it means in Ironic, as well as his context from the sticky implementation issues in the other projects should mean we have pretty good coverage.
Yes. and it is more than just a single service use case especially when heat discussion[1] came up and the scope complexity for heat/NVF users is brought up. We want to make sure by introducing scope at the service level which is all good for us does not break others users/tooling like heat, tacker, and deployment projects.
We discussed one solution for heat[2] which is sent on ML for feedback not still now response and that is why operators' feedback is critical before we try to implement something that can break them.
[1] https://etherpad.opendev.org/p/rbac-zed-ptg#L104 [2] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028490.html
-gmann
Thanks!
--Dan
On Wed, Jun 8, 2022 at 9:50 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 08 Jun 2022 09:43:59 -0500 Dan Smith dms@danplanet.com wrote ----
Julia Kreger juliaashleykreger@gmail.com writes:
Is that Nova's interpretation, specifically the delineation that non-project owned should only be viewable by system, or was system scope changed at some point? I interpreted it differently, but haven't circled back recently. I guess interpretation and evolution in specific pockets after initial implementation work started ultimately resulted in different perceptions.
Nope, not a Nova thing. Here's the relevant course correction from two PTGs ago:
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba...
Thanks Sean! Now I'm remembering! This is what happens when we implement things and then change directions and already have some variety of models. I guess I mentally dropped some of the context due to this after reading it since it was already "done" and committed from my perspective. Thanks for the refresher!
Mohammed is going to be there and primed to discuss this as well. I think he's pretty well caught up on the current state of things. Having your experience with what it means in Ironic, as well as his context from the sticky implementation issues in the other projects should mean we have pretty good coverage.
Yes. and it is more than just a single service use case especially when heat discussion[1] came up and the scope complexity for heat/NVF users is brought up. We want to make sure by introducing scope at the service level which is all good for us does not break others users/tooling like heat, tacker, and deployment projects.
We discussed one solution for heat[2] which is sent on ML for feedback not still now response and that is why operators' feedback is critical before we try to implement something that can break them.
Thanks! I think we will try to remember to bring this up, but we also need to let the operators drive based upon their wants and needs. Operators tend to want to focus on the nuts and bolts of older software, so hopefully we will be able to move the discussion forward. There is entirely the possibility they just won't want to discuss it because it is well over the horizon for them.
Semi-on topic, but also on topic to the base different topic: How many people would be interested in actually trying to meet up with operators on some semi-regular basis? Having a past operations background would be a major bonus point because the same words would be able to be coalesced far faster. Additionally, travel? How far? etc? I'm feeling like we need to build a "bridging" group of some sort. There are a ton of threads I'm on on trying to help bridge some of these communication gaps right now.
[1] https://etherpad.opendev.org/p/rbac-zed-ptg#L104 [2] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028490.html
-gmann
Thanks!
--Dan
On Wed, 2022-06-08 at 07:19 -0700, Julia Kreger wrote:
Is that Nova's interpretation, specifically the delineation that non-project owned should only be viewable by system, or was system scope changed at some point?
no its not just the nova interpreation. there was some differnt view in differnt porjects but we did an openstack wide reset on this in yoga and on the defintions of the personas when it became apprent we coudl not proceed with the previous approch.
I interpreted it differently, but haven't circled back recently. I guess interpretation and evolution in specific pockets after initial implementation work started ultimately resulted in different perceptions.
I'll make sure operators are aware there may be significant nuances and perception differences since they are using their own etherpads and their own communications flow. i.e. we're unlikely to see many find/use our own etherpads as they have their own. And yes, this is a problem, but it is a higher level community/communications feedback issue under active discussion.
well it was under active discussion for a few cycle both at the ptgs and mailing lists, and common understaind was codeified as part of a comunity wide goal https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... with pahses agree to be implemnted across all project based on the updated common understanding of the personas and definitons to ensure that seperate interpreation and perspective nolonger differed.
the direction change and rational are documend in the goal document https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba...
with the high level roadmap cpature in teh pahse 1,2 and 3 defintions.
but in general we woudl like to get feedback from operatros if what is being propsoed in that document is useful. As dan noted the scope enforcment aspect is proving a challange for higher level porject like heat and tacker to support. the is more agreement on the usfullnes of a standard reader role, service role and perhaps manager role as thos standarised role dont really break exising usage but scope enforcement is a big change.
so the dicusion of RBAC is not finalised but a direction has been chosen and there is a certin amount of moment behind it now. parts of the design can still change an evlonve but other parts are more concrate like the reader role.
Granted, I get that the system scope ideas were breaking for some projects in specific use patterns since not everything would be the same nor possible (which is actually a good thing, context of use and all), but it was in theory perfect for a lot of the external audit tooling use cases which arise in so many different ways.
Anyway, off to the next $thing with my scattered brain.
On Wed, Jun 8, 2022 at 6:53 AM Dan Smith dms@danplanet.com wrote:
the system level of scope does not allow you to see everything across the system it only allows you to see the non project related resouces
so you can see the flavors and host aggreates but not the instances as instances are project scoped. and project scoped resouces like ports, instances, images and volumes cannot be accessed with a system scope token if you enabel scope enforcement.
that is one of the things we want to get clarity on form operators. is the disticntion between system level resouces and project level resouces useful.
Yep, exactly this. Given the amount of breakage it brings for things like Heat and Tacker, as well as the potential workflow annoyance for human admins, I really want to measure whether any operators see a benefit here. The persona roles, things like a standardized service role, and getting out of this current situation of having two sets of defaults are priorities for me.
--Dan
---- On Wed, 08 Jun 2022 09:48:04 -0500 Sean Mooney smooney@redhat.com wrote ----
On Wed, 2022-06-08 at 07:19 -0700, Julia Kreger wrote:
Is that Nova's interpretation, specifically the delineation that non-project owned should only be viewable by system, or was system scope changed at some point?
no its not just the nova interpreation. there was some differnt view in differnt porjects but we did an openstack wide reset on this in yoga and on the defintions of the personas when it became apprent we coudl not proceed with the previous approch.
I interpreted it differently, but haven't circled back recently. I guess interpretation and evolution in specific pockets after initial implementation work started ultimately resulted in different perceptions.
I'll make sure operators are aware there may be significant nuances and perception differences since they are using their own etherpads and their own communications flow. i.e. we're unlikely to see many find/use our own etherpads as they have their own. And yes, this is a problem, but it is a higher level community/communications feedback issue under active discussion.
well it was under active discussion for a few cycle both at the ptgs and mailing lists, and common understaind was codeified as part of a comunity wide goal https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... with pahses agree to be implemnted across all project based on the updated common understanding of the personas and definitons to ensure that seperate interpreation and perspective nolonger differed.
the direction change and rational are documend in the goal document https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba...
with the high level roadmap cpature in teh pahse 1,2 and 3 defintions.
but in general we woudl like to get feedback from operatros if what is being propsoed in that document is useful. As dan noted the scope enforcment aspect is proving a challange for higher level porject like heat and tacker to support. the is more agreement on the usfullnes of a standard reader role, service role and perhaps manager role as thos standarised role dont really break exising usage but scope enforcement is a big change.
so the dicusion of RBAC is not finalised but a direction has been chosen and there is a certin amount of moment behind it now. parts of the design can still change an evlonve but other parts are more concrate like the reader role.
True, our overall goal is to ship improvement without breaking any use case. For example, 'scope' can be good for just nova admin/users but from heat, tacker users these might be breaking change more than improvement so we want to make sure what operators think by considering all use cases.
-gmann
Granted, I get that the system scope ideas were breaking for some projects in specific use patterns since not everything would be the same nor possible (which is actually a good thing, context of use and all), but it was in theory perfect for a lot of the external audit tooling use cases which arise in so many different ways.
Anyway, off to the next $thing with my scattered brain.
On Wed, Jun 8, 2022 at 6:53 AM Dan Smith dms@danplanet.com wrote:
the system level of scope does not allow you to see everything across the system it only allows you to see the non project related resouces
so you can see the flavors and host aggreates but not the instances as instances are project scoped. and project scoped resouces like ports, instances, images and volumes cannot be accessed with a system scope token if you enabel scope enforcement.
that is one of the things we want to get clarity on form operators. is the disticntion between system level resouces and project level resouces useful.
Yep, exactly this. Given the amount of breakage it brings for things like Heat and Tacker, as well as the potential workflow annoyance for human admins, I really want to measure whether any operators see a benefit here. The persona roles, things like a standardized service role, and getting out of this current situation of having two sets of defaults are priorities for me.
--Dan
On Wed, Jun 8, 2022 at 9:53 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 08 Jun 2022 09:48:04 -0500 Sean Mooney smooney@redhat.com wrote ----
[trim]
so the dicusion of RBAC is not finalised but a direction has been chosen and there is a certin amount of moment behind it now. parts of the design can still change an evlonve but other parts are more concrate like the reader role.
True, our overall goal is to ship improvement without breaking any use case. For example, 'scope' can be good for just nova admin/users but from heat, tacker users these might be breaking change more than improvement so we want to make sure what operators think by considering all use cases.
-gmann
So, one thought. Ironic views system scope as *critical* for our usage based upon the consensus we built before the direction change, because the system fundamentally is the owner/manager of $things. We can and likely should extend that out to project admin (granted, I suspect at least one ironic admin will reply with a strong -1 to such a change... :. ) given the direction change. We also have had some operators jump on it, but... again, entirely different models of usage/interaction given the base state. If system scope were to suddenly disappear or be completely redefined, it would be a hard break for us at this point.
Granted, I get that the system scope ideas were breaking for some projects in specific use patterns since not everything would be the same nor possible (which is actually a good thing, context of use and all), but it was in theory perfect for a lot of the external audit tooling use cases which arise in so many different ways.
Anyway, off to the next $thing with my scattered brain.
On Wed, Jun 8, 2022 at 6:53 AM Dan Smith dms@danplanet.com wrote:
the system level of scope does not allow you to see everything across the system it only allows you to see the non project related resouces
so you can see the flavors and host aggreates but not the instances as instances are project scoped. and project scoped resouces like ports, instances, images and volumes cannot be accessed with a system scope token if you enabel scope enforcement.
that is one of the things we want to get clarity on form operators. is the disticntion between system level resouces and project level resouces useful.
Yep, exactly this. Given the amount of breakage it brings for things like Heat and Tacker, as well as the potential workflow annoyance for human admins, I really want to measure whether any operators see a benefit here. The persona roles, things like a standardized service role, and getting out of this current situation of having two sets of defaults are priorities for me.
--Dan
So, one thought. Ironic views system scope as *critical* for our usage based upon the consensus we built before the direction change, because the system fundamentally is the owner/manager of $things. We can and likely should extend that out to project admin (granted, I suspect at least one ironic admin will reply with a strong -1 to such a change... :. ) given the direction change. We also have had some operators jump on it, but... again, entirely different models of usage/interaction given the base state. If system scope were to suddenly disappear or be completely redefined, it would be a hard break for us at this point.
I don't think system scope would (or could) disappear at this point, so I don't think there's much to worry about. I think it's totally reasonable to say that there are certain things that a user would never interact with directly, which are entirely system-scoped. This might be things like ironic and maybe even placement. You could also make the argument that a good chunk of keystone's API is system-only. If people are already using ironic with scopes turned on, it proves the point that it's isolated enough that it doesn't suffer from all the other problems that caused the direction change.
--Dan
On Thu, Jun 9, 2022 at 6:30 AM Dan Smith dms@danplanet.com wrote:
So, one thought. Ironic views system scope as *critical* for our usage based upon the consensus we built before the direction change, because the system fundamentally is the owner/manager of $things. We can and likely should extend that out to project admin (granted, I suspect at least one ironic admin will reply with a strong -1 to such a change... :. ) given the direction change. We also have had some operators jump on it, but... again, entirely different models of usage/interaction given the base state. If system scope were to suddenly disappear or be completely redefined, it would be a hard break for us at this point.
I don't think system scope would (or could) disappear at this point, so I don't think there's much to worry about.
Whew! That is a weight off my shoulders!
I think it's totally reasonable to say that there are certain things that a user would never interact with directly, which are entirely system-scoped. This might be things like ironic and maybe even placement. You could also make the argument that a good chunk of keystone's API is system-only.
Definitely.
If people are already using ironic with scopes turned on, it proves the point that it's isolated enough that it doesn't suffer from all the other problems that caused the direction change.
--Dan
Really, starting out as an admin-only service and then later adding multi-tenancy support which only got turned on by default with SRBAC meant we never had to deal with the can of worms that were initially encountered with system scope.
participants (4)
-
Dan Smith
-
Ghanshyam Mann
-
Julia Kreger
-
Sean Mooney