Skip to content

Commit 5eaa6ae

Browse files
author
GitHub Actions
committed
Update Orchestrator plugin permissions
1 parent c229e7c commit 5eaa6ae

File tree

3 files changed

+149
-1
lines changed

3 files changed

+149
-1
lines changed

assemblies/assembly-install-rhdh-orchestrator-operator.adoc

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,4 +15,8 @@ include::modules/orchestrator/proc-enable-orchestrator-plugin.adoc[leveloffset=+
1515

1616
include::modules/orchestrator/proc-upgrading-the-orchestrator-plugin.adoc[leveloffset=+1]
1717

18-
include::modules/orchestrator/proc-upgrading-the-openshift-serverless-logic-operator.adoc[leveloffset=+1]
18+
include::modules/orchestrator/proc-upgrading-the-openshift-serverless-logic-operator.adoc[leveloffset=+1]
19+
20+
include::modules/orchestrator/ref-orchestrator-plugin-permissions.adoc[leveloffset=+1]
21+
22+
include::modules/orchestrator/proc-managing-orchestrator-plugin-permissions-using-rbac-policies.adoc[leveloffset=+1]
Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
:_mod-docs-content-type: PROCEDURE
2+
3+
[id="proc-managing-orchestrator-plugin-permissions-using-rbac-policies_{context}"]
4+
= Managing Orchestrator plugin permissions using RBAC policies
5+
6+
You can configure Role-Based Access Control (RBAC) policies so that users can view workflow details without the permission to run those workflows. This configuration limits user interaction to explicitly authorized workflows.
7+
8+
.Prerequisites
9+
• You have identified the specific [`workflowId`] for each workflow you want to restrict.
10+
• You have enabled the RBAC plugin and configured the `policies-csv-file` path in your `{my-app-config-file}`.
11+
12+
.Procedure
13+
. Identify the `workflowId` from your workflow definition file as shown in the following example:
14+
+
15+
[source,yaml]
16+
----
17+
id: greeting
18+
version: '1.0'
19+
----
20+
. Create or update your RBAC policy CSV file to define permissions. Use the format `p, role, permission, action, allow`.
21+
+
22+
[NOTE]
23+
====
24+
You can grant access using generic permissions, (for example, `orchestrator.workflow`) or specific permissions targeting a `workflowId`, (for example, `orchestrator.workflow.greeting`). Generic permissions take precedence; you cannot grant generic access and then selectively deny a specific ID.
25+
====
26+
27+
. Add the following example policies to your CSV file to establish basic user and administrator roles:
28+
+
29+
[source,yaml]
30+
----
31+
# Minimal user role - can only view and run specific workflows
32+
p, role:default/workflowUser, orchestrator.workflow.greeting, read, allow
33+
p, role:default/workflowUser, orchestrator.workflow.use.greeting, update, allow
34+
# Support role - can view all workflows and instances, but not execute
35+
p, role:default/workflowSupport, orchestrator.workflow, read, allow
36+
p, role:default/workflowSupport, orchestrator.instanceAdminView, read, allow
37+
# Full admin role - complete access to all Orchestrator functions
38+
p, role:default/workflowAdmin, orchestrator.workflow, read, allow
39+
p, role:default/workflowAdmin, orchestrator.workflow.use, update, allow
40+
p, role:default/workflowAdmin, orchestrator.workflowAdminView, read, allow
41+
p, role:default/workflowAdmin, orchestrator.instanceAdminView, read, allow
42+
# Assign users to the roles
43+
g, user:default/example_user, role:default/workflowUser
44+
----
45+
. Enable permissions in your `{my-app-config-file}` file by adding the `orchestrator` plugin to the `rbac` section and set `policyFileReload` to true.
46+
+
47+
[source,subs="+attributes,+quotes"]
48+
----
49+
permission:
50+
enabled: true
51+
rbac:
52+
policies-csv-file: <absolute_path_to_the_policy_file>
53+
pluginsWithPermission:
54+
- orchestrator
55+
policyFileReload: true
56+
admin:
57+
users:
58+
- name: user:default/YOUR_USER
59+
----
60+
. Restart the application to apply the changes.
61+
62+
.Verification
63+
. Log in as a user assigned to the `workflowUser` role.
64+
. Navigate to the Orchestrator plugin and verify that you can see the workflow in the list.
65+
66+
[IMPORTANT]
67+
====
68+
You can view dynamic permissions containing a `workflowId` in the RBAC UI, but you cannot modify them in the interface. Use the policy CSV file or the RBAC API to manage these specific workflow permissions.
69+
====
70+
71+
[role="_additional-resources"]
72+
.Additional resources
73+
* For more information on `casbin` rules, see link:https://www.casbin.org/docs/rbac[RBAC documentation].
Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
:_mod-docs-content-type: REFERENCE
2+
3+
[id="ref-orchestrator-plugin-permissions_{context}"]
4+
= Orchestrator plugin permissions
5+
6+
The Orchestrator plugin uses the {product} permission mechanism and the Role-Based Access Control (RBAC) plugin to restrict access to backend endpoints.
7+
Orchestrator supports decoupling visibility (read) from running (update) using specific workflow IDs instead of generic permissions as shown in the following table:
8+
9+
[cols="15%,15%,15,55%", frame="all", options="header"]
10+
|===
11+
|Permission name|Resource Type|Policy|Description
12+
13+
|orchestrator.workflow
14+
|named resource
15+
|read
16+
|List and read _all_ workflow definitions
17+
18+
List and read their instances
19+
20+
|orchestrator.workflow.[`workflowId`]
21+
|named resource
22+
|read
23+
|List and read a _single_ workflow definition
24+
25+
List and read instances created for this particular workflow.
26+
27+
|orchestrator.workflow.use
28+
|named resource
29+
|update
30+
|Run or abort _any_ workflow
31+
32+
|orchestrator.workflow.use.[`workflowId`]
33+
|named resource
34+
|update
35+
|Run or abort a _specific_ workflow
36+
37+
|orchestrator.workflowAdminView
38+
|named resource
39+
|read
40+
|View instance variables and workflow definition editor
41+
42+
|orchestrator.instanceAdminView
43+
|named resource
44+
|read
45+
|View _all_ workflow instances, including those created by other users.
46+
|===
47+
48+
[WARNING]
49+
====
50+
Avoid generic permissions for specific control. The system grants access if either a generic permission or a specific one provides it. Granting generic permissions overrides specific denial policies within the same action type:
51+
- Granting orchestrator.workflow (read) prevents you from denying access to orchestrator.workflow.[workflowId] (read).
52+
- Granting orchestrator.workflow.use (update) prevents you from denying access to orchestrator.workflow.use.[workflowId] (update).
53+
====
54+
55+
The [`workflowId`] must match the unique identifier in your workflow definition file. For example,
56+
in the workflow definition below, the identifier is `greeting`:
57+
58+
[source,subs="+attributes,+quotes"]
59+
----
60+
id: greeting
61+
version: '1.0'
62+
specVersion: '0.8'
63+
name: Greeting workflow
64+
description: YAML based greeting workflow
65+
annotations:
66+
- 'workflow-type/infrastructure'
67+
dataInputSchema: 'schemas/greeting.sw.input-schema.json'
68+
extensions:
69+
- extensionid: workflow-output-schema
70+
outputSchema: schemas/workflow-output-schema.json
71+
----

0 commit comments

Comments
 (0)