[rbac][keystone][kolla][osa][tripleo][charms] RBAC in Yoga for deployment projects
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all toolings in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
I expect some of them (especially the configuration parameters) would be used by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin + system-reader allows any API calls and works like the previous project-admin.
For token validations system-reader(or service role) would be enough but there are some system-admin-only APIs (os-server-external-events API in nova called by neutron, Create allocation in placement called by nova or neutron) used for communications between services.
If we agree system-admin + system-reader is the right set then I'll update the default role assignment accordingly. This is important for Puppet OpenStack because there are implementations in puppet (which is usually called as providers) to manage some resources like Flavors, and these rely on credentials of service users after trying to look up user credentials.
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all toolings in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would be used by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin + system-reader allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
For token validations system-reader(or service role) would be enough but there are some system-admin-only APIs (os-server-external-events API in nova called by neutron, Create allocation in placement called by nova or neutron) used for communications between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
If we agree system-admin + system-reader is the right set then I'll update the default role assignment accordingly. This is important for Puppet OpenStack because there are implementations in puppet (which is usually called as providers) to manage some resources like Flavors, and these rely on credentials of service users after trying to look up user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators.
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard mark@stackhpc.com wrote:
On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all
toolings
in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would be
used
by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin +
system-reader
allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
For token validations system-reader(or service role) would be enough but
there are
some system-admin-only APIs (os-server-external-events API in nova
called by neutron,
Create allocation in placement called by nova or neutron) used for
communications
between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
I noticed I ignored implied roles... Thanks for clarifying that.
I understand and I agree with this. Considering the intention of SRBAC this would fix better with system-scoped, as you earlier mentioned but I'll defer to the others.
If we agree system-admin + system-reader is the right set then I'll
update the default role
assignment accordingly. This is important for Puppet OpenStack because
there are implementations
in puppet (which is usually called as providers) to manage some
resources like Flavors,
and these rely on credentials of service users after trying to look up
user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators.
My main concern was that some service users would require system-admin but I should have read this part more carefully.
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
So Assigning the service role (for the proper scope which is asked in the original thread) is the right way to go. For the provider stuff I'll look into any available option to replace usage of service user credential but that's specific to Puppet which we can ignore here in this discussion.
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we
missed?
Mark
[1]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
[2]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
[3]
https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d...
[4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5]
https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
---- On Wed, 19 Jan 2022 08:01:00 -0600 Takashi Kajinami tkajinam@redhat.com wrote ----
On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard mark@stackhpc.com wrote: On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all toolings in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would be used by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin + system-reader allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
Yes, as mark mentioned. And that is the key change from prevous direction. We are isolating the system and project level APIs. system token will be able to perform only system level operation and not allowed to do project level operation. For example: system user will not be allowed to create the server in nova. To have a quick view on those (we have not finished yet in nova), you can check how it will look like in the below series:
- https://review.opendev.org/q/topic:%22bp%252Fpolicy-defaults-refresh-2%22+(s...)
You can see the test cases for all four possible configuration combination and what all roles are allowed in which configuration (case 4th is end goal we want to be for RBAC):
1. enforce_scope=False + legacy rule (current default policies) 2. enforce_scope=False + No legacy rule (enable scope but remove old policy default) 3. enforce_scope=True + legacy rule (enable scope with old policy default) 4. enforce_scope=True + no legacy rule (end goal of new RBAC)
For token validations system-reader(or service role) would be enough but there are some system-admin-only APIs (os-server-external-events API in nova called by neutron, Create allocation in placement called by nova or neutron) used for communications between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
I noticed I ignored implied roles... Thanks for clarifying that. I understand and I agree with this. Considering the intention of SRBAC this would fixbetter with system-scoped, as you earlier mentioned but I'll defer to the others. >
Another thigns to note here is, in Yoga cycle we are doing only system-admin. system-reader, system-member will be done in phase3 which is for future releases (BB).
If we agree system-admin + system-reader is the right set then I'll update the default role assignment accordingly. This is important for Puppet OpenStack because there are implementations in puppet (which is usually called as providers) to manage some resources like Flavors, and these rely on credentials of service users after trying to look up user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators. My main concern was that some service users would require system-admin butI should have read this part more carefully. https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... So Assigning the service role (for the proper scope which is asked in the original thread)is the right way to go. For the provider stuff I'll look into any available option to replace usage of serviceuser credential but that's specific to Puppet which we can ignore here in this discussion.
right, once we have service role implemented then we will have clear way on how services will be communicating to other services APIs.
-gmann
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
Thank you, Ghanshyam, for your inputs. These are helpful to understand the latest plan.
So I think our question comes back to the original one. Currently keystone allows any of 1. system-service 2. domain-service 3. project-service 4. system-admin 5. system-member 6. system-reader to validate token but which one is the appropriate one to be used by authtoken middleware ?
Considering the purpose of the service role, the service role is appropriate but it's not yet clear which scope should be used (as is pointed out by Mark from the beginning).
AFAIK token is not a resource belonging to projects so system scope looks appropriate but what is the main intention is to allow project/domain scope ?
By the way, in Puppet OpenStack, we have been using the service"s" project instead of the service project for some reason(which I'm not aware of). So it's helpful for us if we avoid implementing strict limitations to use the service project.
On Thu, Jan 20, 2022 at 1:29 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 08:01:00 -0600 Takashi Kajinami < tkajinam@redhat.com> wrote ----
On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard mark@stackhpc.com wrote: On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com
wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all
toolings
in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would
be used
by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin +
system-reader
allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
Yes, as mark mentioned. And that is the key change from prevous direction. We are isolating the system and project level APIs. system token will be able to perform only system level operation and not allowed to do project level operation. For example: system user will not be allowed to create the server in nova. To have a quick view on those (we have not finished yet in nova), you can check how it will look like in the below series:
https://review.opendev.org/q/topic:%22bp%252Fpolicy-defaults-refresh-2%22+(s...)
You can see the test cases for all four possible configuration combination and what all roles are allowed in which configuration (case 4th is end goal we want to be for RBAC):
- enforce_scope=False + legacy rule (current default policies)
- enforce_scope=False + No legacy rule (enable scope but remove old
policy default) 3. enforce_scope=True + legacy rule (enable scope with old policy default) 4. enforce_scope=True + no legacy rule (end goal of new RBAC)
For token validations system-reader(or service role) would be enough
but there are
some system-admin-only APIs (os-server-external-events API in nova
called by neutron,
Create allocation in placement called by nova or neutron) used for
communications
between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
I noticed I ignored implied roles... Thanks for clarifying that. I understand and I agree with this. Considering the intention of SRBAC
this would fixbetter with system-scoped, as you earlier mentioned but I'll defer to the others. >
Another thigns to note here is, in Yoga cycle we are doing only system-admin. system-reader, system-member will be done in phase3 which is for future releases (BB).
If we agree system-admin + system-reader is the right set then I'll
update the default role
assignment accordingly. This is important for Puppet OpenStack
because there are implementations
in puppet (which is usually called as providers) to manage some
resources like Flavors,
and these rely on credentials of service users after trying to look
up user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators. My main concern was that some service users would require system-admin
butI should have read this part more carefully. https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
So Assigning the service role (for the proper scope which is asked in
the original thread)is the right way to go. For the provider stuff I'll look into any available option to replace usage of serviceuser credential but that's specific to Puppet which we can ignore here in this discussion.
right, once we have service role implemented then we will have clear way on how services will be communicating to other services APIs.
-gmann
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com
wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can
share
how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we
missed?
Mark
[1]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
[2]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
[3]
https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d...
[4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5]
https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
On Thu, 2022-01-20 at 09:05 +0900, Takashi Kajinami wrote:
Thank you, Ghanshyam, for your inputs. These are helpful to understand the latest plan.
So I think our question comes back to the original one. Currently keystone allows any of
- system-service
- domain-service
- project-service
- system-admin
- system-member
- system-reader
to validate token but which one is the appropriate one to be used by authtoken middleware ?
Considering the purpose of the service role, the service role is appropriate but it's not yet clear which scope should be used (as is pointed out by Mark from the beginning).
AFAIK token is not a resource belonging to projects so system scope looks appropriate but what is the main intention is to allow project/domain scope ?
a token is really a resouce belownign to a user and that user can be a member of a project or doamin. do we need to enfoce any scope on this endpoint?
the token that the midelware is vlaidating shoudl be suffenct to do the validation since that user shoudl be able to retirve the list of roles and project/domain membership its is part of so i guess im confusted why we woudl not just pass the token to be ckeck as the token the middelware uses and not enforece any scope or role reqiruement on the token validation endpoint
perhaps im missunderstanding and the authtoken middleware is not the middleware that validate the toke is valid and populates the project_id and domain_id /roles in the oslo context object?
By the way, in Puppet OpenStack, we have been using the service"s" project instead of the service project for some reason(which I'm not aware of). So it's helpful for us if we avoid implementing strict limitations to use the service project.
On Thu, Jan 20, 2022 at 1:29 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 08:01:00 -0600 Takashi Kajinami < tkajinam@redhat.com> wrote ----
On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard mark@stackhpc.com wrote: On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com
wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all
toolings
in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would
be used
by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin +
system-reader
allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
Yes, as mark mentioned. And that is the key change from prevous direction. We are isolating the system and project level APIs. system token will be able to perform only system level operation and not allowed to do project level operation. For example: system user will not be allowed to create the server in nova. To have a quick view on those (we have not finished yet in nova), you can check how it will look like in the below series:
https://review.opendev.org/q/topic:%22bp%252Fpolicy-defaults-refresh-2%22+(s...)
You can see the test cases for all four possible configuration combination and what all roles are allowed in which configuration (case 4th is end goal we want to be for RBAC):
- enforce_scope=False + legacy rule (current default policies)
- enforce_scope=False + No legacy rule (enable scope but remove old
policy default) 3. enforce_scope=True + legacy rule (enable scope with old policy default) 4. enforce_scope=True + no legacy rule (end goal of new RBAC)
For token validations system-reader(or service role) would be enough
but there are
some system-admin-only APIs (os-server-external-events API in nova
called by neutron,
Create allocation in placement called by nova or neutron) used for
communications
between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
I noticed I ignored implied roles... Thanks for clarifying that. I understand and I agree with this. Considering the intention of SRBAC
this would fixbetter with system-scoped, as you earlier mentioned but I'll defer to the others. >
Another thigns to note here is, in Yoga cycle we are doing only system-admin. system-reader, system-member will be done in phase3 which is for future releases (BB).
If we agree system-admin + system-reader is the right set then I'll
update the default role
assignment accordingly. This is important for Puppet OpenStack
because there are implementations
in puppet (which is usually called as providers) to manage some
resources like Flavors,
and these rely on credentials of service users after trying to look
up user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators. My main concern was that some service users would require system-admin
butI should have read this part more carefully. https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
So Assigning the service role (for the proper scope which is asked in
the original thread)is the right way to go. For the provider stuff I'll look into any available option to replace usage of serviceuser credential but that's specific to Puppet which we can ignore here in this discussion.
right, once we have service role implemented then we will have clear way on how services will be communicating to other services APIs.
-gmann
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com
wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can
share
how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we
missed?
Mark
[1]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
[2]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
[3]
https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d...
[4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5]
https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
On Thu, 2022-01-20 at 13:23 +0000, Sean Mooney wrote:
On Thu, 2022-01-20 at 09:05 +0900, Takashi Kajinami wrote:
Thank you, Ghanshyam, for your inputs. These are helpful to understand the latest plan.
So I think our question comes back to the original one. Currently keystone allows any of
- system-service
- domain-service
- project-service
- system-admin
- system-member
- system-reader
to validate token but which one is the appropriate one to be used by authtoken middleware ?
Considering the purpose of the service role, the service role is appropriate but it's not yet clear which scope should be used (as is pointed out by Mark from the beginning).
AFAIK token is not a resource belonging to projects so system scope looks appropriate but what is the main intention is to allow project/domain scope ?
a token is really a resouce belownign to a user and that user can be a member of a project or doamin. do we need to enfoce any scope on this endpoint?
the token that the midelware is vlaidating shoudl be suffenct to do the validation since that user shoudl be able to retirve the list of roles and project/domain membership its is part of so i guess im confusted why we woudl not just pass the token to be ckeck as the token the middelware uses and not enforece any scope or role reqiruement on the token validation endpoint
perhaps im missunderstanding and the authtoken middleware is not the middleware that validate the toke is valid and populates the project_id and domain_id /roles in the oslo context object?
by the way im asserting that a GET or HEAD query to
/v3/auth/tokens should not require any scope or role to complete
https://docs.openstack.org/api-ref/identity/v3/?expanded=check-token-detail,...
if the token that is being vlaidated is valid then the request can use the permission on that token to authrise the return of the info if the token is not valid hten it woudl return a 403
openstack uses bearer tokens so the fact that you posess it entirles you to use teh permission allowed by that token.
even a *reader token with no other roles shoudl be able to use the current token to validate itself. so really i dont think this api shoudl require a second token to vouch for it.
i can see some pushing back saying this would weaken the current security model which is valid in which case i woudl proably go with allowing a system-reader token with service roles or something similar. since tokens are nto really proejct or domaing owned but user owned.
By the way, in Puppet OpenStack, we have been using the service"s" project instead of the service project for some reason(which I'm not aware of). So it's helpful for us if we avoid implementing strict limitations to use the service project.
On Thu, Jan 20, 2022 at 1:29 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 08:01:00 -0600 Takashi Kajinami < tkajinam@redhat.com> wrote ----
On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard mark@stackhpc.com wrote: On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com
wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all
toolings
in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would
be used
by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin +
system-reader
allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
Yes, as mark mentioned. And that is the key change from prevous direction. We are isolating the system and project level APIs. system token will be able to perform only system level operation and not allowed to do project level operation. For example: system user will not be allowed to create the server in nova. To have a quick view on those (we have not finished yet in nova), you can check how it will look like in the below series:
https://review.opendev.org/q/topic:%22bp%252Fpolicy-defaults-refresh-2%22+(s...)
You can see the test cases for all four possible configuration combination and what all roles are allowed in which configuration (case 4th is end goal we want to be for RBAC):
- enforce_scope=False + legacy rule (current default policies)
- enforce_scope=False + No legacy rule (enable scope but remove old
policy default) 3. enforce_scope=True + legacy rule (enable scope with old policy default) 4. enforce_scope=True + no legacy rule (end goal of new RBAC)
For token validations system-reader(or service role) would be enough
but there are
some system-admin-only APIs (os-server-external-events API in nova
called by neutron,
Create allocation in placement called by nova or neutron) used for
communications
between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
I noticed I ignored implied roles... Thanks for clarifying that. I understand and I agree with this. Considering the intention of SRBAC
this would fixbetter with system-scoped, as you earlier mentioned but I'll defer to the others. >
Another thigns to note here is, in Yoga cycle we are doing only system-admin. system-reader, system-member will be done in phase3 which is for future releases (BB).
If we agree system-admin + system-reader is the right set then I'll
update the default role
assignment accordingly. This is important for Puppet OpenStack
because there are implementations
in puppet (which is usually called as providers) to manage some
resources like Flavors,
and these rely on credentials of service users after trying to look
up user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators. My main concern was that some service users would require system-admin
butI should have read this part more carefully. https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
So Assigning the service role (for the proper scope which is asked in
the original thread)is the right way to go. For the provider stuff I'll look into any available option to replace usage of serviceuser credential but that's specific to Puppet which we can ignore here in this discussion.
right, once we have service role implemented then we will have clear way on how services will be communicating to other services APIs.
-gmann
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com
wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can
share
how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we
missed?
Mark
[1]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
[2]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
[3]
https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d...
[4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5]
https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
---- On Thu, 20 Jan 2022 07:37:51 -0600 Sean Mooney smooney@redhat.com wrote ----
On Thu, 2022-01-20 at 13:23 +0000, Sean Mooney wrote:
On Thu, 2022-01-20 at 09:05 +0900, Takashi Kajinami wrote:
Thank you, Ghanshyam, for your inputs. These are helpful to understand the latest plan.
So I think our question comes back to the original one. Currently keystone allows any of
- system-service
- domain-service
- project-service
- system-admin
- system-member
- system-reader
to validate token but which one is the appropriate one to be used by authtoken middleware ?
Considering the purpose of the service role, the service role is appropriate but it's not yet clear which scope should be used (as is pointed out by Mark from the beginning).
AFAIK token is not a resource belonging to projects so system scope looks appropriate but what is the main intention is to allow project/domain scope ?
a token is really a resouce belownign to a user and that user can be a member of a project or doamin. do we need to enfoce any scope on this endpoint?
the token that the midelware is vlaidating shoudl be suffenct to do the validation since that user shoudl be able to retirve the list of roles and project/domain membership its is part of so i guess im confusted why we woudl not just pass the token to be ckeck as the token the middelware uses and not enforece any scope or role reqiruement on the token validation endpoint
perhaps im missunderstanding and the authtoken middleware is not the middleware that validate the toke is valid and populates the project_id and domain_id /roles in the oslo context object?
by the way im asserting that a GET or HEAD query to
/v3/auth/tokens should not require any scope or role to complete
https://docs.openstack.org/api-ref/identity/v3/?expanded=check-token-detail,...
if the token that is being vlaidated is valid then the request can use the permission on that token to authrise the return of the info if the token is not valid hten it woudl return a 403
openstack uses bearer tokens so the fact that you posess it entirles you to use teh permission allowed by that token.
even a *reader token with no other roles shoudl be able to use the current token to validate itself. so really i dont think this api shoudl require a second token to vouch for it.
i can see some pushing back saying this would weaken the current security model which is valid in which case i woudl proably go with allowing a system-reader token with service roles or something similar. since tokens are nto really proejct or domaing owned but user owned.
As you mentioned, token valdiation is allowed to system, domain, and project scope token so I think main idea here to have and check scope is to block the unscoped token which is good.
IMO, Not forcing the scope seems more risky.
-gmann
By the way, in Puppet OpenStack, we have been using the service"s" project instead of the service project for some reason(which I'm not aware of). So it's helpful for us if we avoid implementing strict limitations to use the service project.
On Thu, Jan 20, 2022 at 1:29 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 08:01:00 -0600 Takashi Kajinami < tkajinam@redhat.com> wrote ----
On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard mark@stackhpc.com wrote: On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com
wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all
toolings
in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would
be used
by TripleO later.
> Question: should the role be added with system scope or in the > existing service project? The obvious main use for this is token > validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin +
system-reader
allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
Yes, as mark mentioned. And that is the key change from prevous direction. We are isolating the system and project level APIs. system token will be able to perform only system level operation and not allowed to do project level operation. For example: system user will not be allowed to create the server in nova. To have a quick view on those (we have not finished yet in nova), you can check how it will look like in the below series:
https://review.opendev.org/q/topic:%22bp%252Fpolicy-defaults-refresh-2%22+(s...)
You can see the test cases for all four possible configuration combination and what all roles are allowed in which configuration (case 4th is end goal we want to be for RBAC):
- enforce_scope=False + legacy rule (current default policies)
- enforce_scope=False + No legacy rule (enable scope but remove old
policy default) 3. enforce_scope=True + legacy rule (enable scope with old policy default) 4. enforce_scope=True + no legacy rule (end goal of new RBAC)
For token validations system-reader(or service role) would be enough
but there are
some system-admin-only APIs (os-server-external-events API in nova
called by neutron,
Create allocation in placement called by nova or neutron) used for
communications
between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
I noticed I ignored implied roles... Thanks for clarifying that. I understand and I agree with this. Considering the intention of SRBAC
this would fixbetter with system-scoped, as you earlier mentioned but I'll defer to the others. >
Another thigns to note here is, in Yoga cycle we are doing only system-admin. system-reader, system-member will be done in phase3 which is for future releases (BB).
If we agree system-admin + system-reader is the right set then I'll
update the default role
assignment accordingly. This is important for Puppet OpenStack
because there are implementations
in puppet (which is usually called as providers) to manage some
resources like Flavors,
and these rely on credentials of service users after trying to look
up user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators. My main concern was that some service users would require system-admin
butI should have read this part more carefully. https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
So Assigning the service role (for the proper scope which is asked in
the original thread)is the right way to go. For the provider stuff I'll look into any available option to replace usage of serviceuser credential but that's specific to Puppet which we can ignore here in this discussion.
right, once we have service role implemented then we will have clear way on how services will be communicating to other services APIs.
-gmann
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com
wrote:
> > Hi, > > If you haven't been paying close attention, it would be easy to miss > some of the upcoming RBAC changes which will have an impact on > deployment projects. I thought I'd start a thread so that we can
share
> how we are approaching this, get answers to open questions, and > ideally all end up with a fairly consistent approach. > > The secure RBAC work has a long history, and continues to evolve. > According to [1], we should start to see some fairly substantial > changes over the next few releases. That spec is fairly long, but > worth a read. > > In the yoga timeline [2], there is one change in particular that has > an impact on deployment projects, "3. Keystone enforces scope by > default". After this change, all of the deprecated policies that many > still rely on in Keystone will be removed. > > In kolla-ansible, we have an etherpad [5] with some notes, questions > and half-baked plans. We made some changes in Xena [3] to use system > scope in some places when interacting with system APIs in Ansible > tasks. > > The next change we have staged is to add the service role to all > service users [4], in preparation for [2]. > > Question: should the role be added with system scope or in the > existing service project? The obvious main use for this is token > validation, which seems to allow system or project scope. > > We anticipate that some service users may still require some > project-scoped roles, e.g. when creating resources for octavia. We'll > deal with those on a case by case basis. > > In anticipation of keystone setting enforce_scope=True and removing > old default policies (which I assume effectively removes > enforce_new_defaults?), we will set this in kolla-ansible, and try to > deal with any fallout. Hopefully the previous work will make this > minimal. > > How does that line up with other projects' approaches? What have we
missed?
> > Mark > > [1]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
> [2]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
> [3]
https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d...
> [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 > [5]
https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
>
---- On Wed, 19 Jan 2022 18:05:11 -0600 Takashi Kajinami tkajinam@redhat.com wrote ----
Thank you, Ghanshyam, for your inputs.These are helpful to understand the latest plan. So I think our question comes back to the original one.Currently keystone allows any of 1. system-service 2. domain-service 3. project-service 4. system-admin 5. system-member 6. system-readerto validate token but which one is the appropriate one to be used by authtoken middleware ? Considering the purpose of the service role, the service role is appropriate but it's not yetclear which scope should be used (as is pointed out by Mark from the beginning). AFAIK token is not a resource belonging to projects so system scope looks appropriatebut what is the main intention is to allow project/domain scope ?
IMO, general service role enforcement will look like:
- They will enforce the same scope as APIs. For example, neutrons call nova APIs X (server external event APIs). Nova APIs default policy will add service role like below:
policy.DocumentedRuleDefault( name='os_compute_api:os-server-external-events:create', check_str='role:admin or role:service', scope_types=['project'] )
and neutron will call the service role token with project scoped.
Same applies to token validation APIs also, as you know, it is allowed to any scope (system, domain, project) so allowed service role in any scope can be used. Answer to your question on which one is appropriate is that you can use any of mentioned one as they are allowed (that is how users will be accessing it).
I hope it answer your query but again service roles are not implemented yet so policy default may change especially from project side policy, hoping keystone policy are all good and will not change but let's wait until this spec - https://review.opendev.org/c/openstack/keystone-specs/+/818616
-gmann
By the way, in Puppet OpenStack, we have been using the service"s" project instead ofthe service project for some reason(which I'm not aware of).So it's helpful for us if we avoid implementing strict limitations to use the service project.
On Thu, Jan 20, 2022 at 1:29 AM Ghanshyam Mann gmann@ghanshyammann.com wrote: ---- On Wed, 19 Jan 2022 08:01:00 -0600 Takashi Kajinami tkajinam@redhat.com wrote ----
On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard mark@stackhpc.com wrote: On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all toolings in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would be used by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin + system-reader allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
Yes, as mark mentioned. And that is the key change from prevous direction. We are isolating the system and project level APIs. system token will be able to perform only system level operation and not allowed to do project level operation. For example: system user will not be allowed to create the server in nova. To have a quick view on those (we have not finished yet in nova), you can check how it will look like in the below series:
You can see the test cases for all four possible configuration combination and what all roles are allowed in which configuration (case 4th is end goal we want to be for RBAC):
- enforce_scope=False + legacy rule (current default policies)
- enforce_scope=False + No legacy rule (enable scope but remove old policy default)
- enforce_scope=True + legacy rule (enable scope with old policy default)
- enforce_scope=True + no legacy rule (end goal of new RBAC)
For token validations system-reader(or service role) would be enough but there are some system-admin-only APIs (os-server-external-events API in nova called by neutron, Create allocation in placement called by nova or neutron) used for communications between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
I noticed I ignored implied roles... Thanks for clarifying that. I understand and I agree with this. Considering the intention of SRBAC this would fixbetter with system-scoped, as you earlier mentioned but I'll defer to the others. >
Another thigns to note here is, in Yoga cycle we are doing only system-admin. system-reader, system-member will be done in phase3 which is for future releases (BB).
If we agree system-admin + system-reader is the right set then I'll update the default role assignment accordingly. This is important for Puppet OpenStack because there are implementations in puppet (which is usually called as providers) to manage some resources like Flavors, and these rely on credentials of service users after trying to look up user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators. My main concern was that some service users would require system-admin butI should have read this part more carefully. https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... So Assigning the service role (for the proper scope which is asked in the original thread)is the right way to go. For the provider stuff I'll look into any available option to replace usage of serviceuser credential but that's specific to Puppet which we can ignore here in this discussion.
right, once we have service role implemented then we will have clear way on how services will be communicating to other services APIs.
-gmann
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
On Thu, 20 Jan 2022 at 18:53, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 18:05:11 -0600 Takashi Kajinami tkajinam@redhat.com wrote ----
Thank you, Ghanshyam, for your inputs.These are helpful to understand the latest plan. So I think our question comes back to the original one.Currently keystone allows any of 1. system-service 2. domain-service 3. project-service 4. system-admin 5. system-member 6. system-readerto validate token but which one is the appropriate one to be used by authtoken middleware ? Considering the purpose of the service role, the service role is appropriate but it's not yetclear which scope should be used (as is pointed out by Mark from the beginning). AFAIK token is not a resource belonging to projects so system scope looks appropriatebut what is the main intention is to allow project/domain scope ?
IMO, general service role enforcement will look like:
- They will enforce the same scope as APIs. For example, neutrons call nova APIs X (server external event APIs). Nova
APIs default policy will add service role like below:
policy.DocumentedRuleDefault( name='os_compute_api:os-server-external-events:create', check_str='role:admin or role:service', scope_types=['project'] )
and neutron will call the service role token with project scoped.
Which project would be in scope here? I don't think it makes sense to use the project of the resource that the event is for, since these calls are generally asynchronous, so we won't have the user's context. Currently for these service API calls AFAIK we're using a service user (e.g. nova) which has the admin role in the service project.
Same applies to token validation APIs also, as you know, it is allowed to any scope (system, domain, project) so allowed service role in any scope can be used. Answer to your question on which one is appropriate is that you can use any of mentioned one as they are allowed (that is how users will be accessing it).
I hope it answer your query but again service roles are not implemented yet so policy default may change especially from project side policy, hoping keystone policy are all good and will not change but let's wait until this spec
-gmann
By the way, in Puppet OpenStack, we have been using the service"s" project instead ofthe service project for some reason(which I'm not aware of).So it's helpful for us if we avoid implementing strict limitations to use the service project.
On Thu, Jan 20, 2022 at 1:29 AM Ghanshyam Mann gmann@ghanshyammann.com wrote: ---- On Wed, 19 Jan 2022 08:01:00 -0600 Takashi Kajinami tkajinam@redhat.com wrote ----
On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard mark@stackhpc.com wrote: On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all toolings in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would be used by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin + system-reader allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
Yes, as mark mentioned. And that is the key change from prevous direction. We are isolating the system and project level APIs. system token will be able to perform only system level operation and not allowed to do project level operation. For example: system user will not be allowed to create the server in nova. To have a quick view on those (we have not finished yet in nova), you can check how it will look like in the below series:
You can see the test cases for all four possible configuration combination and what all roles are allowed in which configuration (case 4th is end goal we want to be for RBAC):
- enforce_scope=False + legacy rule (current default policies)
- enforce_scope=False + No legacy rule (enable scope but remove old policy default)
- enforce_scope=True + legacy rule (enable scope with old policy default)
- enforce_scope=True + no legacy rule (end goal of new RBAC)
For token validations system-reader(or service role) would be enough but there are some system-admin-only APIs (os-server-external-events API in nova called by neutron, Create allocation in placement called by nova or neutron) used for communications between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
I noticed I ignored implied roles... Thanks for clarifying that. I understand and I agree with this. Considering the intention of SRBAC this would fixbetter with system-scoped, as you earlier mentioned but I'll defer to the others. >
Another thigns to note here is, in Yoga cycle we are doing only system-admin. system-reader, system-member will be done in phase3 which is for future releases (BB).
If we agree system-admin + system-reader is the right set then I'll update the default role assignment accordingly. This is important for Puppet OpenStack because there are implementations in puppet (which is usually called as providers) to manage some resources like Flavors, and these rely on credentials of service users after trying to look up user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators. My main concern was that some service users would require system-admin butI should have read this part more carefully. https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... So Assigning the service role (for the proper scope which is asked in the original thread)is the right way to go. For the provider stuff I'll look into any available option to replace usage of serviceuser credential but that's specific to Puppet which we can ignore here in this discussion.
right, once we have service role implemented then we will have clear way on how services will be communicating to other services APIs.
-gmann
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
---- On Thu, 20 Jan 2022 13:43:03 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Thu, 20 Jan 2022 at 18:53, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 18:05:11 -0600 Takashi Kajinami tkajinam@redhat.com wrote ----
Thank you, Ghanshyam, for your inputs.These are helpful to understand the latest plan. So I think our question comes back to the original one.Currently keystone allows any of 1. system-service 2. domain-service 3. project-service 4. system-admin 5. system-member 6. system-readerto validate token but which one is the appropriate one to be used by authtoken middleware ? Considering the purpose of the service role, the service role is appropriate but it's not yetclear which scope should be used (as is pointed out by Mark from the beginning). AFAIK token is not a resource belonging to projects so system scope looks appropriatebut what is the main intention is to allow project/domain scope ?
IMO, general service role enforcement will look like:
- They will enforce the same scope as APIs. For example, neutrons call nova APIs X (server external event APIs). Nova
APIs default policy will add service role like below:
policy.DocumentedRuleDefault( name='os_compute_api:os-server-external-events:create', check_str='role:admin or role:service', scope_types=['project'] )
and neutron will call the service role token with project scoped.
Which project would be in scope here? I don't think it makes sense to use the project of the resource that the event is for, since these calls are generally asynchronous, so we won't have the user's context. Currently for these service API calls AFAIK we're using a service user (e.g. nova) which has the admin role in the service project.
Those are good points and honestly saying I do not have answer to those yet. We will see while implementing those service role and per APIs/Service case by case.
-gmann
Same applies to token validation APIs also, as you know, it is allowed to any scope (system, domain, project) so allowed service role in any scope can be used. Answer to your question on which one is appropriate is that you can use any of mentioned one as they are allowed (that is how users will be accessing it).
I hope it answer your query but again service roles are not implemented yet so policy default may change especially from project side policy, hoping keystone policy are all good and will not change but let's wait until this spec
-gmann
By the way, in Puppet OpenStack, we have been using the service"s" project instead ofthe service project for some reason(which I'm not aware of).So it's helpful for us if we avoid implementing strict limitations to use the service project.
On Thu, Jan 20, 2022 at 1:29 AM Ghanshyam Mann gmann@ghanshyammann.com wrote: ---- On Wed, 19 Jan 2022 08:01:00 -0600 Takashi Kajinami tkajinam@redhat.com wrote ----
On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard mark@stackhpc.com wrote: On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami tkajinam@redhat.com wrote:
Hi,
(The topic doesn't include puppet but ...) I recently spent some time implementing initial support for SRBAC in Puppet OpenStack. You can find details in the etherpad[1] I created as my working note. It includes some items commonly required by all toolings in addition to ones specific to puppet. [1] https://etherpad.opendev.org/p/puppet-secure-rbac
Thanks for responding, Takashi - that's useful.
I expect some of them (especially the configuration parameters) would be used by TripleO later.
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
I'd add one more question which is; Which roles should be assigned for the service users ?
In the project which already implemented SRBAC, system-admin + system-reader allows any API calls and works like the previous project-admin.
IIUC the direction of travel has changed, and now the intention is that system-admin won't have access to project-scoped APIs.
Yes, as mark mentioned. And that is the key change from prevous direction. We are isolating the system and project level APIs. system token will be able to perform only system level operation and not allowed to do project level operation. For example: system user will not be allowed to create the server in nova. To have a quick view on those (we have not finished yet in nova), you can check how it will look like in the below series:
You can see the test cases for all four possible configuration combination and what all roles are allowed in which configuration (case 4th is end goal we want to be for RBAC):
- enforce_scope=False + legacy rule (current default policies)
- enforce_scope=False + No legacy rule (enable scope but remove old policy default)
- enforce_scope=True + legacy rule (enable scope with old policy default)
- enforce_scope=True + no legacy rule (end goal of new RBAC)
For token validations system-reader(or service role) would be enough but there are some system-admin-only APIs (os-server-external-events API in nova called by neutron, Create allocation in placement called by nova or neutron) used for communications between services.
The token validation API has the following default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
So system-reader, system-admin or service (any scope) should work. The spec suggests that the service role is intended for use by service to service APIs, in this case the credentials provided in the keystone_authtoken config. I would guess that system scope makes most sense here with the service role, although the rule suggests it would work with project scope and the service role.
I noticed I ignored implied roles... Thanks for clarifying that. I understand and I agree with this. Considering the intention of SRBAC this would fixbetter with system-scoped, as you earlier mentioned but I'll defer to the others. >
Another thigns to note here is, in Yoga cycle we are doing only system-admin. system-reader, system-member will be done in phase3 which is for future releases (BB).
If we agree system-admin + system-reader is the right set then I'll update the default role assignment accordingly. This is important for Puppet OpenStack because there are implementations in puppet (which is usually called as providers) to manage some resources like Flavors, and these rely on credentials of service users after trying to look up user credentials.
I think one of the outcomes of this work is that authentication will necessarily become a bit more fine-grained. It might not make sense to have the same role assignments for all users. To your example, I would say that registering flavors should be done by a different user with different permissions than a service user. In kolla-ansible we don't really register flavors other than for octavia - this is up to operators. My main concern was that some service users would require system-admin butI should have read this part more carefully. https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... So Assigning the service role (for the proper scope which is asked in the original thread)is the right way to go. For the provider stuff I'll look into any available option to replace usage of serviceuser credential but that's specific to Puppet which we can ignore here in this discussion.
right, once we have service role implemented then we will have clear way on how services will be communicating to other services APIs.
-gmann
Takashi
On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard mark@stackhpc.com wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard mark@stackhpc.com wrote ----
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
Service roles are planned for phase2 which is Z release[1]. The Idea here is service to service communication will happen with 'service' role (which keystone need to implement yet) and end users will keep using the what ever role is default (or overridden in policy file) which can be project or system scoped depends on the APIs.
So at the end service-service APIs policy default will looks like
'(role:admin and system:network and project_id:%(project_id)s) or (role:service and project_name:service)'
Say nova will use that service role to communicate to cinder and cinder policy will pass as service role is in OR in default policy.
But let's see how they are going to be and if any challenges when we will implement it in Z cycle.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Yeah, we want users/deployment projects/horizon etc to use the new policy from keystone as first and we will see feedback how they are (good, bad, really bad) from usage perspective. Why we choose keystone is, because new policy are there since many cycle and ready to use. Other projects needs to work their policy as per new SRBAC design/direction (for example nova needs to modify their policy before we ask users to use new policy and work is under progress[2]).
I think trying in kolla will be good way to know if we can move to keystone's new policy completely in yoga.
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
-gmann
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
On Wed, 19 Jan 2022 at 16:12, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard mark@stackhpc.com wrote ----
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
Service roles are planned for phase2 which is Z release[1]. The Idea here is service to service communication will happen with 'service' role (which keystone need to implement yet) and end users will keep using the what ever role is default (or overridden in policy file) which can be project or system scoped depends on the APIs.
So at the end service-service APIs policy default will looks like
'(role:admin and system:network and project_id:%(project_id)s) or (role:service and project_name:service)'
Say nova will use that service role to communicate to cinder and cinder policy will pass as service role is in OR in default policy.
But let's see how they are going to be and if any challenges when we will implement it in Z cycle.
I'm not 100% on our reasoning for using the service role in yoga (I wasn't in the discussion when we made the switch, although John Garbutt was), although I can provide at least one reason.
Currently, we have a bunch of service users doing things like keystone token validation using the admin role in the service project. If we enforce scopes & new defaults in keystone, this will no longer work, due to the default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
Now we could go and assign system-reader to all these users, but if the end goal is to give them all the service role, and that allows token validation, then to me that seems like a better path.
Currently, we're creating the service role during deploy & upgrade, then assigning it to users. Keystone is supposed to create the service role in yoga, so we can eventually drop that part.
Does this seem reasonable? Is keystone still on track to create the service role in yoga?
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Yeah, we want users/deployment projects/horizon etc to use the new policy from keystone as first and we will see feedback how they are (good, bad, really bad) from usage perspective. Why we choose keystone is, because new policy are there since many cycle and ready to use. Other projects needs to work their policy as per new SRBAC design/direction (for example nova needs to modify their policy before we ask users to use new policy and work is under progress[2]).
I think trying in kolla will be good way to know if we can move to keystone's new policy completely in yoga.
We have a scope-enforcing preview patch [1], and it's passing our base set of tests. I have another that triggers all of the jobs.
[1] https://review.opendev.org/c/openstack/kolla-ansible/+/825406
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
-gmann
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
---- On Thu, 20 Jan 2022 03:35:33 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Wed, 19 Jan 2022 at 16:12, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard mark@stackhpc.com wrote ----
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
Service roles are planned for phase2 which is Z release[1]. The Idea here is service to service communication will happen with 'service' role (which keystone need to implement yet) and end users will keep using the what ever role is default (or overridden in policy file) which can be project or system scoped depends on the APIs.
So at the end service-service APIs policy default will looks like
'(role:admin and system:network and project_id:%(project_id)s) or (role:service and project_name:service)'
Say nova will use that service role to communicate to cinder and cinder policy will pass as service role is in OR in default policy.
But let's see how they are going to be and if any challenges when we will implement it in Z cycle.
I'm not 100% on our reasoning for using the service role in yoga (I wasn't in the discussion when we made the switch, although John Garbutt was), although I can provide at least one reason.
Currently, we have a bunch of service users doing things like keystone token validation using the admin role in the service project. If we enforce scopes & new defaults in keystone, this will no longer work, due to the default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
Now we could go and assign system-reader to all these users, but if the end goal is to give them all the service role, and that allows token validation, then to me that seems like a better path.
Currently, we're creating the service role during deploy & upgrade, then assigning it to users. Keystone is supposed to create the service role in yoga, so we can eventually drop that part.
Does this seem reasonable? Is keystone still on track to create the service role in yoga?
I think this is a reasonable plan and once we have service roles implemented in keystone as well as in all the services to request other service APIs then deployment project (Kolla here) can update them from system_reader to actual service role.
And yes that can be done for token validation as well as the service-to-service API calls for example nova to cinder or neutron to nova APIs call. I do not think we can migrate everything (service tokens) together for all the services in deployment projects until all these services are ready with the 'service' role implementation (implementation means changing their default roles to add 'service' role for service-to-service APIs).
Regarding the keystone track on service role work in Yoga or not, I do not have clear answer may be Lance or keystone team can answer it. But Lance has spec up[1] but not yet merged.
[1] https://review.opendev.org/c/openstack/keystone-specs/+/818616
-gmann
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Yeah, we want users/deployment projects/horizon etc to use the new policy from keystone as first and we will see feedback how they are (good, bad, really bad) from usage perspective. Why we choose keystone is, because new policy are there since many cycle and ready to use. Other projects needs to work their policy as per new SRBAC design/direction (for example nova needs to modify their policy before we ask users to use new policy and work is under progress[2]).
I think trying in kolla will be good way to know if we can move to keystone's new policy completely in yoga.
We have a scope-enforcing preview patch [1], and it's passing our base set of tests. I have another that triggers all of the jobs.
[1] https://review.opendev.org/c/openstack/kolla-ansible/+/825406
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
-gmann
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
On Thu, 20 Jan 2022 at 18:40, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Thu, 20 Jan 2022 03:35:33 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Wed, 19 Jan 2022 at 16:12, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard mark@stackhpc.com wrote ----
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
Service roles are planned for phase2 which is Z release[1]. The Idea here is service to service communication will happen with 'service' role (which keystone need to implement yet) and end users will keep using the what ever role is default (or overridden in policy file) which can be project or system scoped depends on the APIs.
So at the end service-service APIs policy default will looks like
'(role:admin and system:network and project_id:%(project_id)s) or (role:service and project_name:service)'
Say nova will use that service role to communicate to cinder and cinder policy will pass as service role is in OR in default policy.
But let's see how they are going to be and if any challenges when we will implement it in Z cycle.
I'm not 100% on our reasoning for using the service role in yoga (I wasn't in the discussion when we made the switch, although John Garbutt was), although I can provide at least one reason.
Currently, we have a bunch of service users doing things like keystone token validation using the admin role in the service project. If we enforce scopes & new defaults in keystone, this will no longer work, due to the default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
Now we could go and assign system-reader to all these users, but if the end goal is to give them all the service role, and that allows token validation, then to me that seems like a better path.
Currently, we're creating the service role during deploy & upgrade, then assigning it to users. Keystone is supposed to create the service role in yoga, so we can eventually drop that part.
Does this seem reasonable? Is keystone still on track to create the service role in yoga?
I think this is a reasonable plan and once we have service roles implemented in keystone as well as in all the services to request other service APIs then deployment project (Kolla here) can update them from system_reader to actual service role.
To be clear, I am proposing to skip system-reader, and go straight to the service role in yoga.
And yes that can be done for token validation as well as the service-to-service API calls for example nova to cinder or neutron to nova APIs call. I do not think we can migrate everything (service tokens) together for all the services in deployment projects until all these services are ready with the 'service' role implementation (implementation means changing their default roles to add 'service' role for service-to-service APIs).
Regarding the keystone track on service role work in Yoga or not, I do not have clear answer may be Lance or keystone team can answer it. But Lance has spec up[1] but not yet merged.
[1] https://review.opendev.org/c/openstack/keystone-specs/+/818616
-gmann
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Yeah, we want users/deployment projects/horizon etc to use the new policy from keystone as first and we will see feedback how they are (good, bad, really bad) from usage perspective. Why we choose keystone is, because new policy are there since many cycle and ready to use. Other projects needs to work their policy as per new SRBAC design/direction (for example nova needs to modify their policy before we ask users to use new policy and work is under progress[2]).
I think trying in kolla will be good way to know if we can move to keystone's new policy completely in yoga.
We have a scope-enforcing preview patch [1], and it's passing our base set of tests. I have another that triggers all of the jobs.
[1] https://review.opendev.org/c/openstack/kolla-ansible/+/825406
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
-gmann
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
---- On Thu, 20 Jan 2022 13:36:53 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Thu, 20 Jan 2022 at 18:40, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Thu, 20 Jan 2022 03:35:33 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Wed, 19 Jan 2022 at 16:12, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard mark@stackhpc.com wrote ----
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
Service roles are planned for phase2 which is Z release[1]. The Idea here is service to service communication will happen with 'service' role (which keystone need to implement yet) and end users will keep using the what ever role is default (or overridden in policy file) which can be project or system scoped depends on the APIs.
So at the end service-service APIs policy default will looks like
'(role:admin and system:network and project_id:%(project_id)s) or (role:service and project_name:service)'
Say nova will use that service role to communicate to cinder and cinder policy will pass as service role is in OR in default policy.
But let's see how they are going to be and if any challenges when we will implement it in Z cycle.
I'm not 100% on our reasoning for using the service role in yoga (I wasn't in the discussion when we made the switch, although John Garbutt was), although I can provide at least one reason.
Currently, we have a bunch of service users doing things like keystone token validation using the admin role in the service project. If we enforce scopes & new defaults in keystone, this will no longer work, due to the default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
Now we could go and assign system-reader to all these users, but if the end goal is to give them all the service role, and that allows token validation, then to me that seems like a better path.
Currently, we're creating the service role during deploy & upgrade, then assigning it to users. Keystone is supposed to create the service role in yoga, so we can eventually drop that part.
Does this seem reasonable? Is keystone still on track to create the service role in yoga?
I think this is a reasonable plan and once we have service roles implemented in keystone as well as in all the services to request other service APIs then deployment project (Kolla here) can update them from system_reader to actual service role.
To be clear, I am proposing to skip system-reader, and go straight to the service role in yoga.
But that would not be doable until services implement service roles which is Yoga cycle target for keystone and Z cyle target for other projects. Or you mean to re-consider to target the service role for all projects also in Yoga so that deployment projects can go with service role directly?
-gmann
And yes that can be done for token validation as well as the service-to-service API calls for example nova to cinder or neutron to nova APIs call. I do not think we can migrate everything (service tokens) together for all the services in deployment projects until all these services are ready with the 'service' role implementation (implementation means changing their default roles to add 'service' role for service-to-service APIs).
Regarding the keystone track on service role work in Yoga or not, I do not have clear answer may be Lance or keystone team can answer it. But Lance has spec up[1] but not yet merged.
[1] https://review.opendev.org/c/openstack/keystone-specs/+/818616
-gmann
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Yeah, we want users/deployment projects/horizon etc to use the new policy from keystone as first and we will see feedback how they are (good, bad, really bad) from usage perspective. Why we choose keystone is, because new policy are there since many cycle and ready to use. Other projects needs to work their policy as per new SRBAC design/direction (for example nova needs to modify their policy before we ask users to use new policy and work is under progress[2]).
I think trying in kolla will be good way to know if we can move to keystone's new policy completely in yoga.
We have a scope-enforcing preview patch [1], and it's passing our base set of tests. I have another that triggers all of the jobs.
[1] https://review.opendev.org/c/openstack/kolla-ansible/+/825406
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
-gmann
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
On Thu, 20 Jan 2022 at 19:55, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Thu, 20 Jan 2022 13:36:53 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Thu, 20 Jan 2022 at 18:40, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Thu, 20 Jan 2022 03:35:33 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Wed, 19 Jan 2022 at 16:12, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard mark@stackhpc.com wrote ----
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
Service roles are planned for phase2 which is Z release[1]. The Idea here is service to service communication will happen with 'service' role (which keystone need to implement yet) and end users will keep using the what ever role is default (or overridden in policy file) which can be project or system scoped depends on the APIs.
So at the end service-service APIs policy default will looks like
'(role:admin and system:network and project_id:%(project_id)s) or (role:service and project_name:service)'
Say nova will use that service role to communicate to cinder and cinder policy will pass as service role is in OR in default policy.
But let's see how they are going to be and if any challenges when we will implement it in Z cycle.
I'm not 100% on our reasoning for using the service role in yoga (I wasn't in the discussion when we made the switch, although John Garbutt was), although I can provide at least one reason.
Currently, we have a bunch of service users doing things like keystone token validation using the admin role in the service project. If we enforce scopes & new defaults in keystone, this will no longer work, due to the default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
Now we could go and assign system-reader to all these users, but if the end goal is to give them all the service role, and that allows token validation, then to me that seems like a better path.
Currently, we're creating the service role during deploy & upgrade, then assigning it to users. Keystone is supposed to create the service role in yoga, so we can eventually drop that part.
Does this seem reasonable? Is keystone still on track to create the service role in yoga?
I think this is a reasonable plan and once we have service roles implemented in keystone as well as in all the services to request other service APIs then deployment project (Kolla here) can update them from system_reader to actual service role.
To be clear, I am proposing to skip system-reader, and go straight to the service role in yoga.
But that would not be doable until services implement service roles which is Yoga cycle target for keystone and Z cyle target for other projects. Or you mean to re-consider to target the service role for all projects also in Yoga so that deployment projects can go with service role directly?
Our current plan is to add the service role to all service users in yoga. This will allow keystone token validation to work when keystone drops the deprecated policies.
We will not remove the admin role from service users in the service project during yoga. This will allow projects other than keystone to continue to work as before.
At some later point, we will remove the admin role from service users in the service project, hopefully relying on the service role for most service-service communication. There may be other roles we need to assign in order to drop admin, but we'll assess that as we go.
Hopefully that's a bit more of a clear picture, and it seems sensible?
-gmann
And yes that can be done for token validation as well as the service-to-service API calls for example nova to cinder or neutron to nova APIs call. I do not think we can migrate everything (service tokens) together for all the services in deployment projects until all these services are ready with the 'service' role implementation (implementation means changing their default roles to add 'service' role for service-to-service APIs).
Regarding the keystone track on service role work in Yoga or not, I do not have clear answer may be Lance or keystone team can answer it. But Lance has spec up[1] but not yet merged.
[1] https://review.opendev.org/c/openstack/keystone-specs/+/818616
-gmann
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Yeah, we want users/deployment projects/horizon etc to use the new policy from keystone as first and we will see feedback how they are (good, bad, really bad) from usage perspective. Why we choose keystone is, because new policy are there since many cycle and ready to use. Other projects needs to work their policy as per new SRBAC design/direction (for example nova needs to modify their policy before we ask users to use new policy and work is under progress[2]).
I think trying in kolla will be good way to know if we can move to keystone's new policy completely in yoga.
We have a scope-enforcing preview patch [1], and it's passing our base set of tests. I have another that triggers all of the jobs.
[1] https://review.opendev.org/c/openstack/kolla-ansible/+/825406
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
-gmann
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
---- On Thu, 20 Jan 2022 14:41:00 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Thu, 20 Jan 2022 at 19:55, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Thu, 20 Jan 2022 13:36:53 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Thu, 20 Jan 2022 at 18:40, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Thu, 20 Jan 2022 03:35:33 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Wed, 19 Jan 2022 at 16:12, Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard mark@stackhpc.com wrote ---- > Hi, > > If you haven't been paying close attention, it would be easy to miss > some of the upcoming RBAC changes which will have an impact on > deployment projects. I thought I'd start a thread so that we can share > how we are approaching this, get answers to open questions, and > ideally all end up with a fairly consistent approach. > > The secure RBAC work has a long history, and continues to evolve. > According to [1], we should start to see some fairly substantial > changes over the next few releases. That spec is fairly long, but > worth a read. > > In the yoga timeline [2], there is one change in particular that has > an impact on deployment projects, "3. Keystone enforces scope by > default". After this change, all of the deprecated policies that many > still rely on in Keystone will be removed. > > In kolla-ansible, we have an etherpad [5] with some notes, questions > and half-baked plans. We made some changes in Xena [3] to use system > scope in some places when interacting with system APIs in Ansible > tasks. > > The next change we have staged is to add the service role to all > service users [4], in preparation for [2]. > > Question: should the role be added with system scope or in the > existing service project? The obvious main use for this is token > validation, which seems to allow system or project scope. > > We anticipate that some service users may still require some > project-scoped roles, e.g. when creating resources for octavia. We'll > deal with those on a case by case basis.
Service roles are planned for phase2 which is Z release[1]. The Idea here is service to service communication will happen with 'service' role (which keystone need to implement yet) and end users will keep using the what ever role is default (or overridden in policy file) which can be project or system scoped depends on the APIs.
So at the end service-service APIs policy default will looks like
'(role:admin and system:network and project_id:%(project_id)s) or (role:service and project_name:service)'
Say nova will use that service role to communicate to cinder and cinder policy will pass as service role is in OR in default policy.
But let's see how they are going to be and if any challenges when we will implement it in Z cycle.
I'm not 100% on our reasoning for using the service role in yoga (I wasn't in the discussion when we made the switch, although John Garbutt was), although I can provide at least one reason.
Currently, we have a bunch of service users doing things like keystone token validation using the admin role in the service project. If we enforce scopes & new defaults in keystone, this will no longer work, due to the default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
Now we could go and assign system-reader to all these users, but if the end goal is to give them all the service role, and that allows token validation, then to me that seems like a better path.
Currently, we're creating the service role during deploy & upgrade, then assigning it to users. Keystone is supposed to create the service role in yoga, so we can eventually drop that part.
Does this seem reasonable? Is keystone still on track to create the service role in yoga?
I think this is a reasonable plan and once we have service roles implemented in keystone as well as in all the services to request other service APIs then deployment project (Kolla here) can update them from system_reader to actual service role.
To be clear, I am proposing to skip system-reader, and go straight to the service role in yoga.
But that would not be doable until services implement service roles which is Yoga cycle target for keystone and Z cyle target for other projects. Or you mean to re-consider to target the service role for all projects also in Yoga so that deployment projects can go with service role directly?
Our current plan is to add the service role to all service users in yoga. This will allow keystone token validation to work when keystone drops the deprecated policies.
We will not remove the admin role from service users in the service project during yoga. This will allow projects other than keystone to continue to work as before.
At some later point, we will remove the admin role from service users in the service project, hopefully relying on the service role for most service-service communication. There may be other roles we need to assign in order to drop admin, but we'll assess that as we go.
Hopefully that's a bit more of a clear picture, and it seems sensible?
+1, sounds good to me. Hopefully we will get in better shape by Z release when all (or maximum) services will be migrated to new RBAC. Till than your plan sounds reasonable.
-gmann
-gmann
And yes that can be done for token validation as well as the service-to-service API calls for example nova to cinder or neutron to nova APIs call. I do not think we can migrate everything (service tokens) together for all the services in deployment projects until all these services are ready with the 'service' role implementation (implementation means changing their default roles to add 'service' role for service-to-service APIs).
Regarding the keystone track on service role work in Yoga or not, I do not have clear answer may be Lance or keystone team can answer it. But Lance has spec up[1] but not yet merged.
[1] https://review.opendev.org/c/openstack/keystone-specs/+/818616
-gmann
> > In anticipation of keystone setting enforce_scope=True and removing > old default policies (which I assume effectively removes > enforce_new_defaults?), we will set this in kolla-ansible, and try to > deal with any fallout. Hopefully the previous work will make this > minimal. > > How does that line up with other projects' approaches? What have we missed?
Yeah, we want users/deployment projects/horizon etc to use the new policy from keystone as first and we will see feedback how they are (good, bad, really bad) from usage perspective. Why we choose keystone is, because new policy are there since many cycle and ready to use. Other projects needs to work their policy as per new SRBAC design/direction (for example nova needs to modify their policy before we ask users to use new policy and work is under progress[2]).
I think trying in kolla will be good way to know if we can move to keystone's new policy completely in yoga.
We have a scope-enforcing preview patch [1], and it's passing our base set of tests. I have another that triggers all of the jobs.
[1] https://review.opendev.org/c/openstack/kolla-ansible/+/825406
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
-gmann
> > Mark > > [1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... > [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... > [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... > [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 > [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible > >
On Sat, Jan 22, 2022 at 8:57 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Thu, 20 Jan 2022 14:41:00 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Thu, 20 Jan 2022 at 19:55, Ghanshyam Mann gmann@ghanshyammann.com
wrote:
---- On Thu, 20 Jan 2022 13:36:53 -0600 Mark Goddard <
mark@stackhpc.com> wrote ----
On Thu, 20 Jan 2022 at 18:40, Ghanshyam Mann <
gmann@ghanshyammann.com> wrote:
---- On Thu, 20 Jan 2022 03:35:33 -0600 Mark Goddard <
mark@stackhpc.com> wrote ----
On Wed, 19 Jan 2022 at 16:12, Ghanshyam Mann <
gmann@ghanshyammann.com> wrote:
> > ---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard <
mark@stackhpc.com> wrote ----
> > Hi, > > > > If you haven't been paying close attention, it would be
easy to miss
> > some of the upcoming RBAC changes which will have an
impact on
> > deployment projects. I thought I'd start a thread so
that we can share
> > how we are approaching this, get answers to open
questions, and
> > ideally all end up with a fairly consistent approach. > > > > The secure RBAC work has a long history, and continues
to evolve.
> > According to [1], we should start to see some fairly
substantial
> > changes over the next few releases. That spec is fairly
long, but
> > worth a read. > > > > In the yoga timeline [2], there is one change in
particular that has
> > an impact on deployment projects, "3. Keystone enforces
scope by
> > default". After this change, all of the deprecated
policies that many
> > still rely on in Keystone will be removed. > > > > In kolla-ansible, we have an etherpad [5] with some
notes, questions
> > and half-baked plans. We made some changes in Xena [3]
to use system
> > scope in some places when interacting with system APIs
in Ansible
> > tasks. > > > > The next change we have staged is to add the service
role to all
> > service users [4], in preparation for [2]. > > > > Question: should the role be added with system scope or
in the
> > existing service project? The obvious main use for this
is token
> > validation, which seems to allow system or project scope. > > > > We anticipate that some service users may still require
some
> > project-scoped roles, e.g. when creating resources for
octavia. We'll
> > deal with those on a case by case basis. > > Service roles are planned for phase2 which is Z release[1].
The Idea here is
> service to service communication will happen with 'service'
role (which keystone
> need to implement yet) and end users will keep using the
what ever role
> is default (or overridden in policy file) which can be
project or system scoped
> depends on the APIs. > > So at the end service-service APIs policy default will
looks like
> > '(role:admin and system:network and
project_id:%(project_id)s) or (role:service and project_name:service)'
> > Say nova will use that service role to communicate to
cinder and cinder policy will pass
> as service role is in OR in default policy. > > But let's see how they are going to be and if any
challenges when we will implement
> it in Z cycle.
I'm not 100% on our reasoning for using the service role in
yoga (I
wasn't in the discussion when we made the switch, although
John
Garbutt was), although I can provide at least one reason.
Currently, we have a bunch of service users doing things like
keystone
token validation using the admin role in the service project.
If we
enforce scopes & new defaults in keystone, this will no
longer work,
due to the default policy:
identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject
Now we could go and assign system-reader to all these users,
but if
the end goal is to give them all the service role, and that
allows
token validation, then to me that seems like a better path.
Currently, we're creating the service role during deploy &
upgrade,
then assigning it to users. Keystone is supposed to create
the service
role in yoga, so we can eventually drop that part.
Does this seem reasonable? Is keystone still on track to
create the
service role in yoga?
I think this is a reasonable plan and once we have service roles
implemented
in keystone as well as in all the services to request other
service APIs then
deployment project (Kolla here) can update them from
system_reader to
actual service role.
To be clear, I am proposing to skip system-reader, and go straight
to
the service role in yoga.
But that would not be doable until services implement service roles
which is
Yoga cycle target for keystone and Z cyle target for other projects.
Or you mean
to re-consider to target the service role for all projects also in
Yoga so that
deployment projects can go with service role directly?
Our current plan is to add the service role to all service users in yoga. This will allow keystone token validation to work when keystone drops the deprecated policies.
We will not remove the admin role from service users in the service project during yoga. This will allow projects other than keystone to continue to work as before.
At some later point, we will remove the admin role from service users in the service project, hopefully relying on the service role for most service-service communication. There may be other roles we need to assign in order to drop admin, but we'll assess that as we go.
Hopefully that's a bit more of a clear picture, and it seems sensible?
+1, sounds good to me. Hopefully we will get in better shape by Z release when all (or maximum) services will be migrated to new RBAC. Till than your plan sounds reasonable.
-gmann
I'll follow the same approach in Puppet OpenStack and will add the project-scoped 'service' role to each service user by default. IIUC This is consistent with the current devstack which assigns the project-scoped service role to each service user, so I expect this approach will be tested in dsvm jobs [1]. [1] https://github.com/openstack/devstack/blob/d5d0bed479497560489983ae1fc80444b...
The same was already implemented in TripleO by [2] [2] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/819250
-gmann
And yes that can be done for token validation as well as the service-to-service API calls for example nova to cinder or
neutron to nova
APIs call. I do not think we can migrate everything (service
tokens) together for all
the services in deployment projects until all these services are
ready with the 'service'
role implementation (implementation means changing their default
roles
to add 'service' role for service-to-service APIs).
Regarding the keystone track on service role work in Yoga or
not, I do not
have clear answer may be Lance or keystone team can answer it.
But Lance
has spec up[1] but not yet merged.
[1]
https://review.opendev.org/c/openstack/keystone-specs/+/818616
-gmann
> > > > > In anticipation of keystone setting enforce_scope=True
and removing
> > old default policies (which I assume effectively removes > > enforce_new_defaults?), we will set this in
kolla-ansible, and try to
> > deal with any fallout. Hopefully the previous work will
make this
> > minimal. > > > > How does that line up with other projects' approaches?
What have we missed?
> > Yeah, we want users/deployment projects/horizon etc to use
the new policy from
> keystone as first and we will see feedback how they are
(good, bad, really bad) from
> usage perspective. Why we choose keystone is, because new
policy are there since
> many cycle and ready to use. Other projects needs to work
their policy as per new
> SRBAC design/direction (for example nova needs to modify
their policy before we ask
> users to use new policy and work is under progress[2]). > > I think trying in kolla will be good way to know if we can
move to keystone's new policy
> completely in yoga.
We have a scope-enforcing preview patch [1], and it's passing
our base
set of tests. I have another that triggers all of the jobs.
[1]
https://review.opendev.org/c/openstack/kolla-ansible/+/825406
> > [1]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
> [2]
https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
> > -gmann > > > > > Mark > > > > [1]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
> > [2]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
> > [3]
https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d...
> > [4]
https://review.opendev.org/c/openstack/kolla-ansible/+/815577
> > [5]
https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
> > > >
On Mon, Jan 24, 2022 at 4:50 PM Takashi Kajinami tkajinam@redhat.com wrote:
On Sat, Jan 22, 2022 at 8:57 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Thu, 20 Jan 2022 14:41:00 -0600 Mark Goddard mark@stackhpc.com wrote ----
On Thu, 20 Jan 2022 at 19:55, Ghanshyam Mann gmann@ghanshyammann.com
wrote:
---- On Thu, 20 Jan 2022 13:36:53 -0600 Mark Goddard <
mark@stackhpc.com> wrote ----
On Thu, 20 Jan 2022 at 18:40, Ghanshyam Mann <
gmann@ghanshyammann.com> wrote:
---- On Thu, 20 Jan 2022 03:35:33 -0600 Mark Goddard <
mark@stackhpc.com> wrote ----
> On Wed, 19 Jan 2022 at 16:12, Ghanshyam Mann <
gmann@ghanshyammann.com> wrote:
> > > > ---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard <
mark@stackhpc.com> wrote ----
> > > Hi, > > > > > > If you haven't been paying close attention, it would be
easy to miss
> > > some of the upcoming RBAC changes which will have an
impact on
> > > deployment projects. I thought I'd start a thread so
that we can share
> > > how we are approaching this, get answers to open
questions, and
> > > ideally all end up with a fairly consistent approach. > > > > > > The secure RBAC work has a long history, and continues
to evolve.
> > > According to [1], we should start to see some fairly
substantial
> > > changes over the next few releases. That spec is fairly
long, but
> > > worth a read. > > > > > > In the yoga timeline [2], there is one change in
particular that has
> > > an impact on deployment projects, "3. Keystone enforces
scope by
> > > default". After this change, all of the deprecated
policies that many
> > > still rely on in Keystone will be removed. > > > > > > In kolla-ansible, we have an etherpad [5] with some
notes, questions
> > > and half-baked plans. We made some changes in Xena [3]
to use system
> > > scope in some places when interacting with system APIs
in Ansible
> > > tasks. > > > > > > The next change we have staged is to add the service
role to all
> > > service users [4], in preparation for [2]. > > > > > > Question: should the role be added with system scope or
in the
> > > existing service project? The obvious main use for this
is token
> > > validation, which seems to allow system or project
scope.
> > > > > > We anticipate that some service users may still require
some
> > > project-scoped roles, e.g. when creating resources for
octavia. We'll
> > > deal with those on a case by case basis. > > > > Service roles are planned for phase2 which is Z
release[1]. The Idea here is
> > service to service communication will happen with
'service' role (which keystone
> > need to implement yet) and end users will keep using the
what ever role
> > is default (or overridden in policy file) which can be
project or system scoped
> > depends on the APIs. > > > > So at the end service-service APIs policy default will
looks like
> > > > '(role:admin and system:network and
project_id:%(project_id)s) or (role:service and project_name:service)'
> > > > Say nova will use that service role to communicate to
cinder and cinder policy will pass
> > as service role is in OR in default policy. > > > > But let's see how they are going to be and if any
challenges when we will implement
> > it in Z cycle. > > I'm not 100% on our reasoning for using the service role in
yoga (I
> wasn't in the discussion when we made the switch, although
John
> Garbutt was), although I can provide at least one reason. > > Currently, we have a bunch of service users doing things
like keystone
> token validation using the admin role in the service
project. If we
> enforce scopes & new defaults in keystone, this will no
longer work,
> due to the default policy: > > identity:validate_token: (role:reader and system_scope:all)
or
> rule:service_role or rule:token_subject > > Now we could go and assign system-reader to all these users,
but if
> the end goal is to give them all the service role, and that
allows
> token validation, then to me that seems like a better path. > > Currently, we're creating the service role during deploy &
upgrade,
> then assigning it to users. Keystone is supposed to create
the service
> role in yoga, so we can eventually drop that part. > > Does this seem reasonable? Is keystone still on track to
create the
> service role in yoga?
I think this is a reasonable plan and once we have service
roles implemented
in keystone as well as in all the services to request other
service APIs then
deployment project (Kolla here) can update them from
system_reader to
actual service role.
To be clear, I am proposing to skip system-reader, and go
straight to
the service role in yoga.
But that would not be doable until services implement service roles
which is
Yoga cycle target for keystone and Z cyle target for other projects.
Or you mean
to re-consider to target the service role for all projects also in
Yoga so that
deployment projects can go with service role directly?
Our current plan is to add the service role to all service users in yoga. This will allow keystone token validation to work when keystone drops the deprecated policies.
We will not remove the admin role from service users in the service project during yoga. This will allow projects other than keystone to continue to work as before.
At some later point, we will remove the admin role from service users in the service project, hopefully relying on the service role for most service-service communication. There may be other roles we need to assign in order to drop admin, but we'll assess that as we go.
Hopefully that's a bit more of a clear picture, and it seems sensible?
+1, sounds good to me. Hopefully we will get in better shape by Z release when all (or maximum) services will be migrated to new RBAC. Till than your plan sounds reasonable.
-gmann
I'll follow the same approach in Puppet OpenStack and will add the project-scoped 'service' role to each service user by default. IIUC This is consistent with the current devstack which assigns the project-scoped service role to each service user, so I expect this approach will be tested in dsvm jobs [1]. [1] https://github.com/openstack/devstack/blob/d5d0bed479497560489983ae1fc80444b...
The same was already implemented in TripleO by [2] [2] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/819250
I've spent some time going through all the keystone credentials managed by puppet modules and I recorded my observations in my working note.
https://etherpad.opendev.org/p/puppet-secure-rbac#L122
If my observation is correct, credentials in the following sections/services are used to access APIs which are not allowed for the service role and require an additional privilege like system-reader when Keystone is running with only new policies and scope enforcement.
glance [oslo_limit] This calls get limits API to obtain the limit for the project where a resource is being created. This requires a system-reader.
nova [keystone] This calls get project API to verify the project id passed in flavor access or quota sets. This operation requires a system-reader.
swift [s3api] This calls get EC2 credential API to cache credentials for the request user. This requires a system-reader.
swift [ceilometer] This calls list project API when ignore_projects is set, to look up these projects. This requires a system-reader.
-gmann
And yes that can be done for token validation as well as the service-to-service API calls for example nova to cinder or
neutron to nova
APIs call. I do not think we can migrate everything (service
tokens) together for all
the services in deployment projects until all these services
are ready with the 'service'
role implementation (implementation means changing their
default roles
to add 'service' role for service-to-service APIs).
Regarding the keystone track on service role work in Yoga or
not, I do not
have clear answer may be Lance or keystone team can answer it.
But Lance
has spec up[1] but not yet merged.
[1]
https://review.opendev.org/c/openstack/keystone-specs/+/818616
-gmann
> > > > > > > > > In anticipation of keystone setting enforce_scope=True
and removing
> > > old default policies (which I assume effectively removes > > > enforce_new_defaults?), we will set this in
kolla-ansible, and try to
> > > deal with any fallout. Hopefully the previous work will
make this
> > > minimal. > > > > > > How does that line up with other projects' approaches?
What have we missed?
> > > > Yeah, we want users/deployment projects/horizon etc to use
the new policy from
> > keystone as first and we will see feedback how they are
(good, bad, really bad) from
> > usage perspective. Why we choose keystone is, because new
policy are there since
> > many cycle and ready to use. Other projects needs to work
their policy as per new
> > SRBAC design/direction (for example nova needs to modify
their policy before we ask
> > users to use new policy and work is under progress[2]). > > > > I think trying in kolla will be good way to know if we can
move to keystone's new policy
> > completely in yoga. > > We have a scope-enforcing preview patch [1], and it's
passing our base
> set of tests. I have another that triggers all of the jobs. > > [1]
https://review.opendev.org/c/openstack/kolla-ansible/+/825406
> > > > [1]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
> > [2]
https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
> > > > -gmann > > > > > > > > Mark > > > > > > [1]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
> > > [2]
https://opendev.org/openstack/governance/src/branch/master/goals/selected/co...
> > > [3]
https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d...
> > > [4]
https://review.opendev.org/c/openstack/kolla-ansible/+/815577
> > > [5]
https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
> > > > > > > >
On Wed, 19 Jan 2022 at 19:38, Dmitriy Rabotyagov noonedeadpunk@ya.ru wrote:
- все
Hi!
In OSA I've already started topic [1] quite a while ago, that adds service role in addition to admin one for the migration purposes. It was intended, that admin can be revoked later on if needed.
So I based on my understanding of the thread, that is exactly the plan for keystone as well.
[1] https://review.opendev.org/q/topic:%22osa%252Fservice_tokens%22+(status:open...)
Hi Dmitriy,
Thanks for the update. I see that those patches are adding the service role. They're also configuring service tokens, which IIUC are unrelated, and allow for long-running operations to outlive the original user's token lifetime. Is it intentional?
Mark
19.01.2022, 12:43, "Mark Goddard" mark@stackhpc.com:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
-- Kind Regards, Dmitriy Rabotyagov
Hi Mark and all,
On Wed, 2022-01-19 at 10:35 +0000, Mark Goddard wrote:
Hi,
If you haven't been paying close attention, it would be easy to miss some of the upcoming RBAC changes which will have an impact on deployment projects. I thought I'd start a thread so that we can share how we are approaching this, get answers to open questions, and ideally all end up with a fairly consistent approach.
Thanks for highlighting this. In the Charms we are evaluating what needs to be changed. On a first pass these are the changes needed that were identified, it's an etherpad that's still evolving though :-)
https://etherpad.opendev.org/p/charms-secure-rbac
The secure RBAC work has a long history, and continues to evolve. According to [1], we should start to see some fairly substantial changes over the next few releases. That spec is fairly long, but worth a read.
In the yoga timeline [2], there is one change in particular that has an impact on deployment projects, "3. Keystone enforces scope by default". After this change, all of the deprecated policies that many still rely on in Keystone will be removed.
In kolla-ansible, we have an etherpad [5] with some notes, questions and half-baked plans. We made some changes in Xena [3] to use system scope in some places when interacting with system APIs in Ansible tasks.
The next change we have staged is to add the service role to all service users [4], in preparation for [2].
Question: should the role be added with system scope or in the existing service project? The obvious main use for this is token validation, which seems to allow system or project scope.
We anticipate that some service users may still require some project-scoped roles, e.g. when creating resources for octavia. We'll deal with those on a case by case basis.
In anticipation of keystone setting enforce_scope=True and removing old default policies (which I assume effectively removes enforce_new_defaults?), we will set this in kolla-ansible, and try to deal with any fallout. Hopefully the previous work will make this minimal.
How does that line up with other projects' approaches? What have we missed?
Mark
[1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/co... [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1d... [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577 [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
participants (6)
-
Dmitriy Rabotyagov
-
Felipe Reyes
-
Ghanshyam Mann
-
Mark Goddard
-
Sean Mooney
-
Takashi Kajinami