NiFi UI not accessible when started from docker-compose

Question

For the life of me I can't get to the NiFi Web UI. It makes me hate security.

---

TLDR; I can't find the right way to start NiFi in a docker container and still access the UI. Here's what I've tried (for 8 hours):

docker run --name nifi \
  -p 8080:8080 \
  -d \
  apache/nifi:latest

I go to localhost:8080/nifi - timeout. Same on 127.0.0.1.

docker inspect nifi - IP Gateway is 172.20.0.1 with actual IP of 172.0.0.2. Invalid Host Header and timeout, respectively.

Start randomly trying stuff:

# I tried localhost, 0.0.0.0, various IP addresses
docker run --name nifi \
  -p 8080:8080 \
  -e NIFI_WEB_HTTP_HOST=${hostname-here}
  -d \
  apache/nifi:latest

I also built a full docker-compose.yml for my diminishingly-possible stack. Everything thing works except for:

nifi:
  image: apache/nifi:latest
  hostname: nifi
  depends_on:
    - zookeeper
    - broker
    - schema_registry
    - nifi-registry
  ports:
    - "8080:8080"

No changes. Can you help me?

---

Updates 1

I used the docker-compose.yml file from the repo linked in comments below; thank you @Chaffelson. Still dealing with timeout on localhost. So I spun up a droplet with docker-machine.

The services start fine, and logs indicate Jetty server is up for both NiFi Registry and NiFi. I can access NiFi registry @ <host ip>:18080/nifi-registry exactly like I can on my local machine.

I can't access <host ip>8080/nifi - I get invalid host header response.

So I added to docker-compose.yml:

environment:
    # Tried both with and without quotes
    NIFI_WEB_HTTP_HOST: "<host-ip>"

Jetty server fails to start. Insight?

---

Updates 2

From the logs, using just docker run --name nifi -p 8080:8080 -d apache/nifi:1.5.0:

[NiFi Web Server-24] o.a.n.w.s.HostHeaderSanitizationCustomizer Request host header [45.55.36.15:8080] different from web hostname [348146fc286f(:8080)]. Overriding to [348146fc286f:8080/nifi] where 45.55.36.15 is the host ip.

This is the crux of my problem.

---

Updates 3

I disabled ufw (firewall) on my local machine. I can now access nifi via localhost:8080. No progress on actually accessing on a remote host (which is the point of all this).

Yvor

Answer 1

Sorry to hear you are having trouble with this. In Apache NiFi 1.5.0, the stricter host header protection was enabled to prevent host header poisoning attacks. Unfortunately, we have seen that this was not documented sufficiently for users who were not familiar with the configuration. In response, we have made changes that are currently in master and will be included in the upcoming 1.6.0 release:

• a new property nifi.web.proxy.host was added to nifi.properties which accepts a comma-separated list of valid host headers independent of the Jetty hostname
• the Docker configuration has been updated to allow proxy whitelisting from the run command
• the host header protection is only enforced on "secured" NiFi instances. This should make it much easier for users to quickly deploy sandbox environments like you are doing in this case

For an immediate fix, this command should work:

docker run --name nifi \
  -p 8080:8080 \
  -e NIFI_WEB_HTTP_HOST=172.20.0.1
  -d \
  apache/nifi:latest

You can also intercept the requests using a Chrome extension like ModHeader to override the Host header and verify that it works when it matches the expected host. Along with Daniel's excellent additions, this should help you until the next version is released.

Chaffer

I ran into this problem running an unsecured 1.9.2 container and adding NIFI_WEB_HTTP_HOST fixed it, but the way I read your answer it seems that this should no longer be necessary after 1.6? – Calcimine

From 1.6.0+, the hostname header protection is only applied on a secured instance/cluster. That said, you still need to provide a valid HTTP hostname (localhost is used by default), and if accessing the service from outside the container, you will need to specify the hostname in the configuration explicitly. – Chaffer

This didnt work for me. Instead adding ' -e NIFI_WEB_HTTP_PORT='9090'' to docker run command worked, and now I can access UI on localhost:8080/nifi. Is there some documentation which explains all this well? – Dextroglucose

Answer 2

I use this and similar docker compose files for my automated NiFi Python client testing. It looks superficially similar to yours, and works perfectly well on both Ubuntu (Travis-CI) and my local MacBook pro for myself.
I suggest you try running this file as a known-good configuration, and also examine 'docker logs -f nifi' for the above to see if your environment is throwing errors on startup.

The environment variables for NIFI_WEB_HTTP_HOST and NIFI_WEB_HTTP_PORT are for when you are accessing Docker nifi on a port other than 8080, so that you don't get the host-headers blocker. I contributed these modifications to the project recently, so if you are having trouble with them I would like to know so I can fix it.

V1

Thanks. I will try and let you know. – Yvor

I used your docker-compose.yml file and it built just fine. Output of logs was normal, indicating Jetty service up and listening on http://1233352d3e0c:8080/nifi. The same thing happens locally. Maybe see my edits and provide insight? I'm somewhat frustrated. – Yvor

Hi @PANDAStack within the current version Andy's answer is your best bet for remote access to the server. If you do not need the latest 1.5 features you could also downgrade to 1.4 for now (which doesn't have this security check) until 1.6 is released (which fixes it) – V1

I have the same problem with latest docker (Jun 2020). Try changing NIFI_WEB_HTTP_HOST , still not working. 2020-06-10 08:58:30,251 INFO [main] org.apache.nifi.web.server.JettyServer 0bca93312e1d:8080/nifi Any advise is welcome. – Ronaronal

Answer 3

I had the same issue, I was not able to access the web ui remotely. Turns out the firewall issue. Disabling the firewalld & adding a custom firewall rule to allow docker network with port should solve the issue.

Here is my docker-compose.yml:

Neutralism

Answer 4

in docker use this. It fixed my problem.

--net=host

so that docker can reduce the internal port forwarding path.

Mcgann