Node Group property usage

[Mark Bean <ma...@gmail.com>]

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

Re: Node Group property usage

[Bryan Bende <bb...@gmail.com>]

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 <ma...@gmail.com> 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 <bb...@gmail.com> 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 <ma...@gmail.com> 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
> >

Re: Node Group property usage

[Mark Bean <ma...@gmail.com>]

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 <bb...@gmail.com> 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 <ma...@gmail.com> 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
>

Re: Node Group property usage

[Bryan Bende <bb...@gmail.com>]

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 <ma...@gmail.com> 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