Open Stack

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


http://git.openstack.org/cgit/openstack/oslo.policy/commit/?id=a08bc79f5c117696c43feb2e44c4dc5fd0013deb

>
> 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