feat: OPA Authorizer #777

labrenbe · 2025-04-15T08:51:48Z

Description

Adds support for authorization with OPA using Nifi OPA Plugin .

=== NAME  kuttl
    harness.go:408: run tests finished
    harness.go:516: cleaning up
    harness.go:573: removing temp folder: ""
--- PASS: kuttl (539.62s)
    --- PASS: kuttl/harness (0.00s)
        --- PASS: kuttl/harness/opa_nifi-1.27.0_zookeeper-latest-3.9.3_opa-latest-1.0.1_openshift-false (261.39s)
        --- PASS: kuttl/harness/opa_nifi-2.2.0_zookeeper-latest-3.9.3_opa-latest-1.0.1_openshift-false (268.44s)
        --- PASS: kuttl/harness/opa_nifi-1.28.1_zookeeper-latest-3.9.3_opa-latest-1.0.1_openshift-false (278.21s)
PASS

Should not be merged before: stackabletech/docker-images#1058

Definition of Done Checklist

Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
Please make sure all these things are done and tick the boxes

# Author
- [ ] Changes are OpenShift compatible
- [ ] CRD changes approved
- [ ] CRD documentation for all fields, following the [style guide](https://docs.stackable.tech/home/nightly/contributor/docs/style-guide).
- [ ] Helm chart can be installed and deployed operator works
- [ ] Integration tests passed (for non trivial changes)
- [ ] Changes need to be "offline" compatible

# Reviewer
- [ ] Code contains useful comments
- [ ] Code contains useful logging statements
- [ ] (Integration-)Test cases added
- [ ] Documentation added or updated. Follows the [style guide](https://docs.stackable.tech/home/nightly/contributor/docs/style-guide).
- [ ] Changelog updated
- [ ] Cargo.toml only contains references to git tags (not specific commits or branches)

# Acceptance
- [ ] Feature Tracker has been updated
- [ ] Proper release label has been added
- [ ] [Roadmap](https://github.com/orgs/stackabletech/projects/25/views/1) has been updated

maltesander

first batch of comments

maltesander · 2025-04-22T16:04:24Z

docs/modules/nifi/pages/usage_guide/security.adoc

@@ -168,7 +169,7 @@ stringData:

 NiFi supports {nifi-docs-authorization}[multiple authorization methods], the available authorization methods depend on the chosen authentication method.

-Authorization is not fully implemented by the Stackable Operator for Apache NiFi.
+The Stackable Operator for Apache NiFi supports a default authorization methods for each authentication method and authorization with Open Policy Agent.


I dont understand that sentence at all. Would you mind reformulating or explaining it?

I think the idea is that there are different default authorization methods depending on the authentication method and OPA authorization which works with every authentication method.

I feel then this can be merged with the sentence above?

The Stackable Operator for Apache NiFi supports {nifi-docs-authorization}[multiple authorization methods], the available authorization methods depend on the chosen authentication method. Using the Open Policy Agent for authorization is independent of the authentication method.

maltesander · 2025-04-22T16:09:38Z

docs/modules/nifi/pages/usage_guide/security.adoc

+        configMapName: simple-opa <1>
+        package: my-druid-rules <2>
+        cache:
+          entryTimeToLive: 5s <3>
+          maxEntries: 10 <4>


Suggested change

configMapName: simple-opa <1>

package: my-druid-rules <2>

cache:

entryTimeToLive: 5s <3>

maxEntries: 10 <4>

configMapName: simple-opa # <1>

package: my-nifi-rules # <2>

cache:

entryTimeToLive: 5s # <3>

maxEntries: 10 # <4>

maltesander · 2025-04-22T16:11:16Z

docs/modules/nifi/pages/usage_guide/security.adoc

+{
+    "action": {
+        "name": <String> <1>
+    },
+    "properties": {
+        "isAccessAttempt": <String>, <2>
+        "isAnonymous": <String> <3>
+    },
+    "resource": { <4>
+        "id": <String>,
+        "name": <String>,
+        "safeDescription": <String>
+    },
+    "requestedResource": { <5>
+        "id": <String>,
+        "name": <String>,
+        "safeDescription": <String>
+    },
+    "identity": {
+        "name": <String>, <6>
+        "groups": String, <7>
+    },
+    "resourceContext": <Object>, <8>
+    "userContext": <Object> <9>
+}


the footnotes do not render correcly

maltesander · 2025-04-22T16:11:58Z

docs/modules/nifi/pages/usage_guide/security.adoc

+    "userContext": <Object> <9>
+}
+----
+<1> The action taken against the resource. Possible values: `"read"` or `"write"`.


I think ticking or quoting is enough?

Suggested change

<1> The action taken against the resource. Possible values: `"read"` or `"write"`.

<1> The action taken against the resource. Possible values: `read` or `write`.

maltesander · 2025-04-23T15:19:54Z

docs/modules/nifi/pages/usage_guide/security.adoc

+
+=== Defining rego rules
+
+For a general explanation of how rules are written, please refer to the {opa-rego-docs}[OPA documentation]. For more information on NiFi's access policies please refer to the  {nifi-docs-access-policies}[NiFi documentation].


Suggested change

For a general explanation of how rules are written, please refer to the {opa-rego-docs}[OPA documentation]. For more information on NiFi's access policies please refer to the {nifi-docs-access-policies}[NiFi documentation].

For a general explanation of how rules are written, please refer to the {opa-rego-docs}[OPA documentation]. For more information on NiFi's access policies please refer to the {nifi-docs-access-policies}[NiFi documentation].

maltesander · 2025-04-23T15:22:52Z

docs/modules/nifi/pages/usage_guide/security.adoc

+
+For a general explanation of how rules are written, please refer to the {opa-rego-docs}[OPA documentation]. For more information on NiFi's access policies please refer to the  {nifi-docs-access-policies}[NiFi documentation].
+
+Inside of your rego rules you have access to the content of the authorization request from NiFi as input for OPA:


Suggested change

Inside of your rego rules you have access to the content of the authorization request from NiFi as input for OPA:

The payload sent by NiFi with each request to OPA, that is accessible within the rego rules, has the following structure:

maltesander · 2025-04-23T15:23:34Z

docs/modules/nifi/pages/usage_guide/security.adoc

+          maxEntries: 10 <4>
+----
+<1> The name of your OPA Stacklet (`simple-opa` in this case)
+<2> The RegoRule package to use for policy decisions.


I would go for "rego rule" instead of "RegoRule" as in other cases.

maltesander · 2025-04-23T15:28:48Z

docs/modules/nifi/pages/usage_guide/security.adoc

+<3> Whether the entity accessing the resource is anonymous. Possible values: `"true"` or `"false"`.
+<4> The current resource being authorized on.
+<5> The original resource being requested. In cases with inherited policies, this will be an ancestor resource of the current resource. For the initial request, and cases without inheritance, the requested resource will be the same as the current resource.


I think this whole section is probably best displayed as table. Something like:

payload - description - possible values
action.name - The action taken against the resource - read/write

maltesander · 2025-04-23T15:36:01Z

rust/operator-binary/src/crd/mod.rs

+        /// Read more about authentication in the [security documentation](DOCS_BASE_URL_PLACEHOLDER/nifi/usage_guide/security#_authentication).
        // We don't add `#[serde(default)]` here, as we require authentication
        pub authentication: Vec<ClientAuthenticationDetails>,

+        /// Authorization options.
+        /// Learn more in the [NiFi authorization usage guide](DOCS_BASE_URL_PLACEHOLDER/nifi/usage-guide/security#authorization).


It fixes "security#_authentication", shouldnt it be "security#_authorization" as well (or the other way round)?

maltesander

I think we should already prepare a more extensive test environment.
Meaning having a couple of users in keycloak with different access in the regos that can be tested via API and easily extended?

maltesander · 2025-05-08T12:36:50Z

docs/modules/nifi/pages/usage_guide/security.adoc

+    authorization:
+      opa:
+        configMapName: simple-opa <1>
+        package: my-druid-rules <2>


Suggested change

package: my-druid-rules <2>

package: my-nifi-rules <2>

maltesander · 2025-05-08T12:37:43Z

docs/modules/nifi/pages/usage_guide/security.adoc

+<1> The name of your OPA Stacklet (`simple-opa` in this case)
+<2> The RegoRule package to use for policy decisions.
+The package needs to contain an `allow` rule.
+This is optional and defaults to the name of the Druid Stacklet.


Suggested change

This is optional and defaults to the name of the Druid Stacklet.

This is optional and defaults to the name of the NiFi Stacklet.

rust/operator-binary/src/main.rs

maltesander · 2025-05-16T09:57:35Z

docs/modules/nifi/pages/usage_guide/security.adoc

@@ -168,7 +169,7 @@ stringData:

 NiFi supports {nifi-docs-authorization}[multiple authorization methods], the available authorization methods depend on the chosen authentication method.

-Authorization is not fully implemented by the Stackable Operator for Apache NiFi.
+The Stackable Operator for Apache NiFi supports a default authorization methods for each authentication method and authorization with Open Policy Agent.


I feel then this can be merged with the sentence above?

The Stackable Operator for Apache NiFi supports {nifi-docs-authorization}[multiple authorization methods], the available authorization methods depend on the chosen authentication method. Using the Open Policy Agent for authorization is independent of the authentication method.

maltesander · 2025-05-16T10:01:05Z

docs/modules/nifi/pages/usage_guide/security.adoc

+[#opa-result]
+==== OPA Result
+
+The OPA authorizer plugin expects relo rules to be named `allow` and to return a result following this schema:


Suggested change

The OPA authorizer plugin expects relo rules to be named `allow` and to return a result following this schema:

The OPA authorizer plugin expects rego rules to be named `allow` and to return a result following this schema:

maltesander · 2025-05-16T10:03:46Z

docs/modules/nifi/pages/usage_guide/security.adoc

+[#component-level-access-policies]
+==== Component Level Access Policies and Access Policy Inheritance
+
+{nifi-docs-component-level-access-policies}[Component Level Access Policies] allow managing granular access to components like process-groups and processors. Components can {nifi-docs-access-policy-inheritance}[inherite access policies] defined for parent components, e.g. a process group is the parent component for a processor component.


Suggested change

{nifi-docs-component-level-access-policies}[Component Level Access Policies] allow managing granular access to components like process-groups and processors. Components can {nifi-docs-access-policy-inheritance}[inherite access policies] defined for parent components, e.g. a process group is the parent component for a processor component.

{nifi-docs-component-level-access-policies}[Component Level Access Policies] allow managing granular access to components like process-groups and processors. Components can {nifi-docs-access-policy-inheritance}[inherite access policies] defined for parent components, e.g. a process group is the parent component for a contained processor component.

maltesander · 2025-05-16T10:56:09Z

docs/modules/nifi/pages/usage_guide/security.adoc

+  input.identity.name == "alice"
+} <3>
+----
+<1> Default rule returns should `"resourceNotFound": true`. If this is not set NiFi's access policy inheritance won't work. Any values for the `allowed` field in the response will be ignored.


Suggested change

<1> Default rule returns should `"resourceNotFound": true`. If this is not set NiFi's access policy inheritance won't work. Any values for the `allowed` field in the response will be ignored.

<1> The default rule should return `"resourceNotFound": true`. If this is not set, NiFi's access policy inheritance will not work. Any values for the `allowed` field in the response will be ignored.

labrenbe added 7 commits March 28, 2025 10:18

add support for authorization with OPA

88944a6

add docs on authorization with OPA

142f867

update helm chart

e603d7d

Merge remote-tracking branch 'origin/main' into feat/opa-authorizer

39caff2

rename input.user to input.identity

032ab37

Merge remote-tracking branch 'origin/main' into feat/opa-authorizer

4470e83

add opa cm watch

6bd4831

labrenbe self-assigned this Apr 15, 2025

labrenbe marked this pull request as ready for review April 15, 2025 08:54

remove unused test

b87430b

labrenbe linked an issue Apr 22, 2025 that may be closed by this pull request

Add a NiFi Authorizer that interfaces with OPA stackabletech/issues#47

Open

maltesander self-requested a review April 22, 2025 14:57

maltesander requested changes Apr 25, 2025

View reviewed changes

update rego with new opa response schema

3c9c7c1

maltesander reviewed May 8, 2025

View reviewed changes

rust/operator-binary/src/main.rs Outdated Show resolved Hide resolved

labrenbe added 11 commits May 8, 2025 16:10

update docs

7dd6e38

improve docs

47f1ab5

update docs

150dfdd

Merge remote-tracking branch 'origin/main' into feat/opa-authorizer

9b3e0d3

fix docs

031820b

refactor references_config_map function

13e60bc

fix docs

cfa6783

wip: add integration test

f9bcd44

add retries to nifi calls during test

46fc511

simplify rego rules

8f0a02f

move nifi flow copying into init container

ca61f92

maltesander reviewed May 16, 2025

View reviewed changes

remove oidc test and fix oidc-opa test with tls disabled

6e66627

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: OPA Authorizer #777

feat: OPA Authorizer #777

labrenbe commented Apr 15, 2025

maltesander left a comment

maltesander Apr 22, 2025

labrenbe May 9, 2025

maltesander May 16, 2025

maltesander Apr 22, 2025 •

edited

Loading

maltesander Apr 22, 2025

maltesander Apr 22, 2025

maltesander Apr 23, 2025

maltesander Apr 23, 2025

maltesander Apr 23, 2025

maltesander Apr 23, 2025

maltesander Apr 23, 2025

maltesander left a comment

maltesander May 8, 2025

maltesander May 8, 2025

maltesander May 16, 2025

maltesander May 16, 2025

maltesander May 16, 2025

maltesander May 16, 2025

	<1> The action taken against the resource. Possible values: `"read"` or `"write"`.
	<1> The action taken against the resource. Possible values: `read` or `write`.


		=== Defining rego rules

		For a general explanation of how rules are written, please refer to the {opa-rego-docs}[OPA documentation]. For more information on NiFi's access policies please refer to the {nifi-docs-access-policies}[NiFi documentation].


		For a general explanation of how rules are written, please refer to the {opa-rego-docs}[OPA documentation]. For more information on NiFi's access policies please refer to the {nifi-docs-access-policies}[NiFi documentation].

		Inside of your rego rules you have access to the content of the authorization request from NiFi as input for OPA:

	Inside of your rego rules you have access to the content of the authorization request from NiFi as input for OPA:
	The payload sent by NiFi with each request to OPA, that is accessible within the rego rules, has the following structure:

	This is optional and defaults to the name of the Druid Stacklet.
	This is optional and defaults to the name of the NiFi Stacklet.

	The OPA authorizer plugin expects relo rules to be named `allow` and to return a result following this schema:
	The OPA authorizer plugin expects rego rules to be named `allow` and to return a result following this schema:

	{nifi-docs-component-level-access-policies}[Component Level Access Policies] allow managing granular access to components like process-groups and processors. Components can {nifi-docs-access-policy-inheritance}[inherite access policies] defined for parent components, e.g. a process group is the parent component for a processor component.
	{nifi-docs-component-level-access-policies}[Component Level Access Policies] allow managing granular access to components like process-groups and processors. Components can {nifi-docs-access-policy-inheritance}[inherite access policies] defined for parent components, e.g. a process group is the parent component for a contained processor component.

	<1> Default rule returns should `"resourceNotFound": true`. If this is not set NiFi's access policy inheritance won't work. Any values for the `allowed` field in the response will be ignored.
	<1> The default rule should return `"resourceNotFound": true`. If this is not set, NiFi's access policy inheritance will not work. Any values for the `allowed` field in the response will be ignored.

feat: OPA Authorizer #777

Are you sure you want to change the base?

feat: OPA Authorizer #777

Conversation

labrenbe commented Apr 15, 2025

Description

Definition of Done Checklist

maltesander left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maltesander Apr 22, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maltesander left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maltesander Apr 22, 2025 •

edited

Loading