nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Logan <>
Subject Re: Whitelisting Proxy Host values in a Container Environment?
Date Sun, 14 Oct 2018 21:23:49 GMT
Thanks Jeff. We're not using Helm (I don't think at least!) and are using
kubectl directly with yaml files. We are trying to avoid binding to
explicit external ports so that we can deploy multiple times, and I am not
sure how to determine the arbitrary external port assigned to be able to do
the property substitution. Is there a way to do this or am I approaching
this wrong?

As an aside, I'm not really sure what this is accomplishing, as it seems
like the 2-way SSL is preventing any sort of MITM attack. Is there a way to
just turn off or bypass this check?

On Sun, Oct 14, 2018 at 4:33 PM Jeff <> wrote:

> Jon,
> I'll start off by saying that I'm still new to k8s, and don't know the
> specifics of most of this.  You should be able to inject the host and port
> of the proxy into the NiFi configuration before starting the NiFi
> instances, with a Helm chart, for instance.  I've done similar things with
> docker compose.
> You are correct, though, that and
> nifi.web.proxy.context.path need to be set in before
> starting NiFi.  This is required for security purposes, and allows NiFi
> return responses which are based on the proxy host and context path values
> so that references to resources hosted by NiFi are made through the proxy,
> instead of exposing the internal URI to a resource.
> - Jeff
> On Fri, Oct 12, 2018 at 12:42 PM Jon Logan <> wrote:
>> We are running into issues with NiFi not allowing secure connections in a
>> container due to the proxy...the only documentation we've found on this
>> involves whitelisting specific proxy addresses. Is this the only solution?
>> Specifically, we're concerned about the fact that we don't know the proxy
>> address ahead of time to whitelist -- the port is an arbitrary assigned at
>> runtime port, and the proxy name could be any of the nodes of our
>> Kubernetes cluster.
>> Are we missing something?
>> Thanks!

View raw message