Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

write access on a process-group always creates write access on NifiFlow process group (top level) #419

Open
koehljaSICKAG opened this issue Apr 19, 2024 · 8 comments
Labels
bug Something isn't working community

Comments

@koehljaSICKAG
Copy link

What steps will reproduce the bug?

  1. create a NifiUser (user0)
  2. create a NifiUserGroup with the same priviledges as nifi.managed-readers (read all)
  3. create a ProcessGroup using the ui on the root canvas of nifi.
  4. write down the id of that ProcessGroup (f02c2450-018e-1000-0000-0000771ba5bc)
  5. Create a NifiUserGroup which gives write access to that ProcessGroup
apiVersion: nifi.konpyutaika.com/v1
kind: NifiUserGroup
metadata:
  name: custom.smax
spec:
  accessPolicies:
  - action: write
    resource: /
    type: component
    componentType: process-groups
    componentId: f02c2450-018e-1000-0000-0000771ba5bc
  clusterRef:
    name: nifi
    namespace: nifi
  usersRef:
    - name: user0

What is the expected behavior?

The user should now have read access to everything and write access only on everything below the ProcessGroup f02c2450-018e-1000-0000-0000771ba5bc

This should result in a user file like this

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tenants>
    <groups>
...
        <group identifier="f016bc45-018e-1000-ffff-ffffe2e74193" name="nifi-custom.smax">
            <user identifier="f016214d-018e-1000-0000-00001c8fe18d"/>
        </group>
        <group identifier="f0241a9c-018e-1000-ffff-ffffc6e93eb8" name="nifi-custom.reader">
            <user identifier="f016214d-018e-1000-0000-00001c8fe18d"/>
        </group>
    </groups>
    <users>
...
        <user identifier="f016214d-018e-1000-0000-00001c8fe18d" identity="[email protected]"/>
    </users>
</tenants>

and a authorizations.xml like this

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<authorizations>
    <policies>
 ...
        <policy identifier="e65bf9bd-018e-1000-0000-0000185a668c" resource="/process-groups/f0241a9c-018e-1000-ffff-ffffc6e93eb8" action="W">
            <group identifier="f009239c-018e-1000-0000-00007550c632"/>
            <group identifier="f016bc45-018e-1000-ffff-ffffe2e74193"/>
            <group identifier="f01673ce-018e-1000-0000-00000a3668b1"/>
        </policy>
 ...
    </policies>
</authorizations>

the important part is this resource="/process-groups/f0241a9c-018e-1000-ffff-ffffc6e93eb8". here should be the componentId of the process group specified above.

What do you see instead?

Instead the user gets write access from the top canvas (NifiFlow, e65a4f68-018e-1000-1027-316d1d593bd6) down. He bascially gests global write by this setting.

In the authorizations.xml one can see the error.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<authorizations>
    <policies>
 ...
        <policy identifier="e65bf9bd-018e-1000-0000-0000185a668c" resource="/process-groups/e65a4f68-018e-1000-1027-316d1d593bd6" action="W">
            <group identifier="f009239c-018e-1000-0000-00007550c632"/>
            <group identifier="f016bc45-018e-1000-ffff-ffffe2e74193"/>
            <group identifier="f01673ce-018e-1000-0000-00000a3668b1"/>
        </policy>
 ...
    </policies>
</authorizations>

nifikop added the the group the the the main canvas resource="/process-groups/e65a4f68-018e-1000-1027-316d1d593bd6" with a write priviledge

Possible solution

No response

NiFiKop version

v1.8.0

Golang version

1.22.1

Kubernetes version

Client Version: v1.28.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.4+k0s

NiFi version

1.24.0

Additional context

this also happend using nifikop 1.6 with nifi 1.23.2

@koehljaSICKAG koehljaSICKAG added bug Something isn't working community labels Apr 19, 2024
@mh013370
Copy link
Member

This does seem like an issue. Thank you for reporting. Will dig into this.

@mh013370
Copy link
Member

mh013370 commented Apr 19, 2024

I think this is an unusual use case, since nifikop is designed to deploy & access control versioned process groups from NiFi registry, but it should be able to assume control of existing or manually created process groups as well. So i think we should address this.

@mh013370
Copy link
Member

@koehljaSICKAG : Can you please share the entire authorizations.xml and users.xml that gets generated in your case?

@koehljaSICKAG
Copy link
Author

@mh013370 here are the files. i just changed the identity tag of user0 and user1. besides that it is as it is in the container. I also included the NifiUserGroup yml for you to see the correct component id. the id of the root canvas is f560ea4e-018e-1000-52c7-4bb47cffdf7d.

