Config nifi behind haproxy

[#1]

I want to config haproxy as LB for nifi web. My nifi cluster is configured using self certificate. When accessing to nifi web, I got the error user unauthorization. Here is my config:

global
  log         127.0.0.1 local2
  chroot      /var/lib/haproxy
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  user        haproxy
  group       haproxy
  daemon
  stats socket /var/lib/haproxy/stats

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000
    timeout http-request 10s
    timeout http-keep-alive 10

frontend nifi
  bind *:80
  mode http
  default_backend nifi
  http-request set-header X-ProxyScheme http
  http-request set-header X-ProxyHost %[hdr(host)]
  http-request set-header X-ProxyPort 80
  http-request set-header X-Forwarded-For %[src]
  http-request set-header X-Forwarded-Proto http

backend nifi
  mode http
  server nifi01 10.29.144.56:8443 ssl verify none
  server nifi02 10.29.144.57:8443 ssl verify none
  server nifi03 10.29.144.58:8443 ssl verify none

nifi.web.proxy.host=10.29.144.56

[#2]

@yoonli 

It would be helpful if you shared the complete authorization exception you are encountering.  I have a feeling your authorization exception is not related to your server certificate, but more related to your individual NiFi user.

Using a load balancer in front of your NiFi cluster would require that session affinity (sticky sessions) is enabled in your load balancer. 
The why?

• Any login based user authentication (ldap-provider, kerberos-provdier, etc) result in a token being issued to the user and a server side token stored on the NiFi server that issues the client token. Only the specific node in the NiFi cluster that issued the client bearer token will have the corresponding server side token.
• If your load balancer does not have sticky sessions enabled subsequent requests after obtaining the client bearer token may get direct to a different node in the cluster.
• Your browser will include this client token in all subsequent request to NiFi
• Since the other nodes will not hav the corresponding server token for your user the session would result in an not authorized response. 

Possible helpful HAProxy links:

• https://www.haproxy.com/blog/enable-sticky-sessions-in-haproxy
• https://www.haproxy.com/solutions/load-balancing

----

Certificate based authentication is not an issue since the client/server MutualTLS exchange happens in every communication between client and server.   This is why is suspect that your setup involves a login based authentication method.

----

I see you configured your LB IP in the nifi.web.proxy.host property within the nifi.properties file.   This property has nothing directly related to client/user authentication.  It is about making sure NiFi accepts requests destined for a different hostname/IP then the destination host that received it. Let's say you initiate a connection to URL containing host: https://10.29.144.56/nifi/ 

Your HAProxy then routes that request to NiFi on host 10.29.144.58 which returns a server certificate with that servers hostname or the IP 10.29.144.58.  The connection is going to be blocked because it appears as a man-in-the-middle attack.  The expectation was that the request would be processed by the server 10.29.144.56; however, host 10.29.144.58 received the request.  By adding 10.29.144.56 to the proxy.host property in NiFi, you are telling NiFi to accept requests intended for a different hostname or IP then the actual NiFi's hostname or IP.

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt