The Node Group concept is only meant to be used with an external user group provider. Imagine a scenario where you want to dynamically create a cluster and dynamically scale it, you don't know the hosts ahead of time, but you have a user-group-provider that will somehow know them and have them in a group. We can probably make the docs clearer about when to use this to avoid confusion.
On Thu, Apr 11, 2019 at 4:14 PM Mark Bean <[email protected]> wrote: > > 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 > >
