Open Stack

Hi Steve,

Thank you -- this clarifies things quite a bit. 

I'd like to join that discussion at the summit if possible. 

-M

________________________________
Kind Regards,

Michael D. Elder

STSM | Master Inventor
mdelder at us.ibm.com  | linkedin.com/in/mdelder

"Success is not delivering a feature; success is learning how to solve the 
customer’s problem.” -Mark Cook



From:   Steven Hardy <shardy at redhat.com>
To:     "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
Date:   04/07/2014 12:00 PM
Subject:        Re: [openstack-dev] [heat] Problems with Heat software 
configurations and KeystoneV2



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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140407/4a9f54df/attachment.html>