[tc][policy][ptl][operator] OpenSatck RBAC goal is to focus on project personas first (postpone the 'scope' implementation)
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
[1] https://etherpad.opendev.org/p/rbac-operator-feedback#L45 [2] https://etherpad.opendev.org/p/rbac-zed-ptg#L171
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
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
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
---- On Wed, 29 Jun 2022 13:25:11 -0500 Dmitriy Rabotyagov noonedeadpunk@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/...
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...
-gmann
[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
---- 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.
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
participants (4)
-
Dmitriy Rabotyagov
-
Ghanshyam Mann
-
Michael Johnson
-
Sean Mooney