Open Stack

 ---- On Wed, 29 Jun 2022 13:25:11 -0500  Dmitriy Rabotyagov <noonedeadpunk at gmail.com> wrote --- 
 > FWIW, there was also discussion during the summit [1], where the idea was to create accounts that would be limited to pretty specific actions for services, when interacting with others.For example, nova can create port in neutron, but not manage security group rules. Which is definitely next step to what is being discussed here.
 > Unfortunately I lost etherpad for the forum, but main suggestion there was to join biweekly meetings or just reach Ghanshyam for further discussion, as basically this topic is more suitable for PTG rather then Summit. Not sure if anyone did reach out though.

I think you mean the 'service' role? and this etherpad https://etherpad.opendev.org/p/deprivilization-of-service-accounts ?

We have that planned for phase 2 
- https://review.opendev.org/c/openstack/governance/+/847418/5/goals/selected/consistent-and-secure-rbac.rst#503

And I have an action item to continue on Lance spec and update it once we finalized the goal documentation.

- https://review.opendev.org/c/openstack/keystone-specs/+/818616/2

But yes, please join policy popup biweekly call and discuss it
- https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup_Team#Meeting 

-gmann

 > 
 > [1] https://openinfra.dev/summit-schedule
 > 
 > ср, 29 июн. 2022 г., 16:36 Michael Johnson <johnsomor at gmail.com>:
 > 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
 > > >
 > > >
 > >
 > >
 > 
 >