Open Stack

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.
> 
> [1] https://etherpad.opendev.org/p/rbac-operator-feedback#L45
> [2] https://etherpad.opendev.org/p/rbac-zed-ptg#L171
> 
>