Thanks for the replies Kevin and Joe! Based on responses, I will proceed with putting together a pull request for removing the TLS Toolkit for the main branch as part of 2.0 technical debt removal.
Regarding the encrypt-config command, it sounds like removing it for a milestone 2.0 release is a good solution. Some of the functionality is already implemented directly in nifi.sh with set-sensitive-properties-key and set-sensitive-properties-algorithm. The existing version of encrypt-config is capable of handling current configurations and files. From that perspective, version 1 can continue to provide a bridge while we scope out a rewritten version. Regards, David Handermann On Wed, Sep 13, 2023 at 3:24 PM Joe Witt <joe.w...@gmail.com> wrote: > > David > > Fully supportive. > > I'll take it a step further and indicate that I am now an advocate of > removing anything we have in our build related to running things or tests > written in Groovy. We should maintain the Groovy support for scripted > components but we should eliminate or replace any tools/tests written in > Groovy. I didn't quite realize how unique the setup seems to be as it > relates to codehaus/vs apache groovy and the versions associated with > integrating with Maven vs versions of Java/etc.. This is adding brittleness > and build complexity we don't need. To that end I'd even suggest we > consider dropping even the encrypt-config on main so we can work to a 2.x > M1 release then get that rewritten with tests in pure Java for a NiFi 2.x > release. > > Thanks > > On Wed, Sep 13, 2023 at 12:58 PM Kevin Doran <kdo...@apache.org> wrote: > > > I agree that tis toolkit can probably be removed in 2.0, and I would add > > that tinycert.org provides another option for teams that need to setup > > dev/test environments with trusted certificates. > > > > Thanks, > > Kevin > > > > On Sep 13, 2023 at 11:46:19, David Handermann <exceptionfact...@apache.org > > > > > wrote: > > > > > Hi Isha, > > > > > > Thanks for the helpful reply. I agree that the TLS Toolkit is most > > > convenient for development and lab deployments, and that's where we > > > should be able to provide some documentation for alternatives. The > > > existing Secure Cluster Walkthrough is a helpful reference for TLS > > > Toolkit usage, so if we updated that to provide similar guidance using > > > other tools, that would be useful. > > > > > > Getting everything right with TLS can be challenging, but when it > > > comes to project maintenance, it seems better to focus on core > > > capabilities and not maintain the TLS Toolkit if the primary use case > > > is for non-production deployments. > > > > > > The encrypt-config command is a different question, but a very good > > > question. It includes functionality that is very specific to NiFi, and > > > it is also in need of refactoring. The threat model for containerized > > > deployments may be somewhat different than running directly on > > > physical hardware. With the need to support various approaches, > > > however, some type of configuration encryption remains a relevant > > > concern. > > > > > > Regards, > > > David Handermann > > > > > > On Wed, Sep 13, 2023 at 10:19 AM Isha Lamboo > > > <isha.lam...@virtualsciences.nl> wrote: > > > > > > > > > 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 > > > > > > > >
