Bug 1235748

Summary: Overcloud heat should use stack domain users
Product: Red Hat OpenStack Reporter: Derek Higgins <derekh>
Component: rhosp-directorAssignee: Derek Higgins <derekh>
Status: CLOSED ERRATA QA Contact: Amit Ugol <augol>
Severity: high Docs Contact:
Priority: high    
Version: DirectorCC: derekh, gfidente, gmollett, jason.dobies, jslagle, mburns, rhel-osp-director-maint, rlandy, rrosa, shardy, tdunnon, whayutin
Target Milestone: gaKeywords: Automation
Target Release: Director   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: python-rdomanager-oscplugin-0.0.8-38.el7ost openstack-tripleo-heat-templates-0.8.6-41.el7ost Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-05 13:56:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Upstream patch, updated for osp-director none

Description Derek Higgins 2015-06-25 15:59:27 UTC
We have recently worked on the undercloud to ensure heat is configured to use a user in a keystone domain (https://bugzilla.redhat.com/show_bug.cgi?id=1231965), we need to do something similar in the overcloud

A patch has been proposed for this in upstream t-h-t
https://review.openstack.org/#/c/180566/

but it has yet to be merged

Comment 3 Derek Higgins 2015-06-25 16:01:25 UTC
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.

Comment 4 Derek Higgins 2015-06-25 16:05:00 UTC
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

Comment 5 Derek Higgins 2015-06-25 16:39:11 UTC
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.

Comment 6 Mike Burns 2015-06-26 03:15:00 UTC
Giulio, can you review the puppet changes and pacemaker impact?

Comment 7 Giulio Fidente 2015-06-26 11:51:05 UTC
I think we can work on the upstream patch only and cherry-pick when done (eventually updating os_cloud_config as well)

Comment 8 Derek Higgins 2015-06-26 12:19:53 UTC
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.

Comment 19 Derek Higgins 2015-07-07 16:19:03 UTC
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.

Comment 21 wes hayutin 2015-07-10 02:12:42 UTC
possible dupe
https://bugzilla.redhat.com/show_bug.cgi?id=1241231

Comment 22 wes hayutin 2015-07-10 02:21:59 UTC
HA deployment failure logs avail at
http://file.rdu.redhat.com/~whayutin/BUGS/1235748/

Comment 23 Giulio Fidente 2015-07-10 02:53:37 UTC
Previous patch attempted to create resources from all nodes, https://review.openstack.org/#/c/180566/13 (patchset 13) should fix it.

Comment 27 Mike Burns 2015-07-13 14:45:54 UTC
*** Bug 1242079 has been marked as a duplicate of this bug. ***

Comment 28 Derek Higgins 2015-07-14 22:58:39 UTC
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

Comment 32 Amit Ugol 2015-07-21 14:50:18 UTC
Users are created when needed and deleted when the stack is removed.

Comment 34 errata-xmlrpc 2015-08-05 13:56:21 UTC
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