Open Stack

On 11/02/2013 09:06 AM, Steven Hardy wrote:
> Hi all,
>
> Looking to start a wider discussion, prompted by:
> https://review.openstack.org/#/c/54651/
> https://blueprints.launchpad.net/heat/+spec/management-api
> https://etherpad.openstack.org/p/heat-management-api
>
> Summary - it has been proposed to add a management API to Heat, similar in
> concept to the admin/public API topology used in keystone.
>
> I'm concerned that this may not be a pattern we want to propagate throughout
> OpenStack, and that for most services, we should have one API to access data,
> with the scope of the data returned/accessible defined by the roles held by
> the user (ie making proper use of the RBAC facilities afforded to us via
> keystone).
>
> In the current PoC patch, a users admin-ness is derived from the fact that
> they are accessing a specific endpoint, and that policy did not deny them
> access to that endpoint.  I think this is wrong, and we should use keystone
> roles to decide the scope of the request.
+1.  It seems like a bad idea to have authorization be driven from 
something other than the roles that a user possesses.
>
> The proposal seems to consider tenants as the top-level of abstraction, with
> the next level up being a global service provider admin, but this does not
> consider the keystone v3 concept of domains [1], or that you may wish to
> provide some of these admin-ish features to domain-admin users (who will
> adminster data accross multiple tenants, just like has been proposed), via the
> public-facing API.
>
> It seems like we need a way of scoping the request (via data in the context),
> based on a heirarchy of admin-ness, like:
>
> 1. Normal user
> 2. Tenant Admin (has admin role in a tenant)
> 3. Domain Admin (has admin role in all tenants in the domain)
> 4. Service Admin (has admin role everywhere, like admin_token for keystone)
>
> The current "is_admin" flag which is being used in the PoC patch won't allow
> this granularity of administrative boundaries to be represented, and splitting
> admin actions into a separate API will prevent us providing tenant and domain
> level admin functionality to customers in a public cloud environment.
>
> It has been mentioned that in keystone, if you have admin in one tenant, you
> are admin everywhere, which is a pattern I think we should not follow -
> keystone folks, what are your thoughts in terms of roadmap to make role
> assignment (at the request level) scoped to tenants rather than globally
> applied?  E.g what data can we add to move from X-Roles in auth_token, to
> expressing roles in multiple tenants and domains?
>
> Basically, I'm very concerned that we discuss this, get a clear roadmap which
> will work with future keystone admin/role models, and is not a short-term hack
> which we won't want to maintain long-term.
I can't speak for the Keystone developers, but it does seem to me that 
if this level of admin granularity is needed, Keystone is the right 
place for it.

-NGK
>
> What are peoples thoughts on this?
>
> [1]: https://wiki.openstack.org/wiki/Domains
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev