nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Wilcsinszky <peterwilcsins...@gmail.com>
Subject Re: Whitelisting Proxy Host values in a Container Environment?
Date Mon, 15 Oct 2018 07:57:01 GMT
Hey,

I can't tell about the original intent and motivations, but this is the
Jira that introduced this check [1].

What I can tell is mutual TLS is not the only option to authenticate
against NiFi. You can set up LDAP for example to authenticate the client
and in that case MITM is possible I beleive.

You will need a stable network identity that you can use to configure as
your "proxy" in advance. For example in a testing scenario where you have
access to the kubernetes cluster you can simply use "localhost" as the name
of the proxy and use kubernetes port forward to tunnel requests from the
localhost to your individual nodes (only one node at a time).

Another option that could better work for non-local use cases is to use a
LoadBalancer service in front of the nodes and configure DNS to point to
your LoadBalancer IP. If you want to do this in advance it is possible to
create floating IPs and preconfigure DNS for it at almost any cloud
provider. Then add the configured DNS to nifi.web.proxy.host property when
starting your cluster. If setting up DNS is not an option you can use the
IP directly. If setting up the IP in advance is not an option you may use
an arbitrary hostname as the proxy host and add that hostname to your hosts
file (or dnsmasq or company dns) to point to the dynamically generated
LoadBalancer IP after NiFi started up.

Yet another option could be using Knox proxy that can act as an
authentication gateway to your NiFi cluster. Knox can use a fully
independent authentication scheme in front of the clients and at the same
time authenticate against NiFi using NiFi's supported mechanisms. To get a
grasp of how that works here is a detailed post on that matter [2].

Maybe you try to connect to you NiFi nodes through Kubernetes provided
NodePorts and want to access them directly. You can set up dedicated
Kubernetes services if your node list is static but then you have to
configure all the services with IP/DNS individually. Maybe you can leverage
Knox here as well to route your request to the individual nodes.

As for disabling this feature I'm not sure how that would work. You would
still need to add the host as a SAN entry to your node certificates and
that is something that must be set in advance. Of course you can decide to
avoid TLS verification of the server, but then you cannot really trust the
connection anymore. (You may think wildcard cert could be used there, but
it is discouraged for several reasons)

It would be good to know more about your general and most specifically
about your security requirements to know what would be the easiest way to
setup your cluster.

[1] https://issues.apache.org/jira/browse/NIFI-4501
[2]
https://risdenk.github.io/2018/03/18/apache-knox-proxying-apache-nifi.html

Cheers,
Peter

On Sun, Oct 14, 2018 at 11:24 PM Jon Logan <jmlogan@buffalo.edu> wrote:

> 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 <jtswork@gmail.com> 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 nifi.web.proxy.host and
>> nifi.web.proxy.context.path need to be set in nifi.properties 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 <jmlogan@buffalo.edu> 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!
>>>
>>

Mime
View raw message