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