You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by "Woodhead, Chad" <Ch...@ncr.com> on 2018/11/19 16:28:29 UTC
Multiple NiFi clusters with 1 NiFi Rigistry
I am standing up 3 new HDF 3.2 clusters (Dev, Cert, and Prod) and we will be focusing on NiFi (1.7.0) + NiFi Registry (0.2.0). We are using git as our FlowPersistenceProvider. My plan is to use 1 NiFi Registry (the Prod NiFi registry) for all 3 clusters, rather than having 3 NiFi Registries and trying to keep the DB’s in sync between the 3 NiFi Registry instances.
Is there a way to implement some type of authorization so that users can only PUSH/PULL changes from Dev NiFi to Prod NiFi Registry, and only PULL from Cert and Prod NiFi from Prod NiFi Registry?
NiFi and NiFi Registry both use the ‘kerberos-identity-provider’ for authentication, and the Prod NiFi Registry authenticates with git via a ssh access key.
Thanks,
Chad
Re: Multiple NiFi clusters with 1 NiFi Rigistry
Posted by Kevin Doran <kd...@gmail.com>.
Good suggestion, Koji.
On 11/20/18, 20:38, "Koji Kawamura" <ij...@gmail.com> wrote:
I agree with Bryan and Kevin. This is a good feature request.
Filed a JIRA for further discussion.
https://issues.apache.org/jira/browse/NIFIREG-212
In the meantime, as a work-around I'd deploy a reverse proxy (Nginx)
in front of NiFi Registry to only pass mutation requests
(POST/PUT/DELETE) from dev NiFi hosts.
https://serverfault.com/questions/152745/nginx-proxy-by-request-method
Thanks,
Koji
On Tue, Nov 20, 2018 at 11:33 PM Kevin Doran <kd...@gmail.com> wrote:
>
> I think Bryan’s correct that this makes a good feature request for Registry.
>
>
>
> One idea is if you are able to set separate policies for production NiFi and non-production NiFi, then you could limit the user policies to read only for the NiFi canvas / process group and only allow a service account or admin have write access to that NiFi.
>
>
>
> NiFi registry would still technically be writable by those users, but it would prevent them from doing something like making a change in the production NiFi and then saving that version to Registry. It would be a safe guard to make sure changes get introduced to the Registry copy from non-production NiFis.
>
>
>
> Regards,
>
> Kevin
>
>
>
> From: Bryan Bende <bb...@gmail.com>
> Reply-To: "users@nifi.apache.org" <us...@nifi.apache.org>
> Date: Tuesday, November 20, 2018 at 08:28
> To: "users@nifi.apache.org" <us...@nifi.apache.org>
> Subject: Re: Multiple NiFi clusters with 1 NiFi Rigistry
>
>
>
> I think we would need to build some type of feature into registry to truly support this. Possibly a more specific policy for proxies so that we could say Dev NiFi can proxy read and write requests, and prod NiFi can only proxy read requests. Currently it would only really work if you had separate Kerberos domains, or weren’t using ranger.
>
>
>
> On Tue, Nov 20, 2018 at 6:25 AM Woodhead, Chad <Ch...@ncr.com> wrote:
>
> Hi Koji,
>
> Unfortunately all of my NiFi clusters use the same Kerberos domain, which is making this harder.
>
> Using NiFi identity mappings to map the same Kerberos principal to environment aware ones seems like a good idea, but I’m thinking there will then be a disconnect for Ranger (used for NiFi authorization) and NiFi Registry. I say this because we use ldap user/group sync for Ranger and ldap sync for NiFi Registry using ldap-user-group-provider.
>
> So in Ranger and NiFi Registry, the users are just listed as ‘bob’ and not ‘bob@dev’. That means I would manually have to add users to Ranger and NiFi Registry to add the ‘@dev’ part right? Or is there a way to customize that too?
>
> Hope I’m not overcomplicating this!
>
> Thanks,
> Chad
>
> On 11/19/18, 8:26 PM, "Koji Kawamura" <ij...@gmail.com> wrote:
>
> *External Message* - Use caution before opening links or attachments
>
> Hi Chad,
>
> NiFi Registry uses NiFi user's identity to authorize request.
> Registry also checks NiFi instance's identity to authorize proxying
> user requests, but this can only authorize proxy capability. In order
> to control access such as bucket read/write, Registry uses NiFi user's
> identity.
>
> I assume the kerberos identities are different among those
> environments (Dev, Cert and Prod). And Registry will have different
> user identities for those.
> E.g. for user Bob, Registry would have bob@dev, bob@cert and bob@prod
> Then you can define dev, cert and prod groups at Registry to give
> certain access to buckets.
> E.g. give read/write access to dev group, and give only read access to
> cert and prod groups for a bucket.
>
> In case your NiFi clusters use the same Kerberos domain, you can use
> NiFi identity mapping to map the same Kerberos principal to
> environment aware ones, so that the above authorization can be
> configured at NiFi Registry.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nifi.apache.org_docs_nifi-2Ddocs_html_administration-2Dguide.html-23identity-2Dmapping-2Dproperties&d=DwIFaQ&c=gJN2jf8AyP5Q6Np0yWY19w&r=MJ04HXP0mOz9-J4odYRNRx3ln4A_OnHTjJvmsZOEG64&m=lFWN8OtWhTL6eW3O-K1-lwIDlC0ZViDDrxxFSys2-Lw&s=_4v5XehCxEQZKSAr800935KuCtiECO-BQGkPknz5Gg4&e=
>
> Thanks,
> Koji
>
>
> On Tue, Nov 20, 2018 at 1:38 AM Woodhead, Chad <Ch...@ncr.com> wrote:
> >
> > I am standing up 3 new HDF 3.2 clusters (Dev, Cert, and Prod) and we will be focusing on NiFi (1.7.0) + NiFi Registry (0.2.0). We are using git as our FlowPersistenceProvider. My plan is to use 1 NiFi Registry (the Prod NiFi registry) for all 3 clusters, rather than having 3 NiFi Registries and trying to keep the DB’s in sync between the 3 NiFi Registry instances.
> >
> >
> >
> > Is there a way to implement some type of authorization so that users can only PUSH/PULL changes from Dev NiFi to Prod NiFi Registry, and only PULL from Cert and Prod NiFi from Prod NiFi Registry?
> >
> >
> >
> > NiFi and NiFi Registry both use the ‘kerberos-identity-provider’ for authentication, and the Prod NiFi Registry authenticates with git via a ssh access key.
> >
> >
> >
> > Thanks,
> >
> > Chad
>
> --
>
> Sent from Gmail Mobile
Re: Multiple NiFi clusters with 1 NiFi Rigistry
Posted by Koji Kawamura <ij...@gmail.com>.
I agree with Bryan and Kevin. This is a good feature request.
Filed a JIRA for further discussion.
https://issues.apache.org/jira/browse/NIFIREG-212
In the meantime, as a work-around I'd deploy a reverse proxy (Nginx)
in front of NiFi Registry to only pass mutation requests
(POST/PUT/DELETE) from dev NiFi hosts.
https://serverfault.com/questions/152745/nginx-proxy-by-request-method
Thanks,
Koji
On Tue, Nov 20, 2018 at 11:33 PM Kevin Doran <kd...@gmail.com> wrote:
>
> I think Bryan’s correct that this makes a good feature request for Registry.
>
>
>
> One idea is if you are able to set separate policies for production NiFi and non-production NiFi, then you could limit the user policies to read only for the NiFi canvas / process group and only allow a service account or admin have write access to that NiFi.
>
>
>
> NiFi registry would still technically be writable by those users, but it would prevent them from doing something like making a change in the production NiFi and then saving that version to Registry. It would be a safe guard to make sure changes get introduced to the Registry copy from non-production NiFis.
>
>
>
> Regards,
>
> Kevin
>
>
>
> From: Bryan Bende <bb...@gmail.com>
> Reply-To: "users@nifi.apache.org" <us...@nifi.apache.org>
> Date: Tuesday, November 20, 2018 at 08:28
> To: "users@nifi.apache.org" <us...@nifi.apache.org>
> Subject: Re: Multiple NiFi clusters with 1 NiFi Rigistry
>
>
>
> I think we would need to build some type of feature into registry to truly support this. Possibly a more specific policy for proxies so that we could say Dev NiFi can proxy read and write requests, and prod NiFi can only proxy read requests. Currently it would only really work if you had separate Kerberos domains, or weren’t using ranger.
>
>
>
> On Tue, Nov 20, 2018 at 6:25 AM Woodhead, Chad <Ch...@ncr.com> wrote:
>
> Hi Koji,
>
> Unfortunately all of my NiFi clusters use the same Kerberos domain, which is making this harder.
>
> Using NiFi identity mappings to map the same Kerberos principal to environment aware ones seems like a good idea, but I’m thinking there will then be a disconnect for Ranger (used for NiFi authorization) and NiFi Registry. I say this because we use ldap user/group sync for Ranger and ldap sync for NiFi Registry using ldap-user-group-provider.
>
> So in Ranger and NiFi Registry, the users are just listed as ‘bob’ and not ‘bob@dev’. That means I would manually have to add users to Ranger and NiFi Registry to add the ‘@dev’ part right? Or is there a way to customize that too?
>
> Hope I’m not overcomplicating this!
>
> Thanks,
> Chad
>
> On 11/19/18, 8:26 PM, "Koji Kawamura" <ij...@gmail.com> wrote:
>
> *External Message* - Use caution before opening links or attachments
>
> Hi Chad,
>
> NiFi Registry uses NiFi user's identity to authorize request.
> Registry also checks NiFi instance's identity to authorize proxying
> user requests, but this can only authorize proxy capability. In order
> to control access such as bucket read/write, Registry uses NiFi user's
> identity.
>
> I assume the kerberos identities are different among those
> environments (Dev, Cert and Prod). And Registry will have different
> user identities for those.
> E.g. for user Bob, Registry would have bob@dev, bob@cert and bob@prod
> Then you can define dev, cert and prod groups at Registry to give
> certain access to buckets.
> E.g. give read/write access to dev group, and give only read access to
> cert and prod groups for a bucket.
>
> In case your NiFi clusters use the same Kerberos domain, you can use
> NiFi identity mapping to map the same Kerberos principal to
> environment aware ones, so that the above authorization can be
> configured at NiFi Registry.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nifi.apache.org_docs_nifi-2Ddocs_html_administration-2Dguide.html-23identity-2Dmapping-2Dproperties&d=DwIFaQ&c=gJN2jf8AyP5Q6Np0yWY19w&r=MJ04HXP0mOz9-J4odYRNRx3ln4A_OnHTjJvmsZOEG64&m=lFWN8OtWhTL6eW3O-K1-lwIDlC0ZViDDrxxFSys2-Lw&s=_4v5XehCxEQZKSAr800935KuCtiECO-BQGkPknz5Gg4&e=
>
> Thanks,
> Koji
>
>
> On Tue, Nov 20, 2018 at 1:38 AM Woodhead, Chad <Ch...@ncr.com> wrote:
> >
> > I am standing up 3 new HDF 3.2 clusters (Dev, Cert, and Prod) and we will be focusing on NiFi (1.7.0) + NiFi Registry (0.2.0). We are using git as our FlowPersistenceProvider. My plan is to use 1 NiFi Registry (the Prod NiFi registry) for all 3 clusters, rather than having 3 NiFi Registries and trying to keep the DB’s in sync between the 3 NiFi Registry instances.
> >
> >
> >
> > Is there a way to implement some type of authorization so that users can only PUSH/PULL changes from Dev NiFi to Prod NiFi Registry, and only PULL from Cert and Prod NiFi from Prod NiFi Registry?
> >
> >
> >
> > NiFi and NiFi Registry both use the ‘kerberos-identity-provider’ for authentication, and the Prod NiFi Registry authenticates with git via a ssh access key.
> >
> >
> >
> > Thanks,
> >
> > Chad
>
> --
>
> Sent from Gmail Mobile
Re: Multiple NiFi clusters with 1 NiFi Rigistry
Posted by Kevin Doran <kd...@gmail.com>.
I think Bryan’s correct that this makes a good feature request for Registry.
One idea is if you are able to set separate policies for production NiFi and non-production NiFi, then you could limit the user policies to read only for the NiFi canvas / process group and only allow a service account or admin have write access to that NiFi.
NiFi registry would still technically be writable by those users, but it would prevent them from doing something like making a change in the production NiFi and then saving that version to Registry. It would be a safe guard to make sure changes get introduced to the Registry copy from non-production NiFis.
Regards,
Kevin
From: Bryan Bende <bb...@gmail.com>
Reply-To: "users@nifi.apache.org" <us...@nifi.apache.org>
Date: Tuesday, November 20, 2018 at 08:28
To: "users@nifi.apache.org" <us...@nifi.apache.org>
Subject: Re: Multiple NiFi clusters with 1 NiFi Rigistry
I think we would need to build some type of feature into registry to truly support this. Possibly a more specific policy for proxies so that we could say Dev NiFi can proxy read and write requests, and prod NiFi can only proxy read requests. Currently it would only really work if you had separate Kerberos domains, or weren’t using ranger.
On Tue, Nov 20, 2018 at 6:25 AM Woodhead, Chad <Ch...@ncr.com>> wrote:
Hi Koji,
Unfortunately all of my NiFi clusters use the same Kerberos domain, which is making this harder.
Using NiFi identity mappings to map the same Kerberos principal to environment aware ones seems like a good idea, but I’m thinking there will then be a disconnect for Ranger (used for NiFi authorization) and NiFi Registry. I say this because we use ldap user/group sync for Ranger and ldap sync for NiFi Registry using ldap-user-group-provider.
So in Ranger and NiFi Registry, the users are just listed as ‘bob’ and not ‘bob@dev’. That means I would manually have to add users to Ranger and NiFi Registry to add the ‘@dev’ part right? Or is there a way to customize that too?
Hope I’m not overcomplicating this!
Thanks,
Chad
On 11/19/18, 8:26 PM, "Koji Kawamura" <ij...@gmail.com>> wrote:
*External Message* - Use caution before opening links or attachments
Hi Chad,
NiFi Registry uses NiFi user's identity to authorize request.
Registry also checks NiFi instance's identity to authorize proxying
user requests, but this can only authorize proxy capability. In order
to control access such as bucket read/write, Registry uses NiFi user's
identity.
I assume the kerberos identities are different among those
environments (Dev, Cert and Prod). And Registry will have different
user identities for those.
E.g. for user Bob, Registry would have bob@dev, bob@cert and bob@prod
Then you can define dev, cert and prod groups at Registry to give
certain access to buckets.
E.g. give read/write access to dev group, and give only read access to
cert and prod groups for a bucket.
In case your NiFi clusters use the same Kerberos domain, you can use
NiFi identity mapping to map the same Kerberos principal to
environment aware ones, so that the above authorization can be
configured at NiFi Registry.
https://urldefense.proofpoint.com/v2/url?u=https-3A__nifi.apache.org_docs_nifi-2Ddocs_html_administration-2Dguide.html-23identity-2Dmapping-2Dproperties&d=DwIFaQ&c=gJN2jf8AyP5Q6Np0yWY19w&r=MJ04HXP0mOz9-J4odYRNRx3ln4A_OnHTjJvmsZOEG64&m=lFWN8OtWhTL6eW3O-K1-lwIDlC0ZViDDrxxFSys2-Lw&s=_4v5XehCxEQZKSAr800935KuCtiECO-BQGkPknz5Gg4&e=
Thanks,
Koji
On Tue, Nov 20, 2018 at 1:38 AM Woodhead, Chad <Ch...@ncr.com>> wrote:
>
> I am standing up 3 new HDF 3.2 clusters (Dev, Cert, and Prod) and we will be focusing on NiFi (1.7.0) + NiFi Registry (0.2.0). We are using git as our FlowPersistenceProvider. My plan is to use 1 NiFi Registry (the Prod NiFi registry) for all 3 clusters, rather than having 3 NiFi Registries and trying to keep the DB’s in sync between the 3 NiFi Registry instances.
>
>
>
> Is there a way to implement some type of authorization so that users can only PUSH/PULL changes from Dev NiFi to Prod NiFi Registry, and only PULL from Cert and Prod NiFi from Prod NiFi Registry?
>
>
>
> NiFi and NiFi Registry both use the ‘kerberos-identity-provider’ for authentication, and the Prod NiFi Registry authenticates with git via a ssh access key.
>
>
>
> Thanks,
>
> Chad
--
Sent from Gmail Mobile
Re: Multiple NiFi clusters with 1 NiFi Rigistry
Posted by Bryan Bende <bb...@gmail.com>.
I think we would need to build some type of feature into registry to truly
support this. Possibly a more specific policy for proxies so that we could
say Dev NiFi can proxy read and write requests, and prod NiFi can only
proxy read requests. Currently it would only really work if you had
separate Kerberos domains, or weren’t using ranger.
On Tue, Nov 20, 2018 at 6:25 AM Woodhead, Chad <Ch...@ncr.com>
wrote:
> Hi Koji,
>
> Unfortunately all of my NiFi clusters use the same Kerberos domain, which
> is making this harder.
>
> Using NiFi identity mappings to map the same Kerberos principal to
> environment aware ones seems like a good idea, but I’m thinking there will
> then be a disconnect for Ranger (used for NiFi authorization) and NiFi
> Registry. I say this because we use ldap user/group sync for Ranger and
> ldap sync for NiFi Registry using ldap-user-group-provider.
>
> So in Ranger and NiFi Registry, the users are just listed as ‘bob’ and not
> ‘bob@dev’. That means I would manually have to add users to Ranger and
> NiFi Registry to add the ‘@dev’ part right? Or is there a way to customize
> that too?
>
> Hope I’m not overcomplicating this!
>
> Thanks,
> Chad
>
> On 11/19/18, 8:26 PM, "Koji Kawamura" <ij...@gmail.com> wrote:
>
> *External Message* - Use caution before opening links or attachments
>
> Hi Chad,
>
> NiFi Registry uses NiFi user's identity to authorize request.
> Registry also checks NiFi instance's identity to authorize proxying
> user requests, but this can only authorize proxy capability. In order
> to control access such as bucket read/write, Registry uses NiFi user's
> identity.
>
> I assume the kerberos identities are different among those
> environments (Dev, Cert and Prod). And Registry will have different
> user identities for those.
> E.g. for user Bob, Registry would have bob@dev, bob@cert and bob@prod
> Then you can define dev, cert and prod groups at Registry to give
> certain access to buckets.
> E.g. give read/write access to dev group, and give only read access to
> cert and prod groups for a bucket.
>
> In case your NiFi clusters use the same Kerberos domain, you can use
> NiFi identity mapping to map the same Kerberos principal to
> environment aware ones, so that the above authorization can be
> configured at NiFi Registry.
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nifi.apache.org_docs_nifi-2Ddocs_html_administration-2Dguide.html-23identity-2Dmapping-2Dproperties&d=DwIFaQ&c=gJN2jf8AyP5Q6Np0yWY19w&r=MJ04HXP0mOz9-J4odYRNRx3ln4A_OnHTjJvmsZOEG64&m=lFWN8OtWhTL6eW3O-K1-lwIDlC0ZViDDrxxFSys2-Lw&s=_4v5XehCxEQZKSAr800935KuCtiECO-BQGkPknz5Gg4&e=
>
> Thanks,
> Koji
>
>
> On Tue, Nov 20, 2018 at 1:38 AM Woodhead, Chad <Ch...@ncr.com>
> wrote:
> >
> > I am standing up 3 new HDF 3.2 clusters (Dev, Cert, and Prod) and we
> will be focusing on NiFi (1.7.0) + NiFi Registry (0.2.0). We are using git
> as our FlowPersistenceProvider. My plan is to use 1 NiFi Registry (the Prod
> NiFi registry) for all 3 clusters, rather than having 3 NiFi Registries and
> trying to keep the DB’s in sync between the 3 NiFi Registry instances.
> >
> >
> >
> > Is there a way to implement some type of authorization so that users
> can only PUSH/PULL changes from Dev NiFi to Prod NiFi Registry, and only
> PULL from Cert and Prod NiFi from Prod NiFi Registry?
> >
> >
> >
> > NiFi and NiFi Registry both use the ‘kerberos-identity-provider’ for
> authentication, and the Prod NiFi Registry authenticates with git via a ssh
> access key.
> >
> >
> >
> > Thanks,
> >
> > Chad
>
>
> --
Sent from Gmail Mobile
Re: Multiple NiFi clusters with 1 NiFi Rigistry
Posted by "Woodhead, Chad" <Ch...@ncr.com>.
Hi Koji,
Unfortunately all of my NiFi clusters use the same Kerberos domain, which is making this harder.
Using NiFi identity mappings to map the same Kerberos principal to environment aware ones seems like a good idea, but I’m thinking there will then be a disconnect for Ranger (used for NiFi authorization) and NiFi Registry. I say this because we use ldap user/group sync for Ranger and ldap sync for NiFi Registry using ldap-user-group-provider.
So in Ranger and NiFi Registry, the users are just listed as ‘bob’ and not ‘bob@dev’. That means I would manually have to add users to Ranger and NiFi Registry to add the ‘@dev’ part right? Or is there a way to customize that too?
Hope I’m not overcomplicating this!
Thanks,
Chad
On 11/19/18, 8:26 PM, "Koji Kawamura" <ij...@gmail.com> wrote:
*External Message* - Use caution before opening links or attachments
Hi Chad,
NiFi Registry uses NiFi user's identity to authorize request.
Registry also checks NiFi instance's identity to authorize proxying
user requests, but this can only authorize proxy capability. In order
to control access such as bucket read/write, Registry uses NiFi user's
identity.
I assume the kerberos identities are different among those
environments (Dev, Cert and Prod). And Registry will have different
user identities for those.
E.g. for user Bob, Registry would have bob@dev, bob@cert and bob@prod
Then you can define dev, cert and prod groups at Registry to give
certain access to buckets.
E.g. give read/write access to dev group, and give only read access to
cert and prod groups for a bucket.
In case your NiFi clusters use the same Kerberos domain, you can use
NiFi identity mapping to map the same Kerberos principal to
environment aware ones, so that the above authorization can be
configured at NiFi Registry.
https://urldefense.proofpoint.com/v2/url?u=https-3A__nifi.apache.org_docs_nifi-2Ddocs_html_administration-2Dguide.html-23identity-2Dmapping-2Dproperties&d=DwIFaQ&c=gJN2jf8AyP5Q6Np0yWY19w&r=MJ04HXP0mOz9-J4odYRNRx3ln4A_OnHTjJvmsZOEG64&m=lFWN8OtWhTL6eW3O-K1-lwIDlC0ZViDDrxxFSys2-Lw&s=_4v5XehCxEQZKSAr800935KuCtiECO-BQGkPknz5Gg4&e=
Thanks,
Koji
On Tue, Nov 20, 2018 at 1:38 AM Woodhead, Chad <Ch...@ncr.com> wrote:
>
> I am standing up 3 new HDF 3.2 clusters (Dev, Cert, and Prod) and we will be focusing on NiFi (1.7.0) + NiFi Registry (0.2.0). We are using git as our FlowPersistenceProvider. My plan is to use 1 NiFi Registry (the Prod NiFi registry) for all 3 clusters, rather than having 3 NiFi Registries and trying to keep the DB’s in sync between the 3 NiFi Registry instances.
>
>
>
> Is there a way to implement some type of authorization so that users can only PUSH/PULL changes from Dev NiFi to Prod NiFi Registry, and only PULL from Cert and Prod NiFi from Prod NiFi Registry?
>
>
>
> NiFi and NiFi Registry both use the ‘kerberos-identity-provider’ for authentication, and the Prod NiFi Registry authenticates with git via a ssh access key.
>
>
>
> Thanks,
>
> Chad
Re: Multiple NiFi clusters with 1 NiFi Rigistry
Posted by Koji Kawamura <ij...@gmail.com>.
Hi Chad,
NiFi Registry uses NiFi user's identity to authorize request.
Registry also checks NiFi instance's identity to authorize proxying
user requests, but this can only authorize proxy capability. In order
to control access such as bucket read/write, Registry uses NiFi user's
identity.
I assume the kerberos identities are different among those
environments (Dev, Cert and Prod). And Registry will have different
user identities for those.
E.g. for user Bob, Registry would have bob@dev, bob@cert and bob@prod
Then you can define dev, cert and prod groups at Registry to give
certain access to buckets.
E.g. give read/write access to dev group, and give only read access to
cert and prod groups for a bucket.
In case your NiFi clusters use the same Kerberos domain, you can use
NiFi identity mapping to map the same Kerberos principal to
environment aware ones, so that the above authorization can be
configured at NiFi Registry.
https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#identity-mapping-properties
Thanks,
Koji
On Tue, Nov 20, 2018 at 1:38 AM Woodhead, Chad <Ch...@ncr.com> wrote:
>
> I am standing up 3 new HDF 3.2 clusters (Dev, Cert, and Prod) and we will be focusing on NiFi (1.7.0) + NiFi Registry (0.2.0). We are using git as our FlowPersistenceProvider. My plan is to use 1 NiFi Registry (the Prod NiFi registry) for all 3 clusters, rather than having 3 NiFi Registries and trying to keep the DB’s in sync between the 3 NiFi Registry instances.
>
>
>
> Is there a way to implement some type of authorization so that users can only PUSH/PULL changes from Dev NiFi to Prod NiFi Registry, and only PULL from Cert and Prod NiFi from Prod NiFi Registry?
>
>
>
> NiFi and NiFi Registry both use the ‘kerberos-identity-provider’ for authentication, and the Prod NiFi Registry authenticates with git via a ssh access key.
>
>
>
> Thanks,
>
> Chad