Re: [DISCUSS] Deprecate TLS Toolkit for Removal?
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 > > > > 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 > > > > > > > > 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 > > > > > > > > > > > > > >
Re: [DISCUSS] Deprecate TLS Toolkit for Removal?
I spent a bit of time working on a draft of the needed openssl commands to generate equivalent keystores / truststores. Was not able to finish this draft before I got side tracked. https://github.com/greyp9/nifi-tidbits/blob/main/cluster/tls-toolkit-via-openssl/cluster-certs.md If you're still offering, I would be interested to see the equivalent keytool commands, to compare and contrast. Maybe both could be documented... If we can reduce or eliminate the needed maintenance efforts associated with TLS Toolkit, this seems worth some one-time effort. On Sun, Sep 17, 2023 at 1:46 AM Matthew Hawkins wrote: > NiFi in certain configurations requires a specific set of x509_v3 > extensions, e.g. when using InvokeHTTP. This is automatically added when > using TLS Toolkit but all other options relies upon the CA either accepting > and passing through extensions in the request, or specifically adding them > in. > > You cannot use a stock standard web cert signing authority as they usually > ignore passed extensions and just sign a server-only cert, which will > result in a dysfunctional NiFi. ADCS doesn't have a valid default template > for NiFi and many installations of that don't deviate from default > templates. > > If you don't use certain processors it's certainly easy to just sign a > server cert and not know anything is amiss. This shouldn't be the default. > It's 15 sequential Java keytool commands to build a proper CA chain and > sign a NiFi cert. If TLS Toolkit is being pulled, a script to invoke > keytool should be included at the same time. > > I'm happy to provide a basic solution to this if asked. > > I like keytool as it is available on all platforms and uses the right > formats NiFi requires for keystore and truststore. The open source Keytool > Explorer is also a nice way to build and manage the stores, not strictly > necessary but nice to have. > > > > > On Thu, 14 Sept 2023, 05:58 Kevin Doran, 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 > > > 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 > > > > > > > > > -Oorspronkeli
Re: [DISCUSS] Deprecate TLS Toolkit for Removal?
NiFi in certain configurations requires a specific set of x509_v3 extensions, e.g. when using InvokeHTTP. This is automatically added when using TLS Toolkit but all other options relies upon the CA either accepting and passing through extensions in the request, or specifically adding them in. You cannot use a stock standard web cert signing authority as they usually ignore passed extensions and just sign a server-only cert, which will result in a dysfunctional NiFi. ADCS doesn't have a valid default template for NiFi and many installations of that don't deviate from default templates. If you don't use certain processors it's certainly easy to just sign a server cert and not know anything is amiss. This shouldn't be the default. It's 15 sequential Java keytool commands to build a proper CA chain and sign a NiFi cert. If TLS Toolkit is being pulled, a script to invoke keytool should be included at the same time. I'm happy to provide a basic solution to this if asked. I like keytool as it is available on all platforms and uses the right formats NiFi requires for keystore and truststore. The open source Keytool Explorer is also a nice way to build and manage the stores, not strictly necessary but nice to have. On Thu, 14 Sept 2023, 05:58 Kevin Doran, 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 > > 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 > > 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 > > > > 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 >
Re: [DISCUSS] Deprecate TLS Toolkit for Removal?
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 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 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 > > > > 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 > > > 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 > > > > > > 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 sec
Re: [DISCUSS] Deprecate TLS Toolkit for Removal?
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 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 > > 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 > > 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 > > > > 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
Re: [DISCUSS] Deprecate TLS Toolkit for Removal?
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 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 > 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 > > 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 > >
Re: [DISCUSS] Deprecate TLS Toolkit for Removal?
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 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 > 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
RE: [DISCUSS] Deprecate TLS Toolkit for Removal?
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 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
[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
