On Thu, Jul 09, 2015 at 06:28:33AM -0400, Attila Fazekas wrote: > Hi, > > Heat creates a keystone user for every resource which uses a CFN_SIGNAL. > Heat also stores their AWS credentials in the heat.resource_data table.
This is true, a possible improvement might be to not store those credentials in the case where we only need them for e.g creating a pre-signed URL (just store the signed URL and not the secret key used to sign it). > These credentials/users are restricted to operate only on limited (1?) > resource, > with very limited operations (3?). Normally these resource users are member > of only > a special heat domain and tenant. True, we've tried to ensure any credentials expected to be deployed inside (implicitly untrusted) instances have a minima API surface accessible and are isolated from the stack owner. > Looks like heat has everything to have CFN/hashmac working without touching > the keystone service. > > Why heat needs to store anything in keystone regarding to the CFN_SIGNALS ? > Is these credentials supposed to be used anywhere else than on heat? Because keystone already provides the functionality we need, e.g the signature validation via the ec2tokens keystone API extension. If we chose not to use keystone, we'd have to take on the responsibility of reimplementing that auth functionality inside heat, which is something we've historically not wanted to do (auth is keystone's job, and we don't want to maintain the same code in two places). Also note that CFN_SIGNAL is only one method of signalling with heat, we also support normal token based authentication (keystone authtoken aka HEAT_SIGNAL), swift temp url's and recently zaqar queues. IMHO it makes no sense to reimplement all these transports and authentication mechanisms inside heat, thus we integrate with what is available instead. HTH, Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
