question Re: NIFIs HTTPS requirements make running on k8s impossible- I'm probably misunderstanding it though in Support Questions

NIFIs HTTPS requirements make running on k8s impossible- I'm probably misunderstanding it though

red888 — Thu, 28 May 2026 13:56:52 GMT

I think I might just be misunderstanding something, because it seems like NIFI requires HTTPS for intra cluster communication and uses the SAME HTTPS channel for external UI and API access?

I'm expecting to have intra cluster communication be separate from my load balancer/ingress. Meaning the nodes communicate securely with each other but I can set the API and UI to HTTP so I can terminate that at my load balancer- this is very standard practice.

What I think I'm seeing is NIFI uses the same HTTPS channel for both internal and external communication? That can't be right because there is no way I'm registering all my NIFI nodes with a public DNS domain.

But this can't be the case right? I should be able to set just the end user API and UI to HTTP and use a self signed cert for intra-node communication.

I can't even seem to be able to just disable HTTPS entirely, nifi's config is poorly documented and disabling HTTPS seems to break everything. I have this on a secured cluster and because this is k8s I have network policies and myriad other features available to secure them.

Its weird there are specific k8s features for nifi (k8s native instead of zookeeper) but it still seems trapped in this legacy model where it expects me to have a pet server for each node and manage them all manually.

Re: NIFIs HTTPS requirements make running on k8s impossible- I'm probably misunderstanding it though

vafs — Wed, 17 Jun 2026 21:56:39 GMT

Hello @red888,

Thanks for reaching Cloudera Community, glad to have you here.

NiFi does not support HTTPS and HTTP mixed, you will need to have only one.
Is recommended HTTPS, HTTP is supported but in the newer versions due to all the security, login auth and more, is not the best idea as you will face issues like you have seen.

NiFi will use the same HTTPS listner to communicate, this is used for the UI, REST API and node protocol traffic. All of these are HTTPS requests.

About the names, you do not need to add public DNS names. The certs only need to have the SANs matching what the nodes uses to talk each other.
In K8s is usually the pods DNS or service DNS.

There is no much NiFi docs for K8s, but some are these:
https://nifi.apache.org/nifi-docs/administration-guide.html#kubernetes-clustering
https://nifi.apache.org/nifi-docs/administration-guide.html#kubernetes-configmap-cluster-state-provider
https://nifi.apache.org/nifi-docs/administration-guide.html#kubernetes-nginx-ingress-controller
https://nifi.apache.org/nifi-docs/administration-guide.html#cluster_node_properties

Re: NIFIs HTTPS requirements make running on k8s impossible- I'm probably misunderstanding it though

steven-matison — Thu, 18 Jun 2026 14:07:03 GMT

@red888 How are you deploying nifi on k8s now? I am using our operators and deploying nifi w/ ssl is super easy!!

Re: NIFIs HTTPS requirements make running on k8s impossible- I'm probably misunderstanding it though

red888 — Wed, 01 Jul 2026 16:28:55 GMT

Where is ssl terminating and how are you issuing the certs?

Are you terminating SSL at the nodes AND the LB? Are you issuing self-signed certs? I don't want users to see cert errors and I don't want to roll out a whole PKI just because NIFI is not configurable.

I know I'm just beating a dead horse, but a more modern system would allow for this standard sort of config, I'm trying to find a workaround for NIFI:

Nodes communicate via pre-shared key or some other mechanism decoupled from the APIs
The APIs are just set to HTTP and SSL terminates at the load balancer

Re: NIFIs HTTPS requirements make running on k8s impossible- I'm probably misunderstanding it though

red888 — Wed, 01 Jul 2026 16:48:18 GMT

I think this is wrong, but maybe I'm being dumb or missing something obvious here: "certs only need to have the SANs matching what the nodes uses to talk each other."

I DO need public DNS names if I don't want users to see cert errors though right? The certs don't _only_ need to match the node names they need to be issued from a trusted CA which requires the nodes to have public DNS names. This is the main issue.

I can easily automate issuing self-signed certs for node communication (without having to deploy a whole PKI, DNS, letsencrypt, etc)
BUT because NIFI uses the same channel for APIs users will see cert errors and I wont be able to terminate SSL at the LB

Perhaps there is a way to issue self-signed certs AND terminate SSL at the LB with a different public cert and then maybe do some kind of redirect? Ultimately users would still be redirected to the URL with the self-signed cert and see errors though I think? I think the only way to do this is...

Drop SSL everywhere (but how ?)

I've been trying to just drop all security to make it all HTTP so I can terminate SSL at the LB, but this is really poorly documented and I haven't been able to actually get it to do everything HTTP. NIFI has so many of its internals super tightly coupled to HTTPS and there are so many individual configuration fields related to this.

Is there any known working config to just set it to HTTP everywhere?

I have it running on k8s and I can use security features of the cluster to lock it down instead. Hell I even gave it its own cluster so its even more isolated, I definitely don't need HTTPS for intra-node communication.