|Summary:||Overcloud heat should use stack domain users|
|Product:||Red Hat OpenStack||Reporter:||Derek Higgins <derekh>|
|Component:||rhosp-director||Assignee:||Derek Higgins <derekh>|
|Status:||CLOSED ERRATA||QA Contact:||Amit Ugol <augol>|
|Version:||Director||CC:||derekh, gfidente, gmollett, jason.dobies, jslagle, mburns, rhel-osp-director-maint, rlandy, rrosa, shardy, tdunnon, whayutin|
|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:||---|
|Last Closed:||2015-08-05 13:56:21 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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 20 wes hayutin 2015-07-10 02:11:31 UTC
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