[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