[openstack-dev] [cross-project] RBAC Policy Basics

Adam Young ayoung at redhat.com
Tue Jun 23 13:29:48 UTC 2015

On 06/23/2015 06:14 AM, Osanai, Hisashi wrote:
> On Tuesday, June 23, 2015 12:14 AM, Adam Young wrote:
>> It is not an issue if you keep each of the policy files completely
>> separate, but it means that each service has its own meaning for the
>> same name, and that confuses operators;  owner in Nova means "a user
>> that has a role on this project" where as "owner" in Keystone means
>> "Objects associated with a specific user".
> I understand your thought came from usability.
> But it might increase development complexity, I think each component
> doesn't want to define own component name in the policy.json because
> it's well-known there.
> Unnn... Please forget it (it might be too development thought) :-)
> I want to focus on the following topic:
>>> My concern now is:
>>> * Service Tokens was implemented in Juno [1] but now we are not able
>>>    to implement it with Oslo policy without extensions so far.
>>> * I think to implement spec[2] needs more time.
>>> [1] https://github.com/openstack/keystone-specs/blob/master/specs/keystonemiddleware/implemented/service-tokens.rst
>>> [2] https://review.openstack.org/#/c/133855/
>>> Is there any way to support spec[1] in Oslo policy? Or
>>> Should I wait for spec[2]?
>> I'm sorry, I am not sure what you are asking.
> I'm sorry let me explain this again.
> (1) Keystone supports service tokens [1] from Juno release.
> (2) Oslo policy graduated from Kilo release.
> (3) Oslo policy doesn't have an ability to deal with the service tokens.
>      I'm not 100% sure but in order to support the service tokens Oslo policy
>      needs to handle service_roles in addition to roles stored in a credential.
>      Current logic:
>      If a rule which starts with 'role:', RoleCheck uses 'roles' in the credential.
>      code: https://github.com/openstack/oslo.policy/blob/master/oslo_policy/_checks.py#L249
>      My solution for this now is create ServiceRoleCheck class to handle 'service_roles' in
>      the credential. This check will be used when a rule starts with 'srole:'.
>      https://review.openstack.org/#/c/149930/15/swift/common/middleware/keystoneauth.py
>      L759-L767
OK, I think I get it;  you want to make a check specific to the roles on 
the service token.  The term Service roles  confused me.

You can do this check with oslo.messaging today.  Don't uyse the role 
check, just a generic check.
It looks for an elelement in a collection, and reeturns true if it is in 
there;  see


> I think it's better to handle by Oslo policy because of a common issue. So I would like
> to know a plan to handle this issue.
> Thanks in advance,
> Hisashi Osanai
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list