Comment 3 for bug 1089261

So it looks like ayoung is implementing a trusts feature in keystone for grizzly, which may in due course allow us to avoid creating an actual user for in-instance credentials, instead creating a "trust token" related to the the user owning the stack, such that authentication may be performed from instances "on behalf of" the user but without actually using their credentials:

https://blueprints.launchpad.net/keystone/+spec/trusts

This may still not be exactly what we want though, since ideally we need the in-instance users to be separated from the (potentially privileged) user owning the stack, such that they have the most minimal set of privileges possible.

Currently I'm implementing support of a policy.json, so that the in instance users (which are assigned the heat_stack_user role) are denied access to all-but-one API call, so whatever credentials mechanism is used will also need to be able to support roles so RBAC policy can still be implemented to lock down the in-instance users.

Also we need whatever credentials we create to allow generation of an ec2 keypair

Several questions here, I'll see if I can get some feedback from ayoung about whether trusts are likely to solve our problem