Created 10-06-2021 08:24 AM
I have a nifi instance running in kubernetes, I used the cetic/helm-nifi as the foundation although I did change some things to minimize the number of mounts to the server container.
Anyways, I can view the UI using admin certificate created during setup, and when I visit the UI page I basically cannot use any of the buttons up top to create flows/etc. I have attached pictures of my user policies and a picture of the top toolbar I'm talking about. When I hover my mouse over any of the icons in the toolbar I get a circle with a line through it ('do not enter' sign).
I assume I need additional permissions, but I'm not sure what to add (I'm guessing it will be an addition to the authorizations.xml file).
Created 10-07-2021 02:06 PM
@Ronman
I don't know anything about the cetic/helm-nifi image.
I assume you are talking about this:
https://github.com/cetic/helm-nifi
I started parsing through what is in the above github and the authorizers.xml that is built looks poorly done.
Can you share what is in your authorizers.xml file on your NiFi host?
The image looks to create numerous providers that are not actually used from what I can tell.
Looks like it creates:
1. file-user-group-provider
2. ldap-user-group-provider (only if ldap enabled)
3. composite-configurable-user-group-provider (Only if ldap enabled)
4. file-access-policy-provider. (Always points at file-user-user-group-provider which means 2 and 3 would never get used even if they were created)
5. managed-authorizer (points at file-access-policy-provider)
6. file-provider (only if LDAP enabled. This is a legacy provider and not sure why anyone would still use it. It can reference and of the above user-group providers)
So seeing what is actually written to that file might be helpful here.
Also on startup the Authorizers.xml is responsible for seeding some initial polciy for the admin user in the users.xml and authorizations.xml files. This would including the intial set of policies for the root PG. This will not happen if upon first launch of NiFi there was not flow.xml.gz yet and thus no flow.xml.gz containing the root PG UUID yet.
So you may want to rename your existing authorizations.xml file and restart your NiFi so that a new one is generated since you have a flow.xml.gz now and see if that gives you the policies you need to start editing the canvas.
But even if above works, it still think you have an issue within your authorizers.xml files configuration.
If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post.
Thank you,
Matt
Created 10-06-2021 08:54 AM
If I right click the canvas and attempt to give myself the permissions ('manage access policies'), there are no policies listed attempting to create one gives a 403 insufficient privileges error.
Created 10-06-2021 10:48 AM
It is interesting that you are seeing a 403 in response to trying to add a new policy on the root Process Group (PG).
By granting your user string (CN=admin, OU=NIFI) to the following global policies:
you should have ability to set any additional policies anywhere.
From the root canvas you can either right click and select "manage access policies" or click on the small key icon in the "Operate" panel that shows the PG name and PG assigned uuid to access the PG level access policies.
First you would select the policy you want to add user or group strings to from the pull-down menu.
If the policy has not yet had any users assigned to it, you'll need to click on "add policy" before being able to click on the Then click on the small "add users/groups to this policy" icon to the far right.
Note: Child PGs added to the canvas will by default inherit all their policies from the parent PG. You will be given option to "override" this and set child specific users/groups on that child PG.
You are stating that you encounter a 403 when you click on the "add" button?
What do you see in the nifi-user.log when you perform that action?
If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post.
Thank you,
Matt
Created on 10-06-2021 11:12 AM - edited 10-06-2021 11:38 AM
Thanks for your reply!
Yes I get a 403 insufficient privileges error when I try to create a new policy.
Here is the user log when I attempt to create the new policy (I removed references to my specific nifi instance, replaced with <nifi instance name>):
2021-10-06 18:05:57,749 INFO [NiFi Web Server-871] o.a.n.w.s.NiFiAuthenticationFilter Attempting request for (CN=admin, OU=NIFI) GET https://localhost:9443/nifi-api/policies/read/process-groups/288a1cba-017c-1000-73fe-2635722f1826 (source ip: 127.0.0.1)
2021-10-06 18:05:57,749 INFO [NiFi Web Server-871] o.a.n.w.s.NiFiAuthenticationFilter Authentication success for CN=admin, OU=NIFI
2021-10-06 18:05:57,751 INFO [NiFi Web Server-848] o.a.n.w.s.NiFiAuthenticationFilter Attempting request for (<CN=admin, OU=NIFI><CN=<nifi instance name>-0.<nifi instance name>-headless.nifi-test.svc.cluster.local, OU=NIFI>) GET https://localhost:9443/nifi-api/policies/read/process-groups/288a1cba-017c-1000-73fe-2635722f1826 (source ip: 127.0.0.1)
2021-10-06 18:05:57,751 INFO [NiFi Web Server-848] o.a.n.w.s.NiFiAuthenticationFilter Authentication success for CN=admin, OU=NIFI
2021-10-06 18:05:57,752 INFO [NiFi Web Server-848] o.a.n.w.a.c.ResourceNotFoundExceptionMapper org.apache.nifi.web.ResourceNotFoundException: Unable to find access policy for read on /process-groups/288a1cba-017c-1000-73fe-2635722f1826. Returning Not Found response.
Created 10-07-2021 05:54 AM
Created on 10-07-2021 06:10 AM - edited 10-07-2021 10:35 AM
Version 1.14.0
I used the cetic/helm-nifi image, and due to the number of mounted volumes I couldn't deploy it to kubernetes on my existing machine (there's like 8 or 9 config files that are mounted in addition to persistent storage), so I basically loaded those [modified] config files onto my base nifi image and moved them into the mounted directory locations as the container is started (I understand there may be some issues with persistence).
Created 10-07-2021 02:06 PM
@Ronman
I don't know anything about the cetic/helm-nifi image.
I assume you are talking about this:
https://github.com/cetic/helm-nifi
I started parsing through what is in the above github and the authorizers.xml that is built looks poorly done.
Can you share what is in your authorizers.xml file on your NiFi host?
The image looks to create numerous providers that are not actually used from what I can tell.
Looks like it creates:
1. file-user-group-provider
2. ldap-user-group-provider (only if ldap enabled)
3. composite-configurable-user-group-provider (Only if ldap enabled)
4. file-access-policy-provider. (Always points at file-user-user-group-provider which means 2 and 3 would never get used even if they were created)
5. managed-authorizer (points at file-access-policy-provider)
6. file-provider (only if LDAP enabled. This is a legacy provider and not sure why anyone would still use it. It can reference and of the above user-group providers)
So seeing what is actually written to that file might be helpful here.
Also on startup the Authorizers.xml is responsible for seeding some initial polciy for the admin user in the users.xml and authorizations.xml files. This would including the intial set of policies for the root PG. This will not happen if upon first launch of NiFi there was not flow.xml.gz yet and thus no flow.xml.gz containing the root PG UUID yet.
So you may want to rename your existing authorizations.xml file and restart your NiFi so that a new one is generated since you have a flow.xml.gz now and see if that gives you the policies you need to start editing the canvas.
But even if above works, it still think you have an issue within your authorizers.xml files configuration.
If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post.
Thank you,
Matt
Created 10-12-2021 11:09 AM
Thanks @MattWho I took a more thorough look at the authorizers.xml file and I had a bad path to the users.xml file in the file-provider. There may still be some issues with the way this is being deployed, but I'm able to interact with the canvas now, so it's progress.