Open Stack

On 04/04/2014 02:46 PM, Clint Byrum wrote:
> Excerpts from Michael Elder's message of 2014-04-04 07:16:55 -0700:
>> Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624
>>
>> I still have concerns though about the design approach of creating a new
>> project for every stack and new users for every resource.
>>
>> If I provision 1000 patterns a day with an average of 10 resources per
>> pattern, you're looking at 10,000 users per day. How can that scale?
>>
> If that can't scale, then keystone is not viable at all. I like to think
> we can scale keystone to the many millions of users level.
>
>> How can we ensure that all stale projects and users are cleaned up as
>> instances are destroy? When users choose to go through horizon or nova to
>> tear down instances, what cleans up the project & users associated with
>> that heat stack?
>>
> So, they created these things via Heat, but have now left the dangling
> references in Heat, and expect things to work properly?
>
> If they create it via Heat, they need to delete it via Heat.
>
>> Keystone defines the notion of tokens to support authentication, why
>> doesn't the design provision and store a token for the stack and its
>> equivalent management?
>>
> Tokens are _authentication_, not _authorization_.

Tokens are authorization, not authentication.  For Authentication you 
should be using a real cryptographically secure authentication 
mechanism:  either Kerberos or X509.


> For the latter, we
> need to have a way to lock down access to an individual resource in
> Heat. This allows putting secrets in deployments and knowing that only
> the instance which has been deployed to will have access to the secrets.
> I do see an optimization possible, which is to just create a user for the
> box that is given access to any deployments on the box. That would make
> sense if users are going to create many many deployments per server. But
> even at 10 per server, having 10 users is simpler than trying to manage
> shared users and edit their authorization rules.
>
> Now, I actually think that OAUTH tokens _are_ intended to be authorization
> as well as authentication, so that is probably where the focus should
> be long term. But really, you're talking about the same thing: a single
> key lookup in keystone.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev