I would like to put a finer point on something Pierre mentioned. The NiFi Registry provides a mechanism for finer granularity in authorized access. Specific users are allowed permission only to specific buckets. For the git repo clients, such authorization does not exist currently.
A possible solution to this would be to create a new Access Policy to be applied to the Registry Clients themselves. In multi-tenant environments, only certain tenants would be granted access to a given Registry Client. Modifying this new Access Policy would be under the same restriction as creating the clients in the first place. Specifically, the user would have to be in the 'access the controller/modify' policy. -Mark On Mon, Jan 12, 2026 at 2:19 PM Kevin Doran <[email protected]> wrote: > Thanks for the thoughtful write-up, Pierre. I support your proposal. > > While the need for version controlled flows still exists, a lot has > changed since the introduction of NiFi Registry, and I believe the > needs of most of the community are better met by the git-based > registry client rather than the NiFi Registry Server implementation. > As one of the original authors of the initial NiFi Registry > implementation, I think if we were doing it over today we would > consider a git repository client based approach for the design rather > than a complimentary web service. I look forward to future > improvements to version controlled flow definitions, such as the > NIP-13 proposal for branch support [1], and I think deprecating the > existing NiFi Registry Server implementation makes those plans more > achievable. > > [1] https://issues.apache.org/jira/browse/NIP-13 > > Cheers, > Kevin > > On Mon, Jan 12, 2026 at 12:50 PM Pierre Villard > <[email protected]> wrote: > > > > Hello NiFi community, > > > > I'd like to start a discussion about the future of NiFi Registry and > > propose that we deprecate this component. > > > > **Current State** > > NiFi Registry has accumulated a significant number of security > > vulnerabilities (CVEs) related to its Angular-based frontend, with the > > count now reaching double digits. Unfortunately, these CVEs cannot be > > resolved through simple dependency updates. The only viable path to > > address the security issues requires completing a full rewrite of the > > Registry UI to use modern Angular, an effort that was started but > > remains incomplete as of today. > > > > **Maintenance Challenges** > > Over the past several years, NiFi Registry has received minimal > > maintenance attention. The UI modernization effort has stalled, and > > there is currently no clear path to completion without significant > > volunteer contributions. While an initial PR was submitted and merged, > > the remaining work—including user/group management pages, > > comprehensive testing, etc—still needs to be addressed. As a PMC, we > > have an obligation to respond to CVEs in software we release. > > Continuing to ship NiFi Registry with known, unresolved security > > vulnerabilities is not sustainable. > > > > **Alternatives Available** > > NiFi 2.x introduced direct integration options with Git-based registry > > clients that provide an alternative path for flow versioning: > > - Git-based registry clients offer native integration with existing > > version control infrastructure > > - These clients are actively maintained and do not carry the same > security debt > > > > The main feature gap is the permission model in NiFi Registry that > > allows users to access specific flows based on permissions (useful for > > multi-tenant deployments). With Git-based clients, access control is > > typically all-or-nothing at the repository level. However, the > > advantages of Git-based registry clients largely compensate for this > > limitation for most use cases. > > > > **Maintenance Requirements** > > If you or your organization depends on NiFi Registry and would like to > > see it continue as part of the project, now is the time to step > > forward and contribute to its maintenance. The work required includes: > > - Completing the Angular UI rewrite > > - Complete testing following the full rewrite > > - Backend changes to have feature parity in terms of OIDC/SAML support > > for authentication, remove support for Kerberos, etc > > > > **Proposal** > > I propose that we: > > - Immediately deprecate NiFi Registry - Mark it as deprecated in the > > documentation and codebase, clearly communicating to users that they > > should migrate to alternative solutions. > > - Set a removal timeline - Plan to remove NiFi Registry from the > > codebase as part of NiFi 3.0, giving users adequate time to migrate. > > - Welcome community contributions - If any community members or > > organizations rely on NiFi Registry and wish to maintain it, we > > welcome contributions to complete the UI rewrite and address the > > outstanding CVEs. The deprecation decision could be revisited if > > substantial progress is made. > > > > Without active maintainers willing to do this work right away, > > deprecation and eventual removal is the responsible path forward. > > I look forward to hearing the community's thoughts on this proposal. > > > > Thanks, > > Pierre >
