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 mdel...@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 <ayo...@redhat.com> To: openstack-dev@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev