To Reproduce Steps to reproduce the behavior:

1. Deploy overcloud
2.  

Expected behavior

• According to the hardening guide, section 14.8 [0], HSTS is enabled by default

Bug impact

• HSTS is configured in Horizon, but not in HAproxy, which results in security scans still detecting and reporting it on the public endpoints

Known workaround

• Apply the yaml block indicated in [1]

Additional context

• The Horizon local settings indicated in the hardening guide are only relevant for horizon, I believe it is HAproxy who should present the Strict-Transport-Security header, and this is not added by default.
• Documentation should mention:
  1. The need to implement an additional configuration in HAproxy
  2. How to validate using command line, rather than just pointing to what the configuration should look like.

Checking HSTS in an environment that is configured with SSL for public endpoints before implementing the workaround:

[stack@director ~]$ date ; curl -s -D- https://overcloud.keller171.lab | grep -i strict
Fri Mar  7 15:21:49 CET 2025
[stack@director ~]$  

Checking on the same environment after applying the configuration mentioned in [1]:

[stack@director ~]$ cat templates/haproxy.yaml 
parameter_defaults:
  ControllerExtraConfig:
    tripleo::haproxy::horizon::options:
      http-response:
        - 'replace-header Location http://(.*) https://\1'
        - 'set-header Strict-Transport-Security "max-age=300; includeSubDomains"'
[stack@director ~]$ 
[stack@director ~]$ date ; curl -s -D- https://overcloud.keller171.lab | grep -i strict
Fri Mar  7 16:14:54 CET 2025
strict-transport-security: max-age=300; includeSubDomains
[stack@director ~]$    

 [0] https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/hardening_red_hat_openstack_platform/index#http-strict-transport-security-hsts-_hardening-the-dashboard-service

 [1]https://access.redhat.com/solutions/6957426