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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
