Bug 1307045 - [Docs] [Director] SSL enabled external load balancer deployment
[Docs] [Director] SSL enabled external load balancer deployment
Status: POST
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
unspecified Severity high
: ga
: 7.0 (Kilo)
Assigned To: Dan Macpherson
RHOS Documentation Team
: Documentation, ZStream
Depends On:
  Show dependency treegraph
Reported: 2016-02-12 09:49 EST by Marius Cornea
Modified: 2017-09-29 16:28 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Release Note
Doc Text:
In order to configure SSL on the overcloud with an external loadbalancer, it is necessary to pass an environment file containing _only_ the EndpointMap from environments/enable-tls.yaml. The resulting environment file should look something like: parameter_defaults: EndpointMap: CeilometerAdmin: {protocol: 'http', port: '8777', host: 'IP_ADDRESS'} CeilometerInternal: {protocol: 'http', port: '8777', host: 'IP_ADDRESS'} CeilometerPublic: {protocol: 'https', port: '13777', host: 'CLOUDNAME'} [entries for all the endpoints] Nothing else from enable-tls.yaml should be included. Otherwise the same information regarding things like self-signed certificates and DNS vs. direct IP endpoints applies to an external loadbalancer SSL setup as a regular SSL deployment. Note that the external loadbalancer must be configured to listen on the ports defined in the EndpointMap.
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marius Cornea 2016-02-12 09:49:05 EST
Description of problem:
With OSP-d 7.3 we introduced SSL support for the overcloud public endoints. We should also get instructions for how to enable SSL when deploying with an external load balancer.

Here are the SSL docs for the regular deployment:

When deploying with an external load balancer we need to basically combine the ssl environments and the external load balancer environment files. A deploy command example is:

openstack overcloud deploy --templates ~/templates/my-overcloud  \
-e ~/templates/my-overcloud/environments/network-isolation.yaml \
-e ~/templates/network-environment.yaml \
-e ~/templates/enable-tls-external-lb.yaml \
-e ~/templates/inject-trust-anchor.yaml  \
-e ~/templates/my-overcloud/environments/external-loadbalancer-vip.yaml \
-e ~/templates/external-lb.yaml \
-e /home/stack/templates/firstboot-environment.yaml \
--control-scale 3 \
--compute-scale 1 \
--ntp-server \
--libvirt-type qemu 

enable-tls-external-lb.yam can contain an emtpy string for the SSLCertificate, SSLIntermediateCertificate and SSLKey parameters because they will be stored on the loadbalanacer itself.

inject-trust-anchor.yaml should contain the root ca certificate. 

This type of the deployment corresponds to the following scenario: SSL on load balancer. Configure standard (non-SSL) on the controllers, still using the external load balancer environment. 
Configure the external SSL load balancer to terminate the SSL, and use
basic unencrypted HTTP between the load balancer and the controllers.
Comment 2 Marius Cornea 2016-02-18 14:41:40 EST
Ben, could you please advise on the proper content of enable-tls.yaml when using an external load balancer? 

According to my tests passing an enable-tls.yaml that doesn't contain the SSLCertificate, SSLIntermediateCertificate and SSLKey parameters, only the EndpointMap fails with: 

Deploying templates in the directory /home/stack/templates/my-overcloud
Stack failed with status: Resource CREATE failed: resources[1]: resources.Controller.Property error: resources.NodeTLSData.properties: Property SSLKey not assigned
ERROR: openstack Heat Stack create failed.

The environment looks like this:
    [endpoint map entries from enable-tls.yaml]

If it contains the parameters as empty strings then deployment completes ok:
  SSLCertificate: ''
  SSLIntermediateCertificate: ''
  SSLKey: ''
    [endpoint map entries from enable-tls.yaml]

Also if the parameters contain the certificates and the key as with a regular deployment then it completes ok.
Comment 3 Ben Nemec 2016-02-18 15:34:35 EST
It should not be looking for those parameters with just the EndpointMap.  Do you have the resource_registry entry from enable-tls.yaml somewhere also?  That's what tells Heat to look for the certificate parameters.
Comment 4 Ben Nemec 2016-02-18 15:35:46 EST
Moving the proposed doc text from the other bug to this one.
Comment 5 Marius Cornea 2016-02-18 16:20:12 EST
My bad, I was still having the resource_registry entry in the enable-tls.yaml. Thanks for the help.

Here is the environment that I used to pass the deployment:

stack@instack:~>>> cat ~/templates/enable-tls-external-lb.yaml
    CeilometerAdmin: {protocol: 'http', port: '8777', host: 'IP_ADDRESS'}
    CeilometerInternal: {protocol: 'http', port: '8777', host: 'IP_ADDRESS'}
    CeilometerPublic: {protocol: 'https', port: '13777', host: 'CLOUDNAME'}
    CinderAdmin: {protocol: 'http', port: '8776', host: 'IP_ADDRESS'}
    CinderInternal: {protocol: 'http', port: '8776', host: 'IP_ADDRESS'}
    CinderPublic: {protocol: 'https', port: '13776', host: 'CLOUDNAME'}
    GlanceAdmin: {protocol: 'http', port: '9292', host: 'IP_ADDRESS'}
    GlanceInternal: {protocol: 'http', port: '9292', host: 'IP_ADDRESS'}
    GlancePublic: {protocol: 'https', port: '13292', host: 'CLOUDNAME'}
    GlanceRegistryAdmin: {protocol: 'http', port: '9191', host: 'IP_ADDRESS'}
    GlanceRegistryInternal: {protocol: 'http', port: '9191', host: 'IP_ADDRESS'}
    GlanceRegistryPublic: {protocol: 'https', port: '9191', host: 'IP_ADDRESS'} # Not set on the loadbalancer yet.
    HeatAdmin: {protocol: 'http', port: '8004', host: 'IP_ADDRESS'}
    HeatInternal: {protocol: 'http', port: '8004', host: 'IP_ADDRESS'}
    HeatPublic: {protocol: 'https', port: '13004', host: 'CLOUDNAME'}
    HorizonPublic: {protocol: 'https', port: '443', host: 'CLOUDNAME'}
    KeystoneAdmin: {protocol: 'http', port: '35357', host: 'IP_ADDRESS'}
    KeystoneInternal: {protocol: 'http', port: '5000', host: 'IP_ADDRESS'}
    KeystonePublic: {protocol: 'https', port: '13000', host: 'CLOUDNAME'}
    NeutronAdmin: {protocol: 'http', port: '9696', host: 'IP_ADDRESS'}
    NeutronInternal: {protocol: 'http', port: '9696', host: 'IP_ADDRESS'}
    NeutronPublic: {protocol: 'https', port: '13696', host: 'CLOUDNAME'}
    NovaAdmin: {protocol: 'http', port: '8774', host: 'IP_ADDRESS'}
    NovaInternal: {protocol: 'http', port: '8774', host: 'IP_ADDRESS'}
    NovaPublic: {protocol: 'https', port: '13774', host: 'CLOUDNAME'}
    NovaEC2Admin: {protocol: 'http', port: '8773', host: 'IP_ADDRESS'}
    NovaEC2Internal: {protocol: 'http', port: '8773', host: 'IP_ADDRESS'}
    NovaEC2Public: {protocol: 'https', port: '13773', host: 'CLOUDNAME'}
    NovaVNCProxyAdmin: {protocol: 'http', port: '6080', host: 'IP_ADDRESS'}
    NovaVNCProxyInternal: {protocol: 'http', port: '6080', host: 'IP_ADDRESS'}
    NovaVNCProxyPublic: {protocol: 'https', port: '13080', host: 'CLOUDNAME'}
    SwiftAdmin: {protocol: 'http', port: '8080', host: 'IP_ADDRESS'}
    SwiftInternal: {protocol: 'http', port: '8080', host: 'IP_ADDRESS'}
    SwiftPublic: {protocol: 'https', port: '13808', host: 'CLOUDNAME'}
Comment 6 Ben Nemec 2016-02-18 17:07:53 EST
Yeah, that should work.  Maybe the doc text should explicitly say not to include the resource_registry?
Comment 7 Dan Macpherson 2017-09-12 01:33:37 EDT
Was looking through my backlog and found this BZ.

I revised the Ext LB Guide since the environment files have changed for OSP10. For Ext LB, you no longer need the enable-tls.yaml file. However the endpoint map has been moved to its own file (or rather files -- one for DNS and one for IP). Plus you still need the file to inject the CA.

Here's the revised content:


@Ben and Marius -- How does it look? Anything further we need to add to this section?
Comment 8 Ben Nemec 2017-09-29 16:28:08 EDT
I've never actually deployed with an external loadbalancer, but the process sounds right to me.

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