users.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tenants>
    <groups>
        <group identifier="f562632d-018e-1000-ffff-ffffd8193d96" name="nifi-nifi.managed-admins">
            <user identifier="04df347d-018f-1000-0000-00000f1c8447"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </group>
        <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0" name="nifi-nifi.managed-readers">
            <user identifier="f5626843-018e-1000-0000-00004548e31c"/>
        </group>
        <group identifier="f56278fa-018e-1000-ffff-ffff88d978f1" name="nifi-nifi.managed-nodes">
            <user identifier="198fdabb-bbf2-347b-ac56-8516587efed6"/>
        </group>
        <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb" name="nifi-custom.reader">
            <user identifier="f585211d-018e-1000-0000-0000088cac1d"/>
        </group>
        <group identifier="f58beaaa-018e-1000-0000-00006da00fee" name="nifi-custom.smax">
            <user identifier="f585211d-018e-1000-0000-0000088cac1d"/>
        </group>
    </groups>
    <users>
        <user identifier="198fdabb-bbf2-347b-ac56-8516587efed6" identity="nifi-1-node.nifi-headless.nifi.svc.cluster.local"/>
        <user identifier="00b12756-f761-329c-a808-51d31ba1c610" identity="nifi-controller"/>
        <user identifier="f5626843-018e-1000-0000-00004548e31c" identity="[email protected]"/>
        <user identifier="f585211d-018e-1000-0000-0000088cac1d" identity="[email protected]"/>
        <user identifier="04df347d-018f-1000-0000-00000f1c8447" identity="[email protected]"/>
    </users>
</tenants>

authorizations.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<authorizations>
    <policies>
        <policy identifier="f99bccd1-a30e-3e4a-98a2-dbc708edc67f" resource="/flow" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="b8775bd4-704a-34c6-987b-84f2daf7a515" resource="/restricted-components" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="627410be-1717-35b4-a06f-e9362b89e0b7" resource="/tenants" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="15e4e0bd-cb28-34fd-8587-f8d15162cba5" resource="/tenants" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="ff96062a-fa99-36dc-9942-0f6442ae7212" resource="/policies" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="ad99ea98-3af6-3561-ae27-5bf09e1d969d" resource="/policies" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="2e1015cb-0fed-3005-8e0d-722311f21a03" resource="/controller" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="c6322e6c-4cc1-3bcc-91b3-2ed2111674cf" resource="/controller" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="287edf48-da72-359b-8f61-da5d4c45a270" resource="/proxy" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <user identifier="198fdabb-bbf2-347b-ac56-8516587efed6"/>
        </policy>
        <policy identifier="f5624a1e-018e-1000-ffff-fffff6018cd3" resource="/proxy" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
            <group identifier="f56278fa-018e-1000-ffff-ffff88d978f1"/>
            <user identifier="198fdabb-bbf2-347b-ac56-8516587efed6"/>
        </policy>
        <policy identifier="f5624b61-018e-1000-ffff-fffff07e74f2" resource="/flow" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="f5624c14-018e-1000-ffff-ffffd500bf27" resource="/restricted-components" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
            <user identifier="00b12756-f761-329c-a808-51d31ba1c610"/>
        </policy>
        <policy identifier="f5626645-018e-1000-0000-00005d64a752" resource="/parameter-context" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
        </policy>
        <policy identifier="f56266fb-018e-1000-0000-00004aae4274" resource="/parameter-context" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
        </policy>
        <policy identifier="f56267d2-018e-1000-0000-000050b77c8c" resource="/provenance" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
        </policy>
        <policy identifier="f5626892-018e-1000-ffff-ffffbe714732" resource="/provenance" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
        </policy>
        <policy identifier="f5626c04-018e-1000-ffff-ffffc46d82dd" resource="/site-to-site" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
        </policy>
        <policy identifier="f5626c8d-018e-1000-ffff-ffffe0383cbf" resource="/system" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
        </policy>
        <policy identifier="f5626d20-018e-1000-0000-00000a199f00" resource="/site-to-site" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
        </policy>
        <policy identifier="f5626e78-018e-1000-ffff-ffff989d7225" resource="/counters" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
        </policy>
        <policy identifier="f5626f08-018e-1000-0000-00001222df50" resource="/counters" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
        </policy>
        <policy identifier="f5626f93-018e-1000-ffff-ffffb2b5e0d4" resource="/process-groups/f560ea4e-018e-1000-52c7-4bb47cffdf7d" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
        </policy>
        <policy identifier="f5627020-018e-1000-ffff-ffff91b6b892" resource="/process-groups/f560ea4e-018e-1000-52c7-4bb47cffdf7d" action="W">
            <group identifier="f58beaaa-018e-1000-0000-00006da00fee"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
        </policy>
        <policy identifier="f56270b1-018e-1000-ffff-ffffb61cb75b" resource="/operation/process-groups/f560ea4e-018e-1000-52c7-4bb47cffdf7d" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
        </policy>
        <policy identifier="f5627138-018e-1000-0000-00002732bca9" resource="/provenance-data/process-groups/f560ea4e-018e-1000-52c7-4bb47cffdf7d" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
            <group identifier="f56278fa-018e-1000-ffff-ffff88d978f1"/>
        </policy>
        <policy identifier="f56271be-018e-1000-ffff-ffffb4ce5e4f" resource="/data/process-groups/f560ea4e-018e-1000-52c7-4bb47cffdf7d" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
            <group identifier="f56278fa-018e-1000-ffff-ffff88d978f1"/>
        </policy>
        <policy identifier="f562724b-018e-1000-0000-00005a6caf21" resource="/data/process-groups/f560ea4e-018e-1000-52c7-4bb47cffdf7d" action="W">
            <group identifier="f562632d-018e-1000-ffff-ffffd8193d96"/>
            <group identifier="f56278fa-018e-1000-ffff-ffff88d978f1"/>
        </policy>
        <policy identifier="f56277c3-018e-1000-0000-000018f0f0a1" resource="/operation/process-groups/f560ea4e-018e-1000-52c7-4bb47cffdf7d" action="R">
            <group identifier="f56272ca-018e-1000-ffff-ffff8a3d5db0"/>
            <group identifier="f58be5ad-018e-1000-ffff-ffffb3f322fb"/>
        </policy>
        <policy identifier="f5627a60-018e-1000-ffff-ffffdaf26b28" resource="/provenance-data/process-groups/f560ea4e-018e-1000-52c7-4bb47cffdf7d" action="W">
            <group identifier="f56278fa-018e-1000-ffff-ffff88d978f1"/>
        </policy>
    </policies>
</authorizations>

grp.smax.yml

apiVersion: nifi.konpyutaika.com/v1
kind: NifiUserGroup
metadata:
  name: custom.smax
spec:
  accessPolicies:
  - action: write
    resource: /
    type: component
    componentType: process-groups
    componentId: f5892907-018e-1000-ffff-ffffb2346c55
  clusterRef:
    name: nifi
    namespace: nifi
  usersRef:
    - name: user0

@koehljaSICKAG
Copy link
Author

I think this is an unusual use case, since nifikop is designed to deploy & access control versioned process groups from NiFi registry, but it should be able to assume control of existing or manually created process groups as well. So i think we should address this.

@mh013370 but even when i am generating the flow DataFlow using a crd i would have to create a separate policy to give a group write access to this DataFlow. So I think the problem would stay the same

@mh013370
Copy link
Member

I think this is an unusual use case, since nifikop is designed to deploy & access control versioned process groups from NiFi registry, but it should be able to assume control of existing or manually created process groups as well. So i think we should address this.

@mh013370 but even when i am generating the flow DataFlow using a crd i would have to create a separate policy to give a group write access to this DataFlow. So I think the problem would stay the same

This is true. I had thought you could provide a NifiDataflow reference for a group, but that is not the case. Your complete example should help enable tracking down what's actually causing this. Thank you

@gmontymk33
Copy link

Any news on this?
It seems that the exact same behaviour happens when trying to do the same on a parameter-context level. Granting a specific user (user identifier "69a730cb-0191-1000-0000-000050681cf9") read access to a specific parameter context (pc identifier "33de34c3-e277-142e-0000-00005002524f"), the user gets granted read access to the global controller instead allowing read rights to all parameter contexts. The specific parameter contexts does appear as a policy at all in the authorizations.

apiVersion: nifi.konpyutaika.com/v1
kind: NifiUser
metadata:
  name: user
spec:
  identity: [email protected]
  clusterRef:
    name: simplenifi
    namespace: nifikop
  includeJKS: false
  createCert: false
  accessPolicies:
    - action: read
      resource: /flow
      type: global   
    - type: component
      action: read
      resource: /
      componentType: "parameter-context"
      componentId: "33de34c3-e277-142e-0000-00005002524f"

<policy identifier="2e1015cb-0fed-3005-8e0d-722311f21a03" resource="/controller" action="R">
  <user identifier="69a730cb-0191-1000-0000-000050681cf9"/>
  <user identifier="15bb23ad-b6d8-3f4c-9bee-ddf096e9e846"/>
</policy>

@gmontymk33
Copy link

gmontymk33 commented Aug 19, 2024

There is a way to bypass it.

If you override the policy of the specific process-group or parameter-context that is not behaving as intended, then on the new overridden policy the user/usergroup CR applies the desired policy as normal.
It seems that even though the CR requests a specific pg or pc policy, the actual policy that is applied and written in the authorizers is the inherited one from the Process Group NiFi Flow and the Controller policies respectively. Overriding those inherited policies seems to allow the CR component specific policy to be written. (or most likely to persist cause I assume it gets overwritten by the inherited ones or smthng).
I guess it has to do with the fact that since these resources automatically inherit the policies of the parent component, any modification on them is essentially trying to modify the parent policy which it can't. I would assume that if a User/UserGroup resource needs a component-level policy applied it would need to override the inherited policy of said component and create a new one rather than giving the User the policy that the component had inherited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working community
Projects
None yet
Development

No branches or pull requests

3 participants