Hello, The correct approach should be # 1, removing the write and delete proxy permissions so that no write or delete operations can be sent from the given nifi instance.
The NiFi node users should only have READ on the special permissions bucket to be able to read all buckets. This is because the status of each PG is calculated in a background thread in NiFi where the request is being made to registry as the NiFi user itself (no proxying of an end user) to retrieve the latest version of the flow. The special permissions take precedence over the specific bucket permissions, so even if bucket1 has a policy that only user1 has READ, the NiFi User will still have READ access if it has the special permissions READ for buckets. I'm not sure I totally follow your # 2, but overall I don't think there is a way to make a whole nifi instance only be able to write to a specific bucket. It would require moving the proxy concept from top-level to bucket-level so that you could specify that a given NiFi node user can only proxy WRITE and DELETE to this specific bucket. -Bryan On Wed, Sep 15, 2021 at 5:30 PM Shawn Weeks <swe...@weeksconsulting.us> wrote: > > Hi, I’m trying to configure NiFi Registry(1.14.0) so that some NiFi (1.14.0) > instances are only able to pull versions and not push them. The behavior I > ran into was not as intuitive as I’d have liked. > > > > Here is what I tried. > > Remove Write and Delete permission from NiFi Proxy User. This causes an error > to raise when you try and commit a version from that cluster about the proxy > user not having permission. > Removed Write and Delete from NiFi User on the bucket but left write and > delete on the proxy user. This caused the versioned process group to switch > to a question mark and not allow any further interaction except stop version > control. > > > > Number 1 works by preventing any writes however what if I want to limit write > at the bucket level not at the cluster level. Number 2 seems bug-like since > I’d expect an exception to popup or the commit option to be greyed out > instead of leaving the process group in stuck state. > > > > Or maybe I’m just being dumb and trying to do this the wrong way, does anyone > have a suggestion? > > > > > > Thanks > > Shawn
