openstack/openstack-ansible-haproxy_server - openstack-ansible-haproxy_server - OpenDev: Free Software Needs Free Tools

In case of defining different IP address for SSH and Management
network in metal scenario, as described in [1], you get SSH address
defined as `ansible_host`, which results in HAProxy configuring
backends on SSH address rather then management one, where
service is actually listening.
We use `ansible_host` as a fallback for non-OSA usage of the role.
[1] https://docs.openstack.org/openstack-ansible/latest/reference/inventory/configure-inventory.html#having-ssh-network-different-from-openstack-management-network
Change-Id: Id35480d5d0cf6316e31fe1b287421bfb56e20685
Signed-off-by: Dmitriy Rabotyagov <dmitriy.rabotyagov@cleura.com>

Change-Id: Ifc4feeffc951ec03745bf65d51db5e4917f1be29

Currently Let's Encrypt is using `haproxy_bind_external_lb_vip_address`
to identify naming of resulting certificate which might not match with
expectations, as all other parts of code already do use
`haproxy_vip_binds`
for calculating resulting TLS path.
This patch introduces `type` key for `haproxy_vip_binds` which is used
to identify for which frontends Let's Encrypt certificate should be used
as in most scenarios it's not gonna be issued for "internal" VIPs anyway
due to dns-01 requirement.
Also moving to single "source of truth" for VIP bindings allows to
override and have control over this behaviour.
Change-Id: Id07d9a0ea270d613b37b6adfa373d01a47f7421f

Effectively haproxy_tls_vip_binds was influencing not only TLS-related
binds but also non-TLS ones. It's naming was picked in a misleading way
from start, as a lot of logic for the variable was around TLS
implementation. Though it has a global effect and this should be
reflected in it's name.
Change-Id: I2f28d0ab033eff96cc2bc09db917bedb387013e8

In case frontend/backend are configured in TCP mode there is no reason
to supply a SSL configuration for such frontend.
With that we also align usage of `request_option` variable which is
anyway defined out of `service.haproxy_balance_type` but with provided
default value.
Change-Id: I5dff5aadc546d2984c1295e89b67b35a34254237

This directive is deprecated in haproxy 2.5. See
https://docs.haproxy.org/2.5/configuration.html#3.1-stats%20bind-process
Change-Id: I600e6a07d14deb10823ebe005ac417a601930f68

HTX became the default in haproxy 2.0 and the config option
is now deprecated.
Change-Id: Id83ad286676cc51ba874f0ca860c778dbebc0be1

We do allow to supply haproxy_backend_nodes as list of mappings rather
the regular list, which supports `ip_addr`, `name` and `backend_port` keys.
However, we do verify hostvars[host_name] and try to set ip_addr regardless
if this needed or not.
During hostvars[host_name] request Ansible tries to fetch all host variables
and resolve some of them, which not always can be possible or preffered
in some scenarios.
Good example of that would be Mozilla SOPS [1] encrypted variables for
specific host or group, which can not be decrypted by some operators.
In the meanwhile they can be eligible to configure haproxy frontend/backend
for this service. So we should have a way to avoid asking for specific
hostvars when it's not needed, and backend_nodes are already contain
all required information.
[1] https://docs.ansible.com/ansible/latest/collections/community/sops/docsite/guide.html
Change-Id: I17a7f2421cd31b37bbda4f9c85971b1825e54891

At the moment service templates are hardly readable, partially due to
complex logic, but incosistent presence of indetnation makes things
way worse, as there's no way to know if you're under some cycle
or condition for sure.
This patch aims to make indents correct which should improve template
readability overall.
Change-Id: Ie60ca87c044281104fbc8334d7254ac351d3d912

In order for http-check to work, option httpchk must be loaded first. Otherwise
regular L4 check will be issued and all `http-check` will be simply ignored.
Closes-Bug: #2046223
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/903488
Change-Id: Ie9ed322ab9c4a04d42cab4456567ac5d1f5c966b

Neither `vip_interface` nor `vip_address` are defined or available in
the context they're being used.
Thus we need to refer to available variables in order to render base config
properly
Current version fail with "AnsibleUndefinedVariable: 'vip_interface' is undefined"
on "Drop base haproxy config" task.
This fix the issue that was introduced with [1] and backported back to Zed
[1] https://review.opendev.org/q/Ib8be6b7fc3dada9d20905b0f07d90ddce0335605
Change-Id: I4e52378d8c5b3eaa6863ecaf0d04554d082e3dc0

Some environments use a dedicated PKI for monitoring and metric collection.
This change allows to configure the serving certificate for stats independently
by setting `haproxy_stats_ssl_cert_path`, the default is to use the same cert.
Also client certificate authentication for stats can now be enabled by defining
a CA cert via `haproxy_stats_ssl_client_cert_ca`.
Change-Id: Ib8be6b7fc3dada9d20905b0f07d90ddce0335605

This patch implements extra variables/keys that can be used to
enable HTTP/2 protocol for frontends and backends.
With that patch does not add HTTP/2 support for any redirect frontends
since they can not be configured to use TLS and this it will
cause such redirect backends to be HTTP/2 only, which might break old
clients.
With that regular frontends, that are not terminating TLS can be
configured to be HTTP/2 only as well as TCP backends.
Change-Id: Ib14f031f3c61f31bf7aaf345a3ba635ca5fb9ff8

It's now possible to set ssl cert path in case you want to bind to
specific hostname via ``haproxy_bind`` and want to share a common
certificate. set ``haproxy_ssl_path`` to override per service.
Change-Id: Ib517f52c0edbc4ac8d0df2a2ae078c9138141aae

Add the possibility to have multiple backend services running on
differents ports.
Change-Id: I1748bfc15bdf879f78aa06c385af7b6c45bde7ff

This change fixes service-redirect.j2 template that was not working so
far, mainly by replacing:
- 'vip_bind' with 'vip_addres'
- 'item' with 'service'
Additionally, I removed `haproxy_tcp_upgrade_backend` support because
it's not really needed after haproxy separated service config was
implemented.
I also changed variable name `haproxy_tcp_upgrade_frontend` to
`haproxy_accept_both_protocols` to better describe what exactly it does.
Release note is not needed as ``haproxy_tcp_upgrade_frontend` was not
working properly before.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/884445
Change-Id: Iba9156c5b909f7b18599638db4471bab12794f0e

Certbot-auto is deprecated since 2020[1] and it is no longer available
under https://dl.eff.org/certbot-auto.
This change removes certbot-auto from haproxy_server role leaving
distro method as the only available option.
[1] https://community.letsencrypt.org/t/certbot-auto-deprecated-explanation-and-solutions/139821
Change-Id: Ibe0f13fc7308359d337fb382cb72998befb90d84

For certificates from widely trusted CA there is no need to provide
a specific CA file for an ssl backend, but the code fails with
undefined variable if only haproxy_backend_ssl is enabled.
A workaround is to set `haproxy_backend_ca: false` but this patch
allows haproxy_backend_ssl to be used on it's own.
Change-Id: I7c87317433acb4ed73070a2252240737b22dccfc

For historical reasons the ``haproxy_service_configs`` variable was
a list of nested mappings with only single valid key for the top
level mapping.
There have been no use-cases for extra keys, so this patch simplifies
the code by removing one level of nesting.
Change-Id: I50c17b7020a459ab8a88b004cc8828cac857f1c9

HAProxy supports the use of map files for selecting backends, or
a number of other functions. See [1] and [2].
This patch adds the key `maps` for each service definition allowing
fragments of a complete map to be defined across all the services,
with each service contributing some elements to the overall map file.
The service enabled/disabled and state flags are observed to add and
remove entries from the map file, and individual map entries can also
be marked as present/absent to make inclusion conditional.
[1] https://www.haproxy.com/blog/introduction-to-haproxy-maps/
[2] https://www.haproxy.com/documentation/hapee/latest/configuration/map-files/syntax/
Change-Id: I755c18a4d33ee69c42d68a50daa63614a2b2feb7

Currently default_backend for a service is always set to the
haproxy_service_name for a service, but this might not be what is
required for some configurations.
This patch allows haproxy_default_backend to be configured for
a service to customise the default_backend setting.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/876436
Change-Id: I9e2be37cb27a33350577a93f23b69e560493b320

In change [1] we have added functionality to accept both HTTP and
HTTPS during an upgrade.
However it's only limited to internal VIP. I see no reason not to
implement this also for external VIP. Some people may find it useful.
[1] https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/829899
Change-Id: I672016b75d4b514d87dbb47119ff549bbc4e923e

Currently this must be configured on a per-frontend basis through
service.haproxy_frontend_raw. This patch adds a new role default
variable haproxy_frontend_extra_raw which will be combined with all
per service raw config lines.
Change-Id: I506d46d64df93bbb9e6d1ebfa3d3caa44c80fdd5

The ternary options appear to be getting evaluated whether they
are used or not, so item['interface'] is always accessed.
This patch aims to check for the key's presence before performing
ternary operations, or use Ansible variables to postpone evaluation
until absolutely necessary.
Change-Id: Ib1462c04d1a0820a37998f989e2ed16566f71f54

At the moment for some reason we're not taking into account default
variables haproxy_rise/haproxy_fall but instead trying to count
based on amount of backends. This makes quite little sense to
depend amount of backend rechecks on amount of backends overall,
so we're chaning behaviour to pre-defined variables that already exist.
Change-Id: I1e53a997f6f443718ea2c6bdfbe8a0b98c44896d

Haproxy config check(/usr/sbin/haproxy -c -f /etc/haproxy/haproxy.cfg)
returns 3 warnings:
1. keyword 'forceclose' is deprecated in favor of 'httpclose', and will
not be supported by future versions.
2. backend 'galera-back' : 'option tcplog' directive is ignored in
backends.
3. 'http-request' rules ignored for backend 'galera-back' as they
require HTTP mode.
This change fixes 1. and 2.
Fixing 3. will be a bit more tricky as it's a part of
`openstack_haproxy_stick_table` defined in
/opt/openstack-ansible/inventory/group_vars/haproxy/haproxy.yml
Change-Id: Idaa4b5580039857435f90416924dee26a702deba

Currently there is no way of disabling SSL connection for stats frontend
as it implies more global variable. However, for some systems consuming
self-signed root certificate might be not an option and disabling
SSL verification tricky. Thus, we introduce new variable that allows to
nicely control if SSL should be served for stats frontend or not.
Change-Id: Ic4bc4393ec89469876e9e95b12bb9c4069972713

Add `haproxy_ssl_letsencrypt_domains` variable, which
contains a list (defaults to `external_lb_vip_address`)
for `--domains` certbot option.
Change-Id: I2ebfff9eeb5279a3964b8578a6e66aa132d763f5

In some user scenarious (like implementing DNS RR) it might be useful to
bind on 0.0.0.0 but at the same time do not conflict with other services
that are binded to the same ports. For that, we can specify a specific
interface, on which haproxy will be binded to 0.0.0.0.
In netstat it would be represented like `0.0.0.0%br-mgmt:5000`.
With that we also allow to fully override `vip_binds` if assumtions
that role make are not valid for some reason.
Change-Id: Ic4c58ef53abc5f454b6fbebbd87292a932d173ae

A new variable "haproxy_stick_table" is added which allows a custom
stick-table to be supplied that is used as the default stick-table
for all haproxy back-ends.
In addition, the variable service.haproxy_stick_table can be defined
for each service to allow a unique stick-table to be supplied for
a particular service.
The old default stick-table definition is removed as there was no
use case defined for it in this role before. An example is added
to defaults/main.yml to show how the custom stick-table can be used
to rate-limit requests that generate 4xx responses which commonly
occur during vulnerability scanning or credential stuffing attacks.
There are many other uses for stick-tables, consult the HAProxy
documentation for details.
Change-Id: I50daba08c10f071157d6450ea2fa97df448f99ec

Instead of hardcoding specific supported tunable options, we
just pass key as an option to haproxy config.
This change might break deployments during upgrades, since format of
values in variable has changed, but appropriate release note was written
We also increase maxrewrite by default, as otherwise usage of CSP leads
to 500 error.
Change-Id: I949960420ed5dbd6d58f0de7dae0ac629a85b7fc
Related-Bug: https://github.com/haproxy/haproxy/issues/1597
Needed-By: https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/844815 

Enable TLS on internal communication has 2 parts
* Enabling TLS on the internal VIPs for haproxy frontends
* Enabling TLS on the service backends
Haproxy has support for enabling TLS on frontends and backends,
but doing so would cause downtime.
In the case of upgrading frontends, enabling TLS would prevent
openstack services from working until their config is changed
from http to https, as they do not follow redirects.
In the case of backends haproxy would mark each backend as down
because if could not initiate a HTTPS connection to the backend
until the backend is updated.
This patch fixes this and allows haproxy to accept both HTTP and
HTTPS on the same well known port for each service. It also
allows for both HTTP and HTTPS backends.
Support for HTTP and HTTPS on the frontend is enabled by setting
haproxy_tcp_upgrade_frontend: true
Support for HTTP and HTTPS on the backend is enabled by setting
haproxy_tcp_upgrade_backend: true
This is a temporary patch and will be removed once instances have
been upgraded to HTTPS for internal communications in a future
release of OSA.
Change-Id: I4279005d5b4e6133cf85ba43379b51149c838f17

This adds TLS v1.3 support to the HAProxy role by default, along
with a new variable to manage cipher suites.
The old variable for TLS v1.2 and below ciphers is renamed for
consistency, but is still supported as a default where overridden
by deployments.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/823943
Change-Id: Iaf9709ac5f5ac8db281a9ec7278cef274186ba15

If haproxy_backend_ca set to true, default to using system CA
so you dont have to specify the exact CA to use.
Change-Id: I536c32a0b152a2b754787e07574472ecfaebd7e7

This is required if a server only speaks HTTPS
Change-Id: Ib99eed929dfded2bbf11bc1a54c4184edafe8452

Option httplog directive is ignored in backends
http://cbonte.github.io/haproxy-dconv/2.0/configuration.html#4-option%20httplog
Change-Id: I792f22b8e20b3ca34be78a9c87ca0f1050f9225c

We have announced and documented haproxy_frontend_raw variable
while in fact introduced haproxy_raw. Since announced variable name
better reflects its purpose and it was announced,
we rename it to haproxy_frontend_raw in template generation.
Change-Id: I7ba9588b599f42dddad395df1a2e18ccfe6b3fe3

With releasing PKI role we broke Let's Encrypt option because of
changing directories where certs should be located
and not reflecting these changes for let's encrypt. At the same time
we should not generate self-signed cert when let's encrypt path is used.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/811742
Closes-Bug: #1938961
Change-Id: I1a6701b171782528373bc1d0a39e70e6d1ef20ab

HAProxy added native Prometheus support from v2.0. This can be
enabled using the existing stats endpoint via an additional
/metrics path.
Change-Id: If9528969c7915db06138c0746dc419d8302f0e7c

We're providing an option to have an IP address per VIP
address. Currently it's used only for creating self-signed
SSLs signed with internal CA per each VIP. With follow-up
patches that will also allow to provide user certificates
per VIP, making possible to cover internal and external
endpoints with different non-wildcard certs.
Change-Id: I0a9eb7689eb42b50daf5c94c874bb7429b271efe

In some use cases you may want to define your own stick-table and
rules, this can be done using the backend_arguments variables.
As you can have only one stick-table per backend or frontend
the default stick-table needs to be disabled.
I am also not convinved the default stick-table is used for anything,
it just logs requests and never uses the logs, i think it could be
removed.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/797819
Change-Id: I54307c00673ababb277257f2bb0e456e3e011ac4