Bug 1472306

Summary:	Horizon overcloud deploy with external load balancer missing 'HTTP_X_FORWARDED_PROTO' configuration.
Product:	Red Hat OpenStack	Reporter:	Benjamin Schmaus <bschmaus>
Component:	puppet-horizon	Assignee:	Radomir Dopieralski <rdopiera>
Status:	CLOSED WORKSFORME	QA Contact:	nlevinki <nlevinki>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	10.0 (Newton)	CC:	beth.white, bschmaus, jjoyce, jschluet, rdopiera, slinaber, tvignaud
Target Milestone:	---	Keywords:	Triaged
Target Release:	12.0 (Pike)
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1472887 (view as bug list)		Environment:
Last Closed:	2017-07-26 14:57:59 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:
Bug Depends On:
Bug Blocks:	1472887

Description Benjamin Schmaus 2017-07-18 12:27:59 UTC

Description of problem:

When we deploy an overcloud using an external load balancer and terminate SSL on the load balancer, the '/etc/openstack-dashboard/local_settings' configuration file does not have the following  line uncommented:

---
# Set SSL proxy settings:
# Pass this header from the proxy after terminating the SSL,
# and don't forget to strip it from the client's request.
# For more information see:
# https://docs.djangoproject.com/en/1.8/ref/settings/#secure-proxy-ssl-header
#SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
---

This causes a reply with HTTP URLs instead of HTTPS URLs.


Version-Release number of selected component (if applicable):
OSP10

How reproducible:
100%

Steps to Reproduce:
1.Deploy with external load balancer and access URLS in horizon.
2.
3.

Actual results:
http

Expected results:
https

Additional info:

Comment 2 Radomir Dopieralski 2017-07-20 14:55:18 UTC

That configuration line has been removed intentionally, because it prevents the non-https configurations from working.

Comment 3 Benjamin Schmaus 2017-07-20 15:00:55 UTC

So it is by design then?  How does customer achieve the https termination when using a external load balancer then?

Comment 4 Radomir Dopieralski 2017-07-20 19:39:54 UTC

I don't think anybody actually "designed" this. I think this is just an example of a conflict of interest, where to fix one bug we introduced a regression in other place, and to fix that we regressed the original bug in turn.

What is needed is a step back and actual design to make that option be enabled only when it is actually required. I'm not sure yet if this is easily possible right now, but I will find out.

Comment 5 Radomir Dopieralski 2017-07-21 11:50:00 UTC

I'm sorry, I started looking into this issue, and I realized that I confused it with a different issue, namely the SESSION_COOKIE_SECURE setting.

Nevertheless, I'm looking into the puppet-horizon and tripleo-heat-templates files and I can see that the enable_secure_proxy_ssl_header setting that controls this is enabled by default.

Can you tell me how was this instance installed? Did you use tripleo/director, or packstack or something else?

Comment 6 Benjamin Schmaus 2017-07-21 12:12:17 UTC

The customer is using Director for the deployment here.

Comment 7 Radomir Dopieralski 2017-07-26 14:57:59 UTC

I can't reproduce this problem with OSP12, it seems that it has been fixed in OSP11 judging by this line: https://github.com/openstack/puppet-horizon/blob/stable/ocata/spec/classes/horizon_init_spec.rb#L131