Phil, Thanks for the thoughtful and thorough reply.
The line of reasoning is broadly correct, but there are some important nuances that drove NIP-24, and also stand against restoring a generalized restricted components flag. The Restricted component annotation attempted to categorize types of behavior, but the problem of going down that road is that one type of behavior allows another. For example, writing to the filesystem doesn't sound like it allows executing code, but it is trivial to build a flow that retrieves a library from a remote location and then writes it to an extensions directory for automatic loading. Attempting to recast the authorization check as a dangerous/non-dangerous flag might also seem appealing, but at minimum, it would require categorizing a large number of components as dangerous. For example, a Database Connection Pool Service might not sound dangerous, but the ability to provide a custom JDBC Driver enables code execution by definition. Some components can support retrieving external configuration from a remote URL, which could be considered a security concern from some angles. Without going into all the possibilities, the aggregate impact is that the actual set of non-dangerous components is very small, and requires careful attention to every implementation detail along the way. The introduction of one new property, or change in property handling, could place a component in the dangerous category. In other words, even before NIP-24 deprecated and removed the Restricted annotation, this was a gap. The project maintainers put in substantive work over the years to address those gaps along the way. The problem also extended to other resources in terms of authorization for features like Parameter Contexts, requiring framework evaluation of all possible references to determine whether reading was allowed to one Parameter Context, but not another. The problem was compounded by the fact that despite extensive levels of work to authorize such references, all of it could be undermined by a user that has enough privilege to create and configure a dangerous Processor or Controller Service. Apache NiFi is a powerful system, and its extensible nature differentiates it from a traditional web application in many ways. As it provides co-located configuration and execution, attempting to set boundaries around one and not the other leaves inevitable gaps. I have not even mentioned issues surrounding resource consumption and noisy neighbor challenges. With that background, I appreciate the desire to maintain some semblance of restricted multi-tenancy. NIP-39, however, should serve as a focusing function, highlighting the capabilities and limitations of the system. Regards, David Handermann On Fri, Aug 21, 2026 at 12:17 PM Phil Lord <[email protected]> wrote: > > Thanks David, > > Thanks for laying that out! I want to dig into the specific claim that "the > ability to create and configure a Processor effectively allows manipulation > of the entire configuration," because I think that claim is true today, but > I don't believe for the reason being presented. > > For PG-scoped write to actually equal Controller-wide write, a user would > need some kind of pivot — a way to get from "I can configure Processors in > my Process Group" to "I can change anything in the system." As far as I can > tell there are really only two pivots: > > 1. A Processor with filesystem write access (PutFile, ExecuteScript, > ExecuteProcess, etc.) directly overwriting NiFi's persisted state on disk, > flow.json.gz, authorizations.xml, users.xml, etc. > 2. Script-executing code reaching into the live FlowController object graph > and modifying flow state directly, again without going through any > authorized API call. > > Both are possible in an unsandboxed JVM. Both require the user to be able > to add a small and specific category of component, one capable of arbitrary > fil-system writes or code execution. A user restricted to ordinary > routing/transform processors in their PG has no path to either pivot. > > That category of "dangerous" component is exactly what the Restricted > annotation used to gate, separately from ordinary PG-level write. Before > NIP-24, an admin could grant a user write access to a Process Group without > also granting Restricted-component authorization; so that user could design > flows within their PG but could not add ExecuteScript, ExecuteProcess, or > anything else with WRITE_FILESYSTEM/EXECUTE_CODE. PG-scoped write did not > imply the escalation path you're describing, because the > dangerous-component gate was a real, independent checkpoint standing in the > way. > > So "PG-level write already equals Controller-wide write" is a downstream > consequence of having already removed the Restricted gate in NIP-24. Once > any PG-write user can add any component type, including the dangerous ones, > PG-scoped write does degrade toward Controller-wide write via that pivot, > but that's the earlier removal creating the very problem now being used to > justify this next removal, not a pre-existing limitation of > PG/component-level authorization itself right?? > > Perhaps worth separating two things that were bundled into one: a 'requires > elevated trust' flag, AND the sub-permission types (EXECUTE_CODE, > WRITE_FILESYSTEM, etc.) layered on top of it. I believe the elastic problem > and the CVEs were specifically about the sub-permission layer, since > permission types couldn't actually be isolated from each other once code > was running? The binary trust flag itself was never making that promise; it > was just gating the whole dangerous-component category behind one trust > check. NIP-24 removed both together, since they were implemented as a > single mechanism, there's nothing that separates them. What I'm proposing > is to reintroduce only one piece of what was removed: the binary flag, not > the sub-permission enumeration that was added in NIFI-4885. > > If that's right, the proportionate fix isn't to remove PG/component-level > authorization for everything. It's to restore just the binary flag: "can > this user add components capable of unconstrained code execution or > arbitrary filesystem/network access," yes or no. Not the sub-permission > enumeration, which was rightly removed — just that one flag, checked once, > separate from ordinary PG/component-scoped write. > > That directly closes the actual pivot mechanism without discarding the > separation that the majority of components and use cases genuinely rely on. > It's also compatible with NAR curation per instance, which I raised earlier > — a curated, non-dangerous NAR set for a given trust boundary accomplishes > the same goal upstream of authorization entirely, and works fine alongside > PG-scoped write staying meaningful. > > If I'm talking crazy... certainly tell me so! :) > > Thanks, > Phil > > On Fri, Aug 21, 2026 at 9:57 AM David Handermann < > [email protected]> wrote: > > > Phil and Lucas, > > > > Thanks for following up on this question, it is worth unpacking the > > implications a bit more as the project moves forward. > > > > At the basic level, the goal of moving to Controller-Level > > Authorization is to remove the boundaries between Process Groups, and > > other resource types for that matter. In other words, if a user has > > authorization to write configuration at the Controller Level, it means > > they can make any changes to anything in the system. Right now, the > > framework checks whether a user has authorization to write to each > > Process Group, so the improvement proposal eliminates this boundary. > > > > As described in the proposal, the fundamental problem is that the > > framework is providing an appearance of security for something it > > cannot actually enforce. The ability to create and configure a > > Processor effectively allows manipulation of the entire configuration. > > This was worse with the Restricted components annotation, because one > > type of limitation often opened up the ability to do more than > > advertised, which was the driver behind removing the Restricted > > annotation in NIP-24. > > > > Given the impact of this change, the eventual removal most likely > > makes sense in a major release version. It could be argued that > > removing it after deprecation in a minor version is reasonable, > > because the current restrictions do not provide effective protection, > > so the change would align behavior with reality. However, there are a > > number of things in the queue for a major release version, and I plan > > to start a discussion thread on that topic soon. > > > > I understand that deploying multiple instances of Apache NiFi is not a > > small task. However, the current multi-tenant feature does not match > > the actual capabilities granted based on what is possible through > > various Processors. This may come as a surprise to some, but it is > > better to be clear going forward than continuing with the status quo. > > > > Including the removal in a major release is probably the best way to > > publicize the fundamental changes, so that seems like the optimal > > direction. > > > > Regards, > > David Handermann > > > > On Thu, Aug 20, 2026 at 10:55 PM Lucas Ottersbach <[email protected]> > > wrote: > > > > > > Hi Phil, David, and Team, > > > > > > I agree with Phil that multi-tenant functionality, specifically regarding > > > the assignment of process groups, is a very practical feature. Although > > > multi-tenancy is often solved nowadays by using multiple, smaller > > > deployments, I personally know of deployments that still rely on larger > > > setups subdivided by process groups. Solving this at the infrastructure > > > level is not easily feasible for all teams, especially when the > > deployment > > > is not yet based on Kubernetes. Would it make sense to involve the user > > > mailing list here to get an impression of how widely this feature is > > still > > > being used? > > > > > > Additionally, have I understood the NIP correctly that the actual > > > transition and removal of these features would only take place with a new > > > major version? Otherwise, a minor update would suddenly soften or alter > > > existing access rights. > > > > > > Best regards, > > > Lucas > > > > > > Phil Lord <[email protected]> schrieb am Fr., 21. Aug. 2026, 05:31: > > > > > > > Hey David, > > > > > > > > I meant to get this out before the vote period, but life got in the > > way. > > > > Anyway, hear me out... > > > > > > > > Aren't we just removing an optional finer grained "security" boundary? > > > > Whether the authorization is at /controller or /process-groups/ etc... > > it's > > > > the same logic regardless of granularity. The authorizer policies > > don't > > > > care about runtime containment at any level right? Once a component is > > > > running there's nothing preventing it from executing code, etc. > > Previously > > > > the restricted-components enforcement controlled who could > > create/modify > > > > these types of components. > > > > > > > > Assuming write permissions at the controller level, this isn't adding > > any > > > > additional security boundary. That would have to be something done by > > > > admins through NAR restrictions to an instance, or total isolation via > > > > maybe separate JVMs/containers per a defined trust boundary. Something > > > > like that perhaps? > > > > > > > > Component/pg level authorization was never about controlling anything > > at > > > > runtime. It was about being able to authorize different users for > > > > different components/pgs, "don't like Group A play in Group B's > > sandbox. > > > > While I agree with Mark to some extent that most Nifi deployments have > > > > "evolved" or shrunken in size over time, this isn't really a legitimate > > > > argument for removing the feature. If anything, limiting the feature > > to > > > > process-group level rather than component level is certainly worth > > > > considering, perhaps some could simply be moved to the controller > > level? > > > > > > > > Regards, > > > > Phil > > > > > > > > > > > > > > > > On Mon, Aug 17, 2026 at 4:29 PM David Handermann < > > > > [email protected]> wrote: > > > > > > > > > Mike, > > > > > > > > > > Thanks for the reply. I agree with you that the other Resource Types > > > > > should also be included in this change for consistency, ending the > > > > > multi-tenant authorization strategy for these Resources. I had > > > > > originally considered decoupling the approach from those other > > > > > Resource Types, but the argument for making a change across the board > > > > > applies to those as well. > > > > > > > > > > I adjusted the wording of that sentence to read: > > > > > > > > > > "Authorization for other Resource Types, such as Provenance, Data > > > > > Content Viewing, Tenants, and Policies, should also be moved to the > > > > > Controller level for consistency." > > > > > > > > > > To that end, yes, Policies for other types of extensions should also > > > > > be limited to the Controller level. The above sentence was not > > > > > intended to be exhaustive, but I'm glad to clarify it if that would > > be > > > > > helpful. > > > > > > > > > > Regards, > > > > > David Handermann > > > > > > > > > > On Mon, Aug 17, 2026 at 3:18 PM Michael Moser <[email protected]> > > > > wrote: > > > > > > > > > > > > I understand the desire to simplify NiFi security boundaries to > > make > > > > them > > > > > > both understandable and enforceable. I agree this is a worthwhile > > > > > effort. > > > > > > However, I feel like we should acknowledge that this will > > effectively > > > > end > > > > > > multi-tenant authorization to different parts of a flow. > > > > > > > > > > > > I know the NIP-39 says "Authorization for other Resource Types, > > such as > > > > > > Provenance, Data Content Viewing, Tenants, and Policies, should be > > > > > > unchanged" but in this regard I don't agree. I don't see the > > value of > > > > > > component-level fine-grained authorization for only some resource > > types > > > > > but > > > > > > not all. It would be hard to explain the motivation behind what's > > > > > allowed > > > > > > and what isn't. For example, I think this NIP proposes to allow: > > "You > > > > > can > > > > > > restrict who can empty flowfile queues in this Process Group, but > > you > > > > > > cannot restrict who can modify/operate processors in this Group". > > I > > > > > > wouldn't be able to answer "Why?" > > > > > > > > > > > > So, at the end of this effort, would flow-level Policies go away > > and > > > > only > > > > > > controller-level Policies remain? I'm considering policies > > applied to > > > > > > Parameter Providers and the other "Management" components to be in > > the > > > > > > category of controller-level Policies. > > > > > > > > > > > > Thanks, > > > > > > -- Mike Moser > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Aug 14, 2026 at 10:48 AM David Handermann < > > > > > > [email protected]> wrote: > > > > > > > > > > > > > Mark, > > > > > > > > > > > > > > Thanks for the thoughtful reply and concurrence with the > > approach. I > > > > > > > agree that more focused deployments provide a better security > > surface > > > > > > > in general, eliminating some of the earlier motivation behind the > > > > > > > attempts to provide fine-grained authorization. > > > > > > > > > > > > > > I will leave this discussion open until Monday and then start a > > vote > > > > > > > thread. > > > > > > > > > > > > > > Regards, > > > > > > > David Handermann > > > > > > > > > > > > > > On Wed, Aug 12, 2026 at 3:56 PM Mark Payne <[email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > > Thanks David. This is one of those proposals that sounds, on > > the > > > > > > > surface, almost like we’re going backward. But I absolutely 100% > > > > agree > > > > > with > > > > > > > this direction. First and foremost of the reasons outlined in the > > > > > > > “Motivation” section of the NIP. But even beyond that, I think > > it’s > > > > > worth > > > > > > > noting that the typical NiFi deployment today is VERY different > > than > > > > > it was > > > > > > > when the fine-grained access control was initially released. At > > that > > > > > time, > > > > > > > the typical deployment footprint was huge, with large enterprises > > > > > running 1 > > > > > > > or a handful of big NiFi clusters that span 32+ core machines. > > The > > > > > > > fine-grained approach alleviated the need for many instances > > based on > > > > > > > security controls. But today, we see many smaller deployments, > > and > > > > > those > > > > > > > smaller deployments fall much more cleanly into those security > > > > > boundaries. > > > > > > > And to me that alone may be enough to justify making these > > changes as > > > > > well. > > > > > > > +1 from me. > > > > > > > > > > > > > > > > Thanks > > > > > > > > -Mark > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 12, 2026, at 4:33 PM, David Handermann < > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > Team, > > > > > > > > > > > > > > > > > > I have drafted NIP-39 [1] proposing a simplified approach to > > > > > framework > > > > > > > > > authorization for the REST API. > > > > > > > > > > > > > > > > > > This proposal follows along from the more focused proposal, > > > > NIP-24 > > > > > [2] > > > > > > > > > that deprecated the Restricted component annotation for > > removal. > > > > > > > > > > > > > > > > > > The Controller-Level Authorization strategy aims to align > > > > > implemented > > > > > > > > > capabilities with enforceable security boundaries. This > > approach > > > > > would > > > > > > > > > eliminate the current mismatch between fine-grained > > authorization > > > > > > > > > configuration and full control over the system through > > Processors > > > > > and > > > > > > > > > other extension components. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > David Handermann > > > > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/NIP-39 > > > > > > > > > [2] https://issues.apache.org/jira/browse/NIP-24 > > > > > > > > > > > > > > > > > > > > > > > > > >
