Bug 1307045

Summary:	[Docs] [Director] SSL enabled external load balancer deployment
Product:	Red Hat OpenStack	Reporter:	Marius Cornea <mcornea>
Component:	documentation	Assignee:	Dan Macpherson <dmacpher>
Status:	CLOSED CURRENTRELEASE	QA Contact:	RHOS Documentation Team <rhos-docs>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	7.0 (Kilo)	CC:	bnemec, dmacpher, mburns, mcornea, srevivo
Target Milestone:	ga	Keywords:	Documentation, ZStream
Target Release:	7.0 (Kilo)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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:		Environment:
Last Closed:	2018-08-06 04:43:54 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:
Embargoed:

Description Marius Cornea 2016-02-12 14:49:05 UTC

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:
http://docs-draft.openstack.org/06/265006/3/check/gate-tripleo-docs-docs/379ec1c//doc/build/html/advanced_deployment/ssl.html

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 10.5.26.10 \
--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 19:41:40 UTC

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:
parameter_defaults:
  EndpointMap:
    [endpoint map entries from enable-tls.yaml]

If it contains the parameters as empty strings then deployment completes ok:
parameter_defaults:
  SSLCertificate: ''
  SSLIntermediateCertificate: ''
  SSLKey: ''
  EndpointMap:
    [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 20:34:35 UTC

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 20:35:46 UTC

Moving the proposed doc text from the other bug to this one.

Comment 5 Marius Cornea 2016-02-18 21:20:12 UTC

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
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'}
    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 22:07:53 UTC

Yeah, that should work.  Maybe the doc text should explicitly say not to include the resource_registry?

Comment 7 Dan Macpherson 2017-09-12 05:33:37 UTC

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:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html-single/external_load_balancing_for_the_overcloud/#configuring_ssl_for_load_balancing

@Ben and Marius -- How does it look? Anything further we need to add to this section?

Comment 8 Ben Nemec 2017-09-29 20:28:08 UTC

I've never actually deployed with an external loadbalancer, but the process sounds right to me.

Comment 9 Dan Macpherson 2018-08-06 04:43:54 UTC

Closing this BZ as it appears to be resolved.