question Re: NIFI: "No available buckets" for saving flow version to nifi registry in Support Questions

question Re: NIFI: "No available buckets" for saving flow version to nifi registry in Support Questions https://community.cloudera.com/t5/Support-Questions/NIFI-quot-No-available-buckets-quot-for-saving-flow-version/m-p/326299#M229859 <a href="https://community.cloudera.com/t5/user/viewprofilepage/user-id/92470">@Theoo</a>  Nice job on your path to solving the authorization issues, but you left out a few pieces - When NiFi cluster nodes or a standalone NiFi instance communicates with a secured NiFi-Registry that communication MUST be authenticated and authorized in the NiFi-Registry side.  The established connection between NiFi and NiFi-Registry only supports authentication via a mutual TLS handshake (Client is identified via the certificate shared to the NiFi-Registry from NiFi).  Both NiFi and NiFi-Registry have identity mapping properties that can be added to the nifi-properties/nifi-registry.properties file that are used to manipulated the DN that comes from the client certificate.    For example a NiFi host certificate with DN of "CN=nifi-node01, OU=NIFI" could be manipulated so the client string is only "nifi-node-01". Users and NiFi nodes/instances to both NiFi and NiFi-Registry are just clients, there is no distinction between the two.  What matters is what each client is uniquely authorized to do within each service. Whatever the client string happens to be, The NiFi nodes/instance must be authorized for the following global policies in NiFi-Registry: "Can proxy user requests" (/proxy) with "Read, Write, and Delete" - This allows the NiFi nodes/instance to proxy some request made by the user authenticated in NiFi to perform some authorized request against NiFi-Registry (start version control, commit a new version of a version controlled Process Group (PG), etc.) since the NiFi user is not actually authenticating in to NiFi-Registry from NiFi. This does mean that the NiFi user string must exist as a user in NiFi-Registry and be authorized for the action they are trying perform. "Can Manage Buckets" (/buckets) with "Read" - This policy is needed by the NiFi nodes/instance so that the NiFi background thread that occasionally communicates with NiFi-Registry to see if newer version of a version controlled PG is available or so NiFi can display a list of available buckets).  This request is not done on behalf of the user authenticated into NiFi. <img src="https://community.cloudera.com/t5/image/serverpage/image-id/32565i5BA4934B3A37690A/image-size/medium?v=v2&px=400" role="button" title="MattWho_0-1633365611601.png" alt="MattWho_0-1633365611601.png" />---- When it comes to the NiFi user, the policies needed in NiFi-Registry vary based on what you want that user to be able to do through NiFi or directly via the NiFi-Registry UI. In order for a user who is currently authenticated and authorized in to NiFi to interact with NiFi-Registry, that user string would need to be authorized in NiFi-Registry for the following: - A NiFi-Registry admin user would need to create a bucket and authorize the NiFi user on that bucket so it can be used by the NiFi user.             - "READ" on the bucket would allow the user to import and existing version controlled flow from Nifi-Registry on the NiFi UI.              - "WRITE" on the bucket would allow the user to start version control or change the version of the versioned PG in NiFi.               - "Delete" on the bucket would allow a user who can authenticate in to NiFi-Registry to delete flows within that bucket.  <img src="https://community.cloudera.com/t5/image/serverpage/image-id/32566i3247DD1462B6CF97/image-size/medium?v=v2&px=400" role="button" title="MattWho_1-1633365681781.png" alt="MattWho_1-1633365681781.png" />-------- As far as authentication of users in to NiFi and/or NiFi-Registry, you can create certificates for each fo your users, but the most commonly used method is LDAP/AD based authentication.  You can add users in NiFi-Registry's authorizer so that those user string can be associated to authorization policies without those user even being able to authenticate and be authorized directly in to the NiFi-Registry's UI.  They simply need to exist for the proxied request that come from NiFi on that user's behalf.Hope this exposes all that is needed in this thread. Thanks, Matt Mon, 04 Oct 2021 16:48:16 GMT MattWho 2021-10-04T16:48:16Z