Bug 998599 - Install an OpenStack deployment with secure communication using Foreman
Summary: Install an OpenStack deployment with secure communication using Foreman
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-foreman-installer
Version: 4.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: z2
: 4.0
Assignee: Rob Crittenden
QA Contact: Omri Hochman
Keywords: FutureFeature, OtherQA, ZStream
Depends On: 1010308 1040162
Blocks: RHOS40RFE 998623 1010310
TreeView+ depends on / blocked
Reported: 2013-08-19 14:53 UTC by Charles Crouch
Modified: 2016-04-27 00:58 UTC (History)
12 users (show)

This enhancement implements SSL encryption for the mysql and qpid services. In addition, SSL is enabled for Dashboard. 

Consequently, qpid messages and mysql queries are hardened against snooping even on the internal network. SSL implementation in Dashboard assists with protecting user credentials sent from browser sessions.
Clone Of:
Last Closed: 2014-03-04 20:12:32 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0213 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform 4 Bug Fix and Enhancement Advisory 2014-03-05 01:11:55 UTC

Description Charles Crouch 2013-08-19 14:53:24 UTC
The goal here is to use the Foreman which is part of RHOS to deploy the core OpenStack controller services (and their dependencies) such that all communication is done securely. This includes the following tasks from https://home.corp.redhat.com/wiki/rdo-usability-sprint

-Use Foreman to deploy RDO with secured qpid (SSL)
-Use Foreman to deploy RDO with secured API services (https/Apache)

Comment 2 Rob Crittenden 2013-10-04 18:52:34 UTC
Upstream review to make SSL possible in Horizon, https://review.openstack.org/#/c/49799/ . This makes use of the puppet-apache 0.4.0 module. The master tree has more capabilities but I had to stick with the lowest-common denominator.

Once this is accepted we can turn it on in the Foreman controller hostgroup.

Comment 3 Rob Crittenden 2013-10-04 19:51:16 UTC
pull request for astapor, https://github.com/jsomara/astapor/pull/45

Comment 4 Rob Crittenden 2013-10-21 19:48:45 UTC
rebased pull request, https://github.com/redhat-openstack/astapor/pull/23

Comment 5 Mike Orazi 2014-01-22 22:28:27 UTC

Couple of comments:
- Can you secure the individual service endpoints in addition to mysql, qpid, horizon?
- Can you make sure this applies to the other existing host groups as well (the neutron variants + the more special purpose nodes for Storage, etc)?

- Mike

Comment 6 Dmitri Pal 2014-01-22 22:38:53 UTC
Any remote communication between any given two components can and should be potentially secured if there is not security in place. But each such channel needs to be identified and implemented based on what the peers participating in this connection are capable of supporting.
What is the protocol used for service end points? What are they? Who connects to whom?
Generally this is the effort that we (IdM team) will continue on working for different components in OpenStack.

Comment 7 Perry Myers 2014-01-22 22:41:01 UTC
API endpoints are REST based, so it would be converting http to https.  However, API endpoints are not served up by something like apache (which is easily secured this way). 

ayoung, iirc had some thoughts about how to secure the API endpoints, we may want to get his ideas here.

Comment 8 Dmitri Pal 2014-01-22 22:51:49 UTC
I do not think apache is the requirement here. We are talking about SSL not about Kerberos. It should be nice to be able to use Apache because then you can you different schemes at your discretion but with eventlet I suspect SSL can be easily used.   http://eventlet.net/doc/ssl.html

Comment 9 Perry Myers 2014-01-22 22:55:00 UTC
Right, I just thought I remembered ayoung saying there were some complications or trickiness with trying to secure services provided by eventlet...  But I also could just be misremembering.  My conversations with ayoung on this were a long time ago :)

just talked to rcrit, and agree with him that we can deliver patches and track securing of mysql/qpid/horizon separately from tracking securing of the REST services.

Rob, can you create a new bug to track securing of the API services?

Comment 10 Rob Crittenden 2014-01-22 22:56:21 UTC
(In reply to Mike Orazi from comment #5)
> Rob,
> Couple of comments:
> - Can you secure the individual service endpoints in addition to mysql,
> qpid, horizon?

We can eventually assuming the upstream code works as advertised, which it always doesn't. I had to make significant changes just to get qpid/mysql working.

> - Can you make sure this applies to the other existing host groups as well
> (the neutron variants + the more special purpose nodes for Storage, etc)?

Yes. When I started this nova was the only option. I can look into the other hostgroups. It is probably largely a matter of cut-and-paste, only testing will tell.

Comment 11 Rob Crittenden 2014-01-22 23:09:02 UTC

Comment 12 Jason Guiditta 2014-02-04 15:47:11 UTC
This should be merged shortly:


Comment 13 Jason Guiditta 2014-02-14 16:08:13 UTC

Comment 15 Rob Crittenden 2014-02-17 19:07:06 UTC
Documentation on the wiki: http://openstack.redhat.com/Securing_Services_Foreman

Comment 16 Jason Guiditta 2014-02-19 15:36:52 UTC
Text from pull request:

If ssl and freeipa are true then certificates are obtained using

If ssl is true and freeipa is false then the the mysql and qpid
certificates and keys need to be passed in as arguments.

Horizon is configured to use ssl on the public interface FQDN if
ssl is true.

Secure qpid and mysql with SSL for nova, keystone, glance, ceilometer,
cinder and heat.

The following Foreman hostgroups support SSL:

Compute (Neutron)
Compute (Nova Network)
Controller (Neutron)
Controller (Nova Network)
LVM Block Storage
Neutron Networker

Comment 18 Rob Crittenden 2014-02-27 16:21:08 UTC

Comment 20 errata-xmlrpc 2014-03-04 20:12:32 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.


Note You need to log in before you can comment on or make changes to this bug.