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 <[email protected]> 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 <[email protected]>
> Reply-To: "[email protected]" <[email protected]>
> Date: Tuesday, November 20, 2018 at 08:28
> To: "[email protected]" <[email protected]>
> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 
> 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

Reply via email to