[openstack-dev] [keystone][security] Service User Permissions

Adam Young ayoung at redhat.com
Thu Jun 2 15:58:16 UTC 2016


On 06/02/2016 11:36 AM, Shawn McKinney wrote:
>> On Jun 2, 2016, at 10:03 AM, Adam Young <ayoung at redhat.com> wrote:
>>
>> To do all of this right, however, requires a degree of introspection that we do not have in OpenStack.  Trove needs to ask Nova "I want to do X, what role do I need?"  and there is no where in the system today that this information lives.
>>
>> So, while we could make something that works for service users as the problem is defined by Nova today, that would be, in a word, bad.  We need something that works for the larger OpenStack ecosystem, to include less trusted third party services, and still deal with the long running tasks.
> Hello,
>
> If openstack supported RBAC (ANSI INCITS 359) you would be able to call (something like) this API:
>
> List<String> permissionRoles(Permission  perm) throws SecurityException
>
> Return a list of type String of all roles that have granted a particular permission.
>
> RBAC Review APIs:
> http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/ReviewMgr.html
>
> One of the advantages of pursuing published standards, you enjoy support for requirements across a broad spectrum of requirements, and perhaps for things you didn’t know was needed (at design time).

Any senseible RBAC setup would support this, but we are not using a 
sensible one, we are using a hand rolled one.  Replacing everything with 
Fortress implies a complete rewrite of what we do now.  Nuke it from 
orbit type stuff.

What I would rather focus on is the splitting of the current policy into 
two parts:

1. Scope check done in code
2. Role check done in middleware

Role check should be donebased on URL, not on the policy key like 
identity:create_user


Then, yes, a Fortress style query could be done, or it could be done by 
asking the service itself.



>
> Hope this helps,
>
> Shawn
> __________________________________________________________________________
> 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