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 > > > > >
