[
https://issues.apache.org/jira/browse/NIFI-14858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18013922#comment-18013922
]
Lars Francke commented on NIFI-14858:
-------------------------------------
{quote}The situation you are describing sounds very much like the set of
problems that cert-manager was created to solve, in terms of dynamic
certificate provisioning for Kubernetes pods, based on pod hostname. It does
require the load balancer to trust the certificate issuer, but that is standard
practice for TLS configuration. Granted, it is necessary for the load balancer
to be updated with knowledge of current pod names, but that is required for
request routing to live pods.
{quote}
Maybe I misunderstand, but: This does not solve the problem. If it's a
L4/Pass-through Load Balancer it isn't concerned about TLS at all. It just
forwards the request at the network level (e.g.
[https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
|https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html).]
without changing or even inspecting the packet.
cert-manager does not help here. And in this case it is the other way around:
NiFi would need to be updated with knowledge of all incoming host names. And
cert-manager can't do that dynamically. And even if it could: We'd then need to
restart each NiFi node for every update of the certificate, wouldn't we? That's
pretty inconvenient.
{quote}At a basic level, the certificate distribution strategy needs to be as
dynamic as the pods themselves. This is readily achievable with solutions such
as cert-manager, but it is difficult without a service that provides a similar
level of flexibility. This is a common deployment pattern for NiFi 2, so
supporting less flexible alternatives that raise security concerns remains
problematic.
{quote}
We have seen our fair share of Kubernetes installations but this is not
something I've ever seen (for the above described scenario) . You've
nerd-sniped me into looking into cert-manager in detail but I can't find the
features you're describing.
I tried drawing it up.
Probably not perfect but this would be the timeline:
# NiFi Pod is up and running with Certificates that DON'T contain the LB name
because the name is not known at this time
# LB comes up and is assigned a random name
# cert-manager has NO way of automatically updating the certs so admin has to
update the certificate CR or the volume declaration
# cert-manager creates a new cert
# Pod needs to restart
!image-2025-08-14-15-57-45-590.png!
So, this is one (common for us) scenario where SNI breaks deployment.
*PodIP problem*
Expanding on the previously mentioned IP problem. CSI drivers that inject
certificates run BEFORE an IP is assigned to a pod so the IPs cannot be
included in the certificates easily. So in cases where you rely on IP
communication you cannot generate a certificate in time. You need to wait until
the Pod has its IP, then generate the certificate and then basically either
restart the Pod or have the pod handle the certificate watching internally.
See here as an example: [https://github.com/cert-manager/csi-driver/issues/17]
We ran into this as well.
The reality on the ground (for us and our customers) is not (probably
unfortunately) what you're describing and setting this up correctly is very
hard and complex (sometimes impossible). In addition, in some of these
scenarios we don't even need NiFi to ensure this security, it can be done at
other levels. Unfortunately, we often can't influence the client infrastructure
and their policies.
I'd still love to convince you that this is a worthwhile tradeoff.
> Make SNI checking configurable
> ------------------------------
>
> Key: NIFI-14858
> URL: https://issues.apache.org/jira/browse/NIFI-14858
> Project: Apache NiFi
> Issue Type: Improvement
> Affects Versions: 2.5.0
> Reporter: Lars Francke
> Assignee: Lars Francke
> Priority: Minor
> Attachments: image-2025-08-14-15-50-33-711.png,
> image-2025-08-14-15-57-45-590.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> As of NiFi 2.0 SNI certificates are required and the host must match.
> This is a problem for us (and others) when there is for example a load
> balancer in front which does not match the host name of NiFi.
> Instead of disabling the SNI check by default this makes it configurable.
>
> I propose introducing two new configuration properties:
> * nifi.web.https.sni.required (whether a SNI certificate is required)
> * nifi.web.https.sni.host.check (whether to check the Host from the SNI
> certificate against the incoming request)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
