---- On Wed, 29 Jun 2022 05:12:29 -0500 Sean Mooney <smooney@redhat.com> wrote ---
On Tue, 2022-06-28 at 15:15 -0500, Ghanshyam Mann wrote:
Hello Everyone,
We have received a good amount of feedback from the operator. In ops meetup Berlin as well as from KDDI (Japanese telco). I have summarized the feedback in etherpad[1]. From feedback, it is clear that 'scope' enable will break heat so do NFV operators and even other operators are also confused with the 'scope' concept. Most operators want legacy admin to work as it is (able to do everything in deployment).
We discussed this feedback in the policy popup meeting[2] and based on feedback and our outstanding issue of 'scope enable break heat create_stack', we decided to postpone the `scope` implementation. That is the way forward to at least implement the project personas which is asked by many operators. Basically the below direction:
* Finish delivering project personas This is to introduce the `member` and `reader` roles to operate things within their project. By default, any other project role like `foo` will not be allowed to do anything in the project.
* Postpone the `scope` implementation for later Some standalone services like Ironic can still have the `scope` implementation as long as it does not break any cross-service communication. Other services will make sure they work for project scope personas even with enforce_scope enabled.
We are not saying 'scope' things are not good or we will never do it but at the same time, I am not sure when we will do it in future. At least moving this giant goal to focus on the project personas first will help us to deliver one good feature (project personas) for operators otherwise we are stuck.
Complete details about the reason to postpone the 'scope' implementation and projects persons detail are proposed in community-wide goal, please review there.
- https://review.opendev.org/c/openstack/governance/+/847418 ack ill be sure to read that. just on the topic of scope i do think there is a better way forward then useing scope to have a similar capablity but more flexible and user friendly.
i mentioned this on another thread but if we had the abiltiy in keystoen to scope roles to service endpoint that woudl allwo us to achive much of the usecase scope was intended for.
e.g. grant the neutron user the admin role scoped to just the nova project so it can call the external events api. once we have the service role we would only grant service role scoped to nova instead of admin
similarly we coudl do the same for nova so it has the servivce role on neutron to do port bidnign but no elevated permeission on say keystone or horizon.
that woudl allow operators to also subdevice there permissiosn so they could grant admin on nova to the cloud operator to define flavors but no admin rights on say cinder which might be manged by a differnt storage admin user.
for a netowrk monitoring systems you could for instnace grant it the reader role on a set of project but scope that role to just neutron apis.
if we have the ablity to scope roles by keystone service cataloge entry and layer that with our ablity to assign rules ot user/groups/application credentials on a per project basis it woudl be a very flexiable sytem to reduce the scope of acces granted to applciation.
going one step beyond that instead of haveing system scope we can have a system role that will be delegate the ablity to do the things we planned to make system scoped like creating flavors.
admin would be the supper set of system, service, member and reader with extra capablity to work aroucess all tenant as we have today if desired.
i honestly think that with a system and serivce roles and the ablity to scope roles to service endpoitn we can do everything we wanted to do with system scope is a much simpler way that is more flexible in the long run.
The key feedback from operators is that they only care about the admin being able to do things in complete deployment and reader roles. I am not sure splitting admin per service will be welcome compared to scope. Also, heat and NFV users will face the same issue they are currently facing with scope enable, they will require their user token to have an admin role to all the services they need which are mostly many. Anyways, let's focus on one thing at a time and as per this goal project reader is our priority otherwise this most needed role by the operator keep getting postponed because we want to solve many things together. -gmann
[1] https://etherpad.opendev.org/p/rbac-operator-feedback#L45 [2] https://etherpad.opendev.org/p/rbac-zed-ptg#L171