Maybe this only makes sense from an LDAP provider scenario. I'm not seeing the advantage using a file-based provider. In this case, the group needs to be created manually. So do the users (i.e. the cluster nodes) as they are added to the cluster. And also those users need to be added to the group. That's still a lot of manual management.
Additionally, once the group is added to the relevant policies (another manual process), it does not need to be added again. So, what is the advantage to placing such a capability in a configuration that (correct me if I'm wrong) is only run at startup? Again, maybe this only makes sense for LDAP or similar external provider. Having gone down this road - and also recently attempted to crack the nut of adding the Initial Admin User to Component Access Policies on a first-time startup - it seems to me the authorizer startup and configuration needs some retooling. Currently, it is not as dynamic as it could be and is highly error prone in a cluster case, and it is remarkably confusing for new users even in a stand-alone case. Perhaps a slight detour from my original question, but to summarize I'd like to see the following options available (even in non-LDAP) - new cluster nodes automatically added to relevant policies (not necessarily requiring membership in a particular group) - authorizations.xml and users.xml inherited from the cluster, if different - add initial admin to component access policies even if flow.xml.gz does not exist at time of startup On Thu, Apr 11, 2019 at 3:28 PM Bryan Bende <[email protected]> wrote: > I believe the Node Group will grant that group the same permissions as > the Node Identities would get. So if you have a user-group-provider > that already has this group and already knows the nodes are in this > group, maybe in LDAP or some other external provider, then you can > just specify this group as the Node Group and then you don't have to > specify Node Identities. This helps when adding new nodes because you > don't have to do anything with policies for the new node, as long as > they are in that group in the user-group-provider. > > On Thu, Apr 11, 2019 at 2:53 PM Mark Bean <[email protected]> wrote: > > > > What is the proper usage of the Node Group in the authorizers.xml file? > The > > documentation only describes what it is, but not how to use it. > > > > For example, I attempt to add a new node to a cluster. The > authorizers.xml > > was modified to add the User Group name to the accessPolicyProvider's > Node > > Group property. NiFi failed to start; it could not find the node group. > The > > startup process created new, empty authorizations.xml and users.xml > files. > > Should it have inherited these from the cluster? > > > > What else am I doing wrong? > > > > Thanks, > > Mark >
