Open Stack

On Sun, Apr 06, 2014 at 10:22:15PM -0400, Michael Elder wrote:
> If Keystone is configured with an external identity provider (LDAP, 
> OpenID, etc), how does the creation of a new user per resource affect that 
> external identity source? 

My understanding is that it should be possible to configure keystone to use
multiple (domain specific) identity backends.

So a possible configuration could be to have "real" users backed by the
LDAP directory, and have all projects/users associated with heat (which are
created in a special "heat" domain, completely separated from "real" users)
backed by some other identity backend, e.g Sql.

http://docs.openstack.org/developer/keystone/configuration.html#domain-specific-drivers

This is something we should definitely test, and I'd welcome feedback from
the keystone folks, or anyone who has experience with this functionality,
as to how well it works in Icehouse.

> My suggestion is broader, but in the same spirit: Could we consider 
> defining an _authorization_ "stack" token (thanks Adam), which acts like 
> an OAuth token (by delegating a set of actionable behaviors that a token 
> holder may perform). The "stack" token would be managed within the stack 
> in some protected form and used for any activities later performed on 
> resources which are managed by the stack. Instead of imposing user 
> administration tasks like creating users, deleting users, etc against the 
> Keystone database, Heat would instead provide these "stack" tokens to any 
> service which it connects to when managing a resource. In fact, there's no 
> real reason that the "stack" token couldn't piggyback on the existing 
> Keystone token mechanism, except that it would be potentially longer lived 
> and restricted to the specific set of resources for which it was granted. 

So oauth was considered before we implemented the domain-isolated users,
but it was not possible to persue due to lack of client support:

https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers
https://blueprints.launchpad.net/heat/+spec/oauth-credentials-resource

The main issue with tokens as provided by keystone today, is that they will
expire.  That is the main reason for chosing to create a user rather than
e.g a token limited in scope via a trust - if you put it in the instance,
you have to refresh it before expiry, which may not always be possible.

Additionally, you don't really want the credentials deployed inside a
(implicitly untrusted) instance derived from the operator who created the
stack - you want something associated with the stack but completely
isolated from "real" users

Your "stack" token approach above appears to indicate that Heat would
somehow generate, and maintain the lifecycle of, some special token which
is not owned by keystone.  This idea has been discussed, and rejected,
because we would prefer to make use of keystone functionality instead of
having the burden of maintaining our own bespoke authorization system.

If implementing something based on oauth, or some sort of scope-limited
non-expiring token, becomes possible, it's quite likely we can provide the
option to do something other than the domain isolated users which has been
impelmented for Icehouse.

Ultimately, we had to use what was available in keystone *now* to enable
delivery of something which worked for Icehouse, hence the decision to use
what is available in the keystone v3 API.

> Not sure if email is the best medium for this discussion, so if there's a 
> better option, I'm happy to follow that path as well. 

I think it's fine, and I'm happy to get constructive feedback on the the
current approach, along with ideas for roadmap items which can potentially
improve it.

I have proposed this summit session which may provide more opportunity for
discussion, if accepted:

http://summit.openstack.org/cfp/details/190

Steve