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]<mailto:[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]<mailto:[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]<mailto:[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