Open Stack

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