nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Logan <jmlo...@buffalo.edu>
Subject Re: Whitelisting Proxy Host values in a Container Environment?
Date Mon, 15 Oct 2018 13:45:56 GMT
Thanks Peter. I briefly was playing around with connecting to localhost via
the port-forwarding late last week but was having issues where Nifi was
internally trying to connect to 0.0.0.0 and failing...I'll toy with it some
more this morning (I had set the https listen property as 0.0.0.0 so that
it'd bind to localhost). Or I think the NodePort option will work -- but
will require mucking with the yaml file every deployment to avoid port
clashing between deployments. Mildly inconvenient, but certainly is doable.

If this feature were disabled, certificates would still work -- in this
case, we know our entrypoint, but do not know the port. We could have certs
dynamically issued including the entrypoint hostname into the cert as an
alternate name. Our issue hasn't been knowing the hostname in advance, but
knowing the port, which isn't part of the certificate entry. We haven't
made it to that point yet, but it should work, and is on our roadmap.

Again, thanks a lot -- securing this is turning out to be a lot more
complicated than originally anticipated.




On Mon, Oct 15, 2018 at 3:57 AM Peter Wilcsinszky <
peterwilcsinszky@gmail.com> wrote:

> 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