[tc][policy][ptl][operator] OpenSatck RBAC goal is to focus on project personas first (postpone the 'scope' implementation)

Michael Johnson johnsomor at gmail.com
Wed Jun 29 14:32:57 UTC 2022


I agree. This was more aligned to what John Garbutt and I were
advocating for back in 2017 and was implemented in Octavia[1] in Pike.

The related proposed spec:
https://review.opendev.org/c/openstack/nova-specs/+/427872

Michael

[1] https://docs.openstack.org/octavia/latest/configuration/policy.html#octavia-advanced-role-based-access-control-rbac

On Wed, Jun 29, 2022 at 3:26 AM Sean Mooney <smooney at 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.
> >
> > [1] https://etherpad.opendev.org/p/rbac-operator-feedback#L45
> > [2] https://etherpad.opendev.org/p/rbac-zed-ptg#L171
> >
> >
>
>



More information about the openstack-discuss mailing list