<font size=2 face="sans-serif">Adam, </font>
<br>
<br><font size=2 face="sans-serif">I was imprecise, thank you for correcting
that error. </font>
<br>
<br><font size=2 face="sans-serif">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? </font>
<br>
<br>
<br><font size=2 face="sans-serif">-M</font>
<br><font size=2 face="sans-serif"><br>
________________________________<br>
Kind Regards,<br>
<br>
Michael D. Elder<br>
<br>
STSM | Master Inventor<br>
mdelder@us.ibm.com  | linkedin.com/in/mdelder<br>
<br>
"Success is not delivering a feature; success is learning how to solve
the customer’s problem.” -Mark Cook</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Adam Young <ayoung@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">openstack-dev@lists.openstack.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">04/04/2014 09:54 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[heat] Problems with Heat software configurations and KeystoneV2</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 04/04/2014 02:46 PM, Clint Byrum wrote:<br>
> Excerpts from Michael Elder's message of 2014-04-04 07:16:55 -0700:<br>
>> Opened in Launchpad: </font></tt><a href="https://bugs.launchpad.net/heat/+bug/1302624"><tt><font size=2>https://bugs.launchpad.net/heat/+bug/1302624</font></tt></a><tt><font size=2><br>
>><br>
>> I still have concerns though about the design approach of creating
a new<br>
>> project for every stack and new users for every resource.<br>
>><br>
>> If I provision 1000 patterns a day with an average of 10 resources
per<br>
>> pattern, you're looking at 10,000 users per day. How can that
scale?<br>
>><br>
> If that can't scale, then keystone is not viable at all. I like to
think<br>
> we can scale keystone to the many millions of users level.<br>
><br>
>> How can we ensure that all stale projects and users are cleaned
up as<br>
>> instances are destroy? When users choose to go through horizon
or nova to<br>
>> tear down instances, what cleans up the project & users associated
with<br>
>> that heat stack?<br>
>><br>
> So, they created these things via Heat, but have now left the dangling<br>
> references in Heat, and expect things to work properly?<br>
><br>
> If they create it via Heat, they need to delete it via Heat.<br>
><br>
>> Keystone defines the notion of tokens to support authentication,
why<br>
>> doesn't the design provision and store a token for the stack and
its<br>
>> equivalent management?<br>
>><br>
> Tokens are _authentication_, not _authorization_.<br>
<br>
Tokens are authorization, not authentication.  For Authentication
you <br>
should be using a real cryptographically secure authentication <br>
mechanism:  either Kerberos or X509.<br>
<br>
<br>
> For the latter, we<br>
> need to have a way to lock down access to an individual resource in<br>
> Heat. This allows putting secrets in deployments and knowing that
only<br>
> the instance which has been deployed to will have access to the secrets.<br>
> I do see an optimization possible, which is to just create a user
for the<br>
> box that is given access to any deployments on the box. That would
make<br>
> sense if users are going to create many many deployments per server.
But<br>
> even at 10 per server, having 10 users is simpler than trying to manage<br>
> shared users and edit their authorization rules.<br>
><br>
> Now, I actually think that OAUTH tokens _are_ intended to be authorization<br>
> as well as authentication, so that is probably where the focus should<br>
> be long term. But really, you're talking about the same thing: a single<br>
> key lookup in keystone.<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>