[openstack-dev] [cross-project] RBAC Policy Basics
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  but now we are not able
>>> to implement it with Oslo policy without extensions so far.
>>> * I think to implement spec needs more time.
>>>  https://github.com/openstack/keystone-specs/blob/master/specs/keystonemiddleware/implemented/service-tokens.rst
>>>  https://review.openstack.org/#/c/133855/
>>> Is there any way to support spec in Oslo policy? Or
>>> Should I wait for spec?
>> I'm sorry, I am not sure what you are asking.
> I'm sorry let me explain this again.
> (1) Keystone supports service tokens  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:'.
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
> 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
More information about the OpenStack-dev