Open Stack

Excerpts from Steven Hardy's message of 2013-11-03 00:06:39 +0800:
> 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.
> 
> 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?
> 

Right, roles should be tenant and domain scoped, and the roles that we
consume in our policy definitions should not need to know anything about
the hierarchy. It seems very broken to me that there would be no way to
make a user who can only create more users in their tenant in Keystone.
Likewise, I would consider Heat broken if I had to use a special API
for doing things with a role I already have that is just scoped more
broadly than a single tenant or domain.

> 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.
> 
> What are peoples thoughts on this?

Let's try and find a keystone dev or two in the hallway at the summit
and get some clarity on the way Keystone is intended to work, which may
help us decide if we want to follow their admin-specific-API paradigm or
not.