Bug 1235748

Copy/editing description from undercloud bug 

Description of problem:
Currently the overcloud heat isn't configured to use domain isolated users, with the consequence that the users associated with in-node signalling and metadata polling are all created in the default "admin" tenant (in the default domain), which is bad from a security isolation perspective.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Install overcloud
2. Inspect heat.conf and use python openstackclient to observe that the "heat" domain isn't created, and the heat.conf lacks the related stack_user_domain_id entry and username/password for the domain-admin user.
3. Deploy an overcloud, observe via keystoneclient or openstackclient that users are created in the admin project in the default domain.

Actual results:
The deployed nodes contain admin credentials in the default domain

Expected results:
All credentials deployed to the nodes via heat should be associated with users in the isolated "heat" domain, so the risk of abuse should a node become compromised is reduced.

Marking as a blocker as it is much the same as the undercloud version of the bug 

@Steve can you add a comment if I've missed anything

Created attachment 1043197 [details]
Upstream patch, updated for osp-director

The upstream patch as-is doesn't work for us (mainly because its missing updates to overcloud_controller_pacemaker.pp), I've tested a new version(attached), this now works but just needs to be updated so the "stack_domain_admin_password" doesn't default to "unset".

I also think its worth noting that for this approach to work we've had to tweak the puppet modules so they will be starting the keystone service, (which we have avoided up to now (so pacemaker could start them?)).

I think instead another option would be to create the domain with os-cloud-config which is consistent with how we create projects/endpoints etc.... If this is preferred I can work on it as soon as possible or finish the password setting for the original patch.

Giulio, can you review the puppet changes and pacemaker impact?

I think we can work on the upstream patch only and cherry-pick when done (eventually updating os_cloud_config as well)

This patch will fix the part about the password being unset
    https://review.gerrithub.io/237696

and the patch attached works but may not be the best solution, still looking into other solutions.

Two patches to tackle this are now on gerrit
    Ensure the heat domain user password it set
    https://code.engineering.redhat.com/gerrit/#/c/52506/
    This can be verified by checking "stack_domain_admin_password" in heat.conf, it should not be "unset"

    Configure heat to use a keystone domain
    https://code.engineering.redhat.com/gerrit/52507
    To verify you can look in the keystone user table to show heat created users not in the default domain

The heat template upstream is failing ci and wont pass until a new version of python-cliff, I've pulled cliff into delorean-master but it fails to build until this fix is merged
https://review.openstack.org/#/c/199052/

I've tried the heat-templates patch both upstream (with new python-cliff) and downstream and both worked.

Looks like this fails on the latest poodle HA job

https://rhos-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/RDO/view/rdo-manager/job/osp_director-none-7.1-rhos-7_director-poodle-rhel-7.1-virthost-minimal_ha-neutron-ml2-vxlan/36/consoleFull

http://pastebin.test.redhat.com/296245

possible dupe
https://bugzilla.redhat.com/show_bug.cgi?id=1241231

HA deployment failure logs avail at
http://file.rdu.redhat.com/~whayutin/BUGS/1235748/

Previous patch attempted to create resources from all nodes, https://review.openstack.org/#/c/180566/13 (patchset 13) should fix it.

*** Bug 1242079 has been marked as a duplicate of this bug. ***

Both patches were reverted yesterday as the deployment was failing when the keystone domain was being created.

It looks like the reason for the failure was due to controller clocks being out of sync, so I've rebased, retested and resubmitted the patches

Users are created when needed and deleted when the stack is removed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2015:1549