Hi Bryan, thanks for your response! That would indeed solve the issue, however create a certificate that could be used to impersonate a service called "nifi" in all namespaces of this cluster (or rather anywhere the CA that is used is accepted). Kinda like (well ... exactly like I guess) issuing a certificate for "stackable.*" to someone running "stackable.de" who could then use it to also authenticate as "stackable.tech", stackable.com" ...
We discussed this in the past (cannot find a link to the discussion right now, if I manage to find it I'll post it later) and decided that we'd like to avoid that if possible. Best regards, Sönke On Mon, Oct 28, 2024 at 12:18 PM Bryan Bende <bbe...@gmail.com> wrote: > Hello, > > I think the problem would be solved by adding "nifi" as a SAN to the > certificate of each nifi node right? > > To answer your specific question, there isn't anything I am aware of > to directly pass Jetty configuration, it would have to be something > through nifi.properties. > > Thanks, > > Bryan > > On Mon, Oct 28, 2024 at 7:01 AM Sönke Liebau > <soenke.lie...@stackable.tech.invalid> wrote: > > > > Hi all, > > > > we recently came across some changed behavior when testing NiFi 2.0 [1] > > which we think is due to upstream changes in Jetty that became active > when > > switching to Jetty 12 in NiFi 2.0. > > > > I think the actual issue is less important to this question, but I'll > > briefly outline it, feel free to skip down until the ==question starts > > here== marker if you are not interested. > > > > We run NiFi in Kubernetes and expose it via a service that clients can > > connect to. As usual in Kubernetes, these services get a fqdn assigned to > > them which could look like this "nifi.default.svc.cluster.local". If your > > client runs within the same namespace as NiFi it could also just connect > to > > "nifi" though, which is then essentially the same. > > Since NiFi 2.0 this doesn't work anymore, because the Jetty hostnamecheck > > is enabled by default and fails, because "nifi" is not in the > certificate. > > > > Don't get me wrong: All of this is correct and it should fail, and > > everything works as intended here! > > This should arguably be fixed by simply connecting to > > "nifi.default.svc.cluster.local" instead of "nifi". > > > > Sadly however, we live in a world where we cannot expect to have > everything > > under our control all the time. If NiFi in k8s is exposed via an > > Azure/GKE/AWS/proprietary/... ingress controller or some other forwarding > > mechanisms we cannot expect to always be able to influence what this > > connects to. > > > > I don't think this should be exposed as an option, disabling this check > is > > arguably wrong, but having a uncomfortable override in our back pocket to > > hand out when there is absolutely positively no other alternative might > be > > worth while. > > > > Hence my question - sorry for the very long introduction... > > > > ==question starts here== > > > > Is it possible to somehow set jetty options when starting NiFi that get > > passed through to the server? I googled around a bit and was not able to > > find a definitive answer, there is an xml file that jetty uses in tests, > > but I suspect that'll need to be explicitly referenced somewhere > somehow... > > > > Best regards, > > Sönke > > > > [1] https://github.com/stackabletech/decisions/issues/34 >
