[haproxy-route] Match host header as domain, not as string

[jsimpso]

Enhancement Proposal

Hi,

I've integrated ingress-configurator with haproxy using the haproxy-route interface and the following configuration:

backend-addresses: 10.156.0.13
backend-ports: 80
hostname: test.example.com
paths: /development-jimm

This has given me the following HAProxy config:

frontend haproxy
    mode http
    bind [::]:80 v4v6
    bind [::]:443 v4v6 ssl crt /var/lib/haproxy/certs
    # Redirect HTTP to HTTPS
    http-request redirect scheme https unless { ssl_fc }

    acl acl_path_development-ingress-configurator path_beg -i /development-jimm
    acl acl_host_development-ingress-configurator req.hdr(Host) -m str test.example.com
    use_backend development-ingress-configurator if acl_path_development-ingress-configurator acl_host_development-ingress-configurator

    default_backend default


backend development-ingress-configurator
    balance leastconn
    timeout server 60s
    timeout connect 60s
    timeout queue 60s


    option httpchk
    http-check send hdr Host test.example.com
    server development-ingress-configurator_80_0 10.156.0.13:80

The workload this is connected to (jimm) exposes a Juju controller API. When I try to connect to it with the Juju CLI, host headers aren't sent by the Juju client and we see HAProxy logs indicating that the request falls through to the default backend:

haproxy~ default/<NOSRV> 0/-1/-1/-1/0 200 115 - - LR-- 1/1/0/0/0 0/0 "GET /development-jimm/api HTTP/1.1"

If I adjust the HAProxy use_backend configuration line to remove the acl_host_development-ingress-configurator directive, requests are correctly routed to the backend:

haproxy~ development-ingress-configurator/development-ingress-configurator_80_0 0/0/5/14/1029 101 2340 - - ---- 1/1/0/0/0 0/0 "GET /development-jimm/api HTTP/1.1"

---

Could we please update the possible configurations to allow for path-based routing without the requirement on host headers?

[syncronize-issues-to-jira]

Thank you for reporting your feedback to us!

The internal ticket has been created: https://warthogs.atlassian.net/browse/ISD-4737.

This message was autogenerated

[jsimpso]

UPDATE - per juju/juju#18917 (comment) it seems that I misdiagnosed the issue here. The Juju client does send host headers, the problem we're seeing is that the host header is sent as <host>:<port>.

Including the port in host headers is optional, but normal.

I have verified locally that replacing req.hdr(Host) -m str with req.hdr(Host) -m dom in the HAProxy configuration does result in traffic being routed to the expected backend. Per the HAProxy manual, the difference is:

• exact match (-m str) : the extracted string must exactly match the
  patterns;

• domain match (-m dom) : the patterns are looked up anywhere inside the
  extracted string, delimited with dots ("."), colons (":"), slashes ("/"),
  question marks ("?"), the beginning or the end of the string. This is made
  to be used with URLs. Leading and trailing delimiters in the pattern are
  ignored. The ACL matches if any of them matches. As such, in the example
  string "http://www1.dc-eu.example.com:80/blah", the patterns "http",
  "www1", ".www1", "dc-eu", "example", "com", "80", "dc-eu.example",
  "blah", ":www1:", "dc-eu.example:80" would match, but not "eu" nor "dc".
  Using it to match domain suffixes for filtering or routing is generally
  not a good idea, as the routing could easily be fooled by prepending the
  matching prefix in front of another domain for example.

Would you have any issues replacing -m str with -m dom in haproxy_route?

[Thanhphan1147]

Thanks for the update, I was planning to dive into this a bit more with the juju client

Using it to match domain suffixes for filtering or routing is generally
not a good idea, as the routing could easily be fooled by prepending the
matching prefix in front of another domain for example.

I'm a bit concerned about this, since as it explicitly mentions using it for routing is "generally not a good idea"

If we know that the juju client sends the Host header as host:port can you try setting the hostname config in ingress-configurator to match that?

juju config ingres-configurator hostname="example.com:443"

[jsimpso]

I don't believe the scenario the documentation warns us about is applicable here.

We're talking about matching the fully qualified hostname the service wants to listen on (e.g. "my.domain.example.com") in order to route traffic to that service.

The documentation is warning about not matching on the domain suffix "example.com" in order to route traffic to "my.domain.example.com".

---

can you try setting the hostname config in ingress-configurator to match that?

I did try that, but ingress-configurator doesn't regard it as a valid value:

ingress-configurator/0*  blocked   idle   10.85.2.63         Invalid integrator configuration: hostname

[Thanhphan1147]

I think there are 2 things we can do here:

1. I'll create a separate issue to allow the hostname config to have a port component following the document that you referenced, which should solve this specific use-case with the juju client
2. I'll have to discuss with my team internally to decide if switching to domain matching makes sense

There might be some overlap between the 2 options ( if we have domain matching then allowing a port component might be redundant, etc ... ) but we'll also discuss about that internally.

[Thanhphan1147]

As we're still not sure about using domain matching for the Host header, I'll work on #288 to allow a workaround for the juju client in the meantime.