[KEYSTONE][POLICIES] - Overrides that don't work?
From my understanding, any user with the project-manager role should be able to add any available user on any available group as long as the
Hi team, I'm having a weird behavior with my Openstack platform that makes me think I may have misunderstood some mechanisms on the way policies are working and especially the overriding. So, long story short, I've few services that get custom policies such as glance that behave as expected, Keystone's one aren't. All in all, here is what I'm understanding of the mechanism: This is the keystone policy that I'm looking to override: https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/ This policy default can be found in here: https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol... Here is the policy that I'm testing: https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/ I know, this policy isn't taking care of the admin role but it's not the point. project-manager domain is the same as the target. However, when I'm doing that, keystone complains that I'm not authorized to do so because the user token scope is 'PROJECT' where it should be 'SYSTEM' or 'DOMAIN'. Now, I wouldn't be surprised of that message being thrown out with the default policy as it's stated on the code with the following: https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com... So the question is, if the custom policy doesn't override the default scope_types how am I supposed to make it work? I hope it was clear enough, but if not, feel free to ask me for more information. PS: I've tried to assign this role with a domain scope to my user and I've still the same issue. Thanks a lot everyone!
I don't believe it's possible to override the scope of a policy rule. In this case it sounds like the user should request a domain-scoped token to perform this operation. For details on who to do that, see https://docs.openstack.org/keystone/wallaby/admin/tokens-overview.html#autho... On 10/6/21 7:52 AM, Gaël THEROND wrote:
Hi team,
I'm having a weird behavior with my Openstack platform that makes me think I may have misunderstood some mechanisms on the way policies are working and especially the overriding.
So, long story short, I've few services that get custom policies such as glance that behave as expected, Keystone's one aren't.
All in all, here is what I'm understanding of the mechanism:
This is the keystone policy that I'm looking to override: https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/ <https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/>
This policy default can be found in here: https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol... <https://opendev.org/openstack/keystone/src/branch/master/keystone/common/policies/group.py#L197>
Here is the policy that I'm testing: https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/ <https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/>
I know, this policy isn't taking care of the admin role but it's not the point.
From my understanding, any user with the project-manager role should be able to add any available user on any available group as long as the project-manager domain is the same as the target.
However, when I'm doing that, keystone complains that I'm not authorized to do so because the user token scope is 'PROJECT' where it should be 'SYSTEM' or 'DOMAIN'.
Now, I wouldn't be surprised of that message being thrown out with the default policy as it's stated on the code with the following: https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com... <https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/common/policies/group.py#L197>
So the question is, if the custom policy doesn't override the default scope_types how am I supposed to make it work?
I hope it was clear enough, but if not, feel free to ask me for more information.
PS: I've tried to assign this role with a domain scope to my user and I've still the same issue.
Thanks a lot everyone!
Hi ben! Thanks a lot for the answer! Ok I’ll get a look at that, but if I correctly understand a user with a role of project-admin attached to him as a scoped to domain he should be able to add users to a group once the policy update right? Once again thanks a lot for your answer! Le lun. 11 oct. 2021 à 17:25, Ben Nemec <openstack@nemebean.com> a écrit :
I don't believe it's possible to override the scope of a policy rule. In this case it sounds like the user should request a domain-scoped token to perform this operation. For details on who to do that, see
https://docs.openstack.org/keystone/wallaby/admin/tokens-overview.html#autho...
On 10/6/21 7:52 AM, Gaël THEROND wrote:
Hi team,
I'm having a weird behavior with my Openstack platform that makes me think I may have misunderstood some mechanisms on the way policies are working and especially the overriding.
So, long story short, I've few services that get custom policies such as glance that behave as expected, Keystone's one aren't.
All in all, here is what I'm understanding of the mechanism:
This is the keystone policy that I'm looking to override: https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/ <https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/>
This policy default can be found in here:
https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol...
< https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol...
Here is the policy that I'm testing: https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/ <https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/>
I know, this policy isn't taking care of the admin role but it's not the point.
From my understanding, any user with the project-manager role should be able to add any available user on any available group as long as the project-manager domain is the same as the target.
However, when I'm doing that, keystone complains that I'm not authorized to do so because the user token scope is 'PROJECT' where it should be 'SYSTEM' or 'DOMAIN'.
Now, I wouldn't be surprised of that message being thrown out with the default policy as it's stated on the code with the following:
https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com...
< https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com...
So the question is, if the custom policy doesn't override the default scope_types how am I supposed to make it work?
I hope it was clear enough, but if not, feel free to ask me for more information.
PS: I've tried to assign this role with a domain scope to my user and I've still the same issue.
Thanks a lot everyone!
Probably. I'm not an expert on writing Keystone policies so I can't promise anything. :-) However, I'm fairly confident that if you get a properly scoped token it will get you past your current error. Anything beyond that would be a barely educated guess on my part. On 10/11/21 12:18 PM, Gaël THEROND wrote:
Hi ben! Thanks a lot for the answer!
Ok I’ll get a look at that, but if I correctly understand a user with a role of project-admin attached to him as a scoped to domain he should be able to add users to a group once the policy update right?
Once again thanks a lot for your answer!
Le lun. 11 oct. 2021 à 17:25, Ben Nemec <openstack@nemebean.com <mailto:openstack@nemebean.com>> a écrit :
I don't believe it's possible to override the scope of a policy rule. In this case it sounds like the user should request a domain-scoped token to perform this operation. For details on who to do that, see https://docs.openstack.org/keystone/wallaby/admin/tokens-overview.html#autho... <https://docs.openstack.org/keystone/wallaby/admin/tokens-overview.html#authorization-scopes>
On 10/6/21 7:52 AM, Gaël THEROND wrote: > Hi team, > > I'm having a weird behavior with my Openstack platform that makes me > think I may have misunderstood some mechanisms on the way policies are > working and especially the overriding. > > So, long story short, I've few services that get custom policies such as > glance that behave as expected, Keystone's one aren't. > > All in all, here is what I'm understanding of the mechanism: > > This is the keystone policy that I'm looking to override: > https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/ <https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/> > <https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/ <https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/>> > > This policy default can be found in here: > https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol... <https://opendev.org/openstack/keystone/src/branch/master/keystone/common/policies/group.py#L197>
> <https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol... <https://opendev.org/openstack/keystone/src/branch/master/keystone/common/policies/group.py#L197>> > > Here is the policy that I'm testing: > https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/ <https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/> > <https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/ <https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/>> > > I know, this policy isn't taking care of the admin role but it's not the > point. > > From my understanding, any user with the project-manager role should be > able to add any available user on any available group as long as the > project-manager domain is the same as the target. > > However, when I'm doing that, keystone complains that I'm not authorized > to do so because the user token scope is 'PROJECT' where it should be > 'SYSTEM' or 'DOMAIN'. > > Now, I wouldn't be surprised of that message being thrown out with the > default policy as it's stated on the code with the following: > https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com... <https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/common/policies/group.py#L197>
> <https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com... <https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/common/policies/group.py#L197>> > > So the question is, if the custom policy doesn't override the default > scope_types how am I supposed to make it work? > > I hope it was clear enough, but if not, feel free to ask me for more > information. > > PS: I've tried to assign this role with a domain scope to my user and > I've still the same issue. > > Thanks a lot everyone! > >
All right, I'll test that out a bit more using a native Keystone user type as for now I'm dealing with ADFS/SSO based users that can't use CLI because ECP isn't available and so rely on Application Credentials that are project scoped ^^ Le mar. 12 oct. 2021 à 18:18, Ben Nemec <openstack@nemebean.com> a écrit :
Probably. I'm not an expert on writing Keystone policies so I can't promise anything. :-)
However, I'm fairly confident that if you get a properly scoped token it will get you past your current error. Anything beyond that would be a barely educated guess on my part.
On 10/11/21 12:18 PM, Gaël THEROND wrote:
Hi ben! Thanks a lot for the answer!
Ok I’ll get a look at that, but if I correctly understand a user with a role of project-admin attached to him as a scoped to domain he should be able to add users to a group once the policy update right?
Once again thanks a lot for your answer!
Le lun. 11 oct. 2021 à 17:25, Ben Nemec <openstack@nemebean.com <mailto:openstack@nemebean.com>> a écrit :
I don't believe it's possible to override the scope of a policy rule. In this case it sounds like the user should request a domain-scoped token to perform this operation. For details on who to do that, see
https://docs.openstack.org/keystone/wallaby/admin/tokens-overview.html#autho...
<
https://docs.openstack.org/keystone/wallaby/admin/tokens-overview.html#autho...
On 10/6/21 7:52 AM, Gaël THEROND wrote: > Hi team, > > I'm having a weird behavior with my Openstack platform that makes
me
> think I may have misunderstood some mechanisms on the way policies are > working and especially the overriding. > > So, long story short, I've few services that get custom policies such as > glance that behave as expected, Keystone's one aren't. > > All in all, here is what I'm understanding of the mechanism: > > This is the keystone policy that I'm looking to override: > https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/ <https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/> > <https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/ <https://paste.openstack.org/show/bwuF6jFISscRllWdUURL/>> > > This policy default can be found in here: >
https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol...
<
https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol...
> <
https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol...
<
> > Here is the policy that I'm testing: > https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/ <https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/> > <https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/ <https://paste.openstack.org/show/bHQ0PXvOro4lXNTlxlie/>> > > I know, this policy isn't taking care of the admin role but it's not the > point. > > From my understanding, any user with the project-manager role should be > able to add any available user on any available group as long as
https://opendev.org/openstack/keystone/src/branch/master/keystone/common/pol... the
> project-manager domain is the same as the target. > > However, when I'm doing that, keystone complains that I'm not authorized > to do so because the user token scope is 'PROJECT' where it should be > 'SYSTEM' or 'DOMAIN'. > > Now, I wouldn't be surprised of that message being thrown out with the > default policy as it's stated on the code with the following: >
https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com...
<
https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com...
> <
https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com...
<
https://opendev.org/openstack/keystone/src/branch/stable/ussuri/keystone/com...
> > So the question is, if the custom policy doesn't override the default > scope_types how am I supposed to make it work? > > I hope it was clear enough, but if not, feel free to ask me for more > information. > > PS: I've tried to assign this role with a domain scope to my user and > I've still the same issue. > > Thanks a lot everyone! > >
participants (2)
-
Ben Nemec
-
Gaël THEROND