Hi David, My primary use for the TLS toolkit is for lab deployments, mostly during in-house trainings. I will miss the convenience of having a full set of keystores and truststores ready to go with a single command, but then again, a few commands in a script should replicate this well enough, without the need for maintaining the toolkit.
I see no obstacles to adopting NiFi 2.0 if the TLS toolkit is phased out, from the perspective of the deployments I manage. On a side note: How relevant is the encrypt config part of the toolkit still in a mostly containerized world? Regards, Isha -----Oorspronkelijk bericht----- Van: David Handermann <exceptionfact...@apache.org> Verzonden: woensdag 13 september 2023 15:16 Aan: dev@nifi.apache.org Onderwerp: [DISCUSS] Deprecate TLS Toolkit for Removal? Team, The TLS Toolkit provides a number of useful features for securing NiFi server communication, but it also presents several maintenance concerns. In light of other available tools, I am raising the question of removing the TLS Toolkit from the repository as part of NiFi 2.0 technical debt reduction. With the addition of automatic self-signed certificate generation in NiFi 1.14.0, the TLS Toolkit is much less relevant to standalone or development deployments. The validity period of the automatic certificate is limited, but it provides a method of getting started without any need for the TLS Toolkit. On the other end of the spectrum, orchestrated deployments of Kubernetes can take advantage of cert-manager [1] for declarative and configurable certificate generation and distribution. Cluster deployments on physical hardware or virtual machines may have organization-specific Certificate Authorities, which require certificate request processing external to NiFi itself. For this scenario, documenting several standard OpenSSL commands may help to describe converting between PEM and PKCS12 files for common use cases. Back to standalone deployments, Let's Encrypt provides automated certificate provisioning with many tools for managing updates. For a self-signed solution, the mkcert [2] tool is a popular and simple option that works across modern operating systems. With these alternatives, the use cases for TLS Toolkit seem limited. The Toolkit code is not well-structured, and includes several modes that involve custom configuration files with a Jetty web server. There are a number of long-standing unresolved Jira issues [3] related to the TLS Toolkit. Removing the TLS Toolkit for NiFi 2.0 would encourage the use of more robust alternatives and keep the project focused on core capabilities. Thoughts? Regards, David Handermann [1] https://cert-manager.io/ [2] https://github.com/FiloSottile/mkcert [3] https://issues.apache.org/jira/issues/?jql=project%20%3D%20NIFI%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22TLS%20Toolkit%22
