Heat should use trusts by default

[Steven Hardy]

We should switch to using deferred_auth_method=trusts by default, for the following reasons:

- It's more secure, we won't have to store username/password anymore
- It's better for users, because they won't have to provide a username/password anymore, e.g the box in horizon where we force them to enter a password even though horizon is already passing us a token.

The trusts functionality was merged back in Havana, and IME it's ready, so we should get things passing in the gate with the updated default, and check if updates are required to avoid breaking existing heat users (e.g tripleo)

[Steven Hardy (shardy)]

So action plan to get this in:

1. Get the rest of the instance-users patches reviewed/merged

https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bug/1089261,n,z

2. Get stevebakers tempest change in which moves the heat tests to use the demo user:

https://review.openstack.org/#/c/76981/

3. Get a devstack change in which creates the heat_stack_owner role and gives it to the demo user (this is the role we delegate via the trust by default in heat.conf)

4. Get a heat change in which flips the default (easy in theory but there's test fallout to deal with, perhaps we set the default back to password for most of the unit tests)

5. Get a patch into horizon which makes the password box optional (defaulted to off, to match the new heat default)

[Steven Hardy (shardy)]

Additional task - need some upgrade testing to ensure users migrating from password-> trusts will work, the code should just use whatever is stored in user_creds but needs ideally a new test to prove all works as expected.

[Clint Byrum (clint-fewbar)]

Excerpts from Steven Hardy's message of 2014-02-28 15:07:46 UTC:
> Additional task - need some upgrade testing to ensure users migrating
> from password-> trusts will work, the code should just use whatever is
> stored in user_creds but needs ideally a new test to prove all works as
> expected.
>

+1 from me! The prospect of being able to spin up TripleO stacks as a
non-admin is quite attractive from a data center management perspective.
It is good to be able to separate "people who can spin up clouds" from
"people who can destroy the entire infrastructure".

[Steven Hardy (shardy)]

@Clint: Note this particular change won't affect the admin requirement, it will only remove the requirement to pass a password so we can work correctly with just a token provided (still a nice improvement IMO :)

The admin thing will be solved when we merge the remaining instance-users patches:

https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bug/1089261,n,z

When all of those are merged then bug #1089261 will be resolved, reviews appreciated! :)

[Steven Hardy (shardy)]

Ok, after all the pushback related to the domain users change I'm not sure how to proceed with this :(

Flipping the deferred_auth_method method to trusts is easy enough (apart from the unit test fallout), but then it is expected that the role referred to in trusts_delegated_roles will exist, and that every user creating a stack will have it (or whatever deployers put in that list), since to delegate via trusts you must have a role to delegate.

I believe the fallback for existing DB contents will be OK, but the fallback in the event deferred_auth_method=trusts and the role's aren't right will probably be unacceptable to those trunk-chasing heat.

Clint, perhaps you can provide feedback on your preferred strategy for making this tranition?

For now I think we'll have to make do with a patch which makes it the default in devstack (with a variable folks can easily use to switch back), at least then we'll be getting some wider usage and taking a step towards making it the default.

I'll remove the Icehouse milestone for this.

[Steve Baker (steve-stevebaker)]

If deferred_auth_method=trusts could it check for the existence of trusts_delegated_roles and if they don't exist then print out a big fat warning then revert to a runtime conf setting of password?

[Clint Byrum (clint-fewbar)]

Excerpts from Steve Baker's message of 2014-03-12 19:58:09 UTC:
> If deferred_auth_method=trusts could it check for the existence of
> trusts_delegated_roles and if they don't exist then print out a big fat
> warning then revert to a runtime conf setting of password?
>

I think this is a good path to take. Note that the role recommendation
in the docs and in the warning should include the fact that all normal
heat users must be added to this role once it is created and configured
in Heat, or they won't be able to create stacks anymore.

[Steven Hardy (shardy)]

Ok, sounds like we have a plan, I'll work up an "auto trusts" patch in the next couple of days.

Also I was thinking of ways we could only create/store a trust when deferred operations are actually required (i.e when parser.Stack.requires_deferred_auth is True), then the impact of any misconfiguration would be reduced, as only stacks which actually require deferred operations would fail.

The only slight issue with that is we're currently (ab)using the stored context in other ways, (e.g see https://review.openstack.org/#/c/79824/), so I'm not really sure that flag means anything - we probably need to eliminate the stack-context-escalation path except for where explicitly required by resources in the stack before we can sensibly do conditionaly creation of the trust.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit 2cb0e674f3e5ace44b1b1e8ffc5c19a6af2166be
Author: Ethan Lynn <email address hidden>
Date: Wed Mar 18 20:09:44 2015 +0800

    Switch config deferred_auth_method to trusts by default

    Change deferred_auth_method to trusts by default,
    and fixes unittests error.

    Closes-Bug: #1286157
    Change-Id: Ifebbc1b5d71458d8502e08bcacbd94b7437128f9