Bug 998599

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.

pull request for astapor, https://github.com/jsomara/astapor/pull/45

rebased pull request, https://github.com/redhat-openstack/astapor/pull/23

Rob,

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

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.

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.

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

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?

(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.

https://bugzilla.redhat.com/show_bug.cgi?id=1056798

This should be merged shortly:

https://github.com/redhat-openstack/astapor/pull/108

Merged

Documentation on the wiki: http://openstack.redhat.com/Securing_Services_Foreman

Text from pull request:



If ssl and freeipa are true then certificates are obtained using
certmonger.

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

Verified:devel

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.

http://rhn.redhat.com/errata/RHBA-2014-0213.html