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