Avoid needing admin role for stack create/delete

Discussion now indicates we should probably postpone any action on this issue, and track the progress of the keystone blueprints for grizzly, as it looks like there are some changes which may help resolve this

defocused waiting on keystone "sudo" type feature hopefully in H cycle

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

What is the status on this bug?

Why not use the admin keystone credentials that needs to be configured anyway?

All these ideas about RBAC, trusts etc are good, but why not just fix the stuff with the code that's already there? This makes heat basically unusable for any real scenario other than "developer plays with heat on his/her own machine".

> Why not use the admin keystone credentials that needs to be configured anyway?

For 2 reasons:
- only the API daemons are configured for those credentials, not the engine
- those credentials belong in a completely different tenant/project to the user who is launching the stack.

Also when solving this, keep in mind that the ec2_user create may not be allowed by Keystone when you are configured with LDAP Identity driver. With this config the following two scenarios will fail:
1) keystone.conf setting for ldap: user_allow_create=False
2) The authenticated user from ldap does not have privilege in LDAP to create other users in ldap.

Ref: https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample

We are currently blocked by these scenarios. I'm not familiar with how to add use-case requirements into the blueprints and hope this helps to capture some needs for this fix.

Fix proposed to branch: master
Review: https://review.openstack.org/62438

Fix proposed to branch: master
Review: https://review.openstack.org/62439

Fix proposed to branch: master
Review: https://review.openstack.org/62440

Fix proposed to branch: master
Review: https://review.openstack.org/62441

Reviewed: https://review.openstack.org/62440
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=ba9c290212363efc242b659826a7f9d18ac1fed5
Submitter: Jenkins
Branch: master

commit ba9c290212363efc242b659826a7f9d18ac1fed5
Author: Steven Hardy <email address hidden>
Date: Mon Dec 16 17:17:13 2013 +0000

    SignalResponder store access/secret in resource data

    We need to stop relying on the logic in heat_keystoneclient which
    assumes there is only one keypair per user, as this assumption
    may not remain true in future.

    So instead, store the access/secret key in the DB as resource data,
    which is probably better from a performance perspective anyway, and
    will also allow SignalResponder subclasses to potentially override
    the default credentials implementation more easily.

    Change-Id: I7952181f30c94848acf358ab34cf17b6281d43ac
    Partial-Bug: #1089261
    blueprint: instance-users

Reviewed: https://review.openstack.org/62441
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=cd853f699496fc7d7e98d4c5cbe7deda8eb5a360
Submitter: Jenkins
Branch: master

commit cd853f699496fc7d7e98d4c5cbe7deda8eb5a360
Author: Steven Hardy <email address hidden>
Date: Mon Dec 16 17:31:11 2013 +0000

    heat_keystoneclient revise get_ec2_keypair

    Modify get_ec2_keypair so it's no longer making assumptions about the
    number of keypairs a user has, instead we provide create_ec2_keypair,
    which just creates and returns a keypair, and get_ec2_keypair just gets
    a specified keypair by user and access key ID.

    It's now up to the calling resources to manage the lifecycle of the keypairs
    (which they should be doing anyway..). Also make the user_id optional.

    Change-Id: I28aa0c2d764b9e957302269598a5910346363d0f
    Related-Bug: #1089261
    blueprint: instance-users

Fix proposed to branch: master
Review: https://review.openstack.org/72763

Reviewed: https://review.openstack.org/71210
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=4b1969ac5b69f2cf95cceb2e947da4342395a931
Submitter: Jenkins
Branch: master

commit 4b1969ac5b69f2cf95cceb2e947da4342395a931
Author: Steven Hardy <email address hidden>
Date: Mon Feb 10 18:09:41 2014 +0000

    migrate StackUser base class to stack domain users

    Migrates the user/credential interfaces to stack domain users,
    so the user is created in the instance-user domain not the
    domain of the user creating the stack.

    Partial-Bug: #1089261
    blueprint: instance-users
    Change-Id: If4c57144a32050a8d0b145444a84896cce53908b

Reviewed: https://review.openstack.org/72763
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=4e36926d0161120e972e18ddfca31cf8a4a37e96
Submitter: Jenkins
Branch: master

commit 4e36926d0161120e972e18ddfca31cf8a4a37e96
Author: Steven Hardy <email address hidden>
Date: Tue Feb 11 12:37:20 2014 +0000

    migrate User/AccessKey resources to StackUser base class

    migrate the User/AccessKey resources to use the StackUser
    base class, and therefore convert to stack domain users.

    Note that becuse the User resource inherits from StackUser,
    and the keypair is managed by that resource now, we have
    to update both resources at the same time, as it's not
    possible to update individually and keep them both working.

    This (finally! :) resolves bug #1089261 and allows all
    resources to be created even if the user creating the
    stack doesn't have the required roles to create keystone
    users.

    Closes-Bug: #1089261
    blueprint: instance-users

    Change-Id: I854644e7669150521f8904cdb76c292519ef4167