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:
That configuration line has been removed intentionally, because it prevents the non-https configurations from working.
So it is by design then? How does customer achieve the https termination when using a external load balancer then?
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.
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?
The customer is using Director for the deployment here.
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