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.
[1] https://openinfra.dev/summit-schedule
ср, 29 июн. 2022 г., 16:36 Michael Johnson johnsomor@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-...
On Wed, Jun 29, 2022 at 3:26 AM 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.
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