Open Stack

Adam, 

I was imprecise, thank you for correcting that error. 

I think the net of the statement still holds though: the Keystone token 
mechanism defines a mechanism for authorization, why doesn't the heat 
stack manage a token for any behavior that requires authorization? 


-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:   Adam Young <ayoung at redhat.com>
To:     openstack-dev at lists.openstack.org
Date:   04/04/2014 09:54 PM
Subject:        Re: [openstack-dev] [heat] Problems with Heat software 
configurations and KeystoneV2



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


_______________________________________________
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/20140406/9f67e53f/attachment.html>