Skip to content

Commit 5ac5dce

Browse files
[release-1.6] RHIDP-6570: Document the permission support to RBAC plugin (#1115)
Co-authored-by: Heena Manwani <[email protected]>
1 parent 720080e commit 5ac5dce

File tree

3 files changed

+181
-1
lines changed

3 files changed

+181
-1
lines changed

assemblies/assembly-configuring-authorization-in-rhdh.adoc

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -43,6 +43,7 @@ include::assembly-managing-authorizations-by-using-external-files.adoc[leveloffs
4343

4444
include::assembly-configuring-guest-access-with-rbac-ui.adoc[leveloffset=+1]
4545

46+
include::modules/authorization/proc-delegating-rbac-access.adoc[leveloffset=+1]
4647

4748
include::modules/authorization/ref-rbac-permission-policies.adoc[leveloffset=+1]
4849

Lines changed: 179 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,179 @@
1+
[id='proc-delegating-rbac-access_{context}']
2+
= Delegating role-based access controls (RBAC) access in {product}
3+
4+
An enterprise customer requires the ability to delegate role-based access control (RBAC) responsibilities to other individuals in the organization. In this scenario, you, as the administrator, can provide access to the RBAC plugin specifically to designated users, such as team leads. Each team lead is then able to manage permissions exclusively for users within their respective team or department, without visibility into or control over permissions outside their assigned scope. This approach allows team leads to manage access and permissions for their own teams independently, while administrators maintain global oversight.
5+
6+
In {product-very-short}, you can delegate RBAC access using the multitenancy feature of RBAC plugin, specifically the `IS_OWNER` conditional rule.
7+
8+
By delegating the RBAC access, you can expect the following outcomes:
9+
10+
* Team leads can manage RBAC settings for their teams independently.
11+
* Visibility of other users' or teams' permissions is restricted.
12+
* Administrators retain overarching control while delegating team-specific access.
13+
14+
.Prerequisites
15+
* Your {product-very-short} instance is up and running with RBAC plugin installed and configured.
16+
* You have administrative access to {product-very-short}.
17+
* You have API access using `curl` or another tool.
18+
19+
.Procedure
20+
. In your {product-very-short} instance, navigate to the *Administration -> RBAC* page.
21+
. Create a new role designated for team leads using the Web UI or API:
22+
+
23+
--
24+
.Example of creating a new role for the team lead using the RBAC backend API
25+
[source,bash]
26+
----
27+
curl -X POST 'http://localhost:7007/api/permission/roles' \
28+
--header "Authorization: Bearer $ADMIN_TOKEN" \
29+
--header "Content-Type: application/json" \
30+
--data '{
31+
"memberReferences": ["user:default/team_lead"],
32+
"name": "role:default/team_lead",
33+
"metadata": {
34+
"description": "This is an example team lead role"
35+
}
36+
}'
37+
----
38+
39+
For more information about creating a role using the Web UI, see xref:proc-rbac-ui-create-role_title-authorization[Creating a role in the {product} Web UI].
40+
--
41+
42+
. Allow team leads to read catalog entities and create permissions in the RBAC plugin using the Web UI or the following API request:
43+
+
44+
--
45+
.Example of granting the team lead role permission to create RBAC policies and read catalog entities
46+
[source,bash]
47+
----
48+
curl -X POST 'http://localhost:7007/api/permission/policies' \
49+
--header "Authorization: Bearer $ADMIN_TOKEN" \
50+
--header "Content-Type: application/json" \
51+
--data '[
52+
{
53+
"entityReference": "role:default/team_lead",
54+
"permission": "policy.entity.create",
55+
"policy": "create",
56+
"effect": "allow"
57+
},
58+
{
59+
"entityReference": "role:default/team_lead",
60+
"permission": "catalog-entity",
61+
"policy": "read",
62+
"effect": "allow"
63+
}
64+
]'
65+
----
66+
--
67+
68+
. To ensure team leads can only manage what they own, use the `IS_OWNER` conditional rule as follows:
69+
+
70+
--
71+
.Example `curl` of applying a conditional access policy using the `IS_OWNER` rule for the team lead role
72+
[source,bash]
73+
----
74+
curl -X POST 'http://localhost:7007/api/permission/roles/conditions' \
75+
--header "Authorization: Bearer $ADMIN_TOKEN" \
76+
--header "Content-Type: application/json" \
77+
--data '{
78+
"result": "CONDITIONAL",
79+
"pluginId": "permission",
80+
"resourceType": "policy-entity",
81+
"conditions": {
82+
"rule": "IS_OWNER",
83+
"resourceType": "policy-entity",
84+
"params": {
85+
"owners": [
86+
"user:default/team_lead"
87+
]
88+
}
89+
},
90+
"roleEntityRef": "role:default/team_lead",
91+
"permissionMapping": [
92+
"read",
93+
"update",
94+
"delete"
95+
]
96+
}'
97+
----
98+
The previous example of conditional policy limits visibility and control to only owned roles and policies.
99+
--
100+
101+
. Log in to {product-very-short} as team lead and verify the following:
102+
+
103+
--
104+
.. Use the following request and verify that you do not see any roles:
105+
+
106+
.Example `curl` to retrieve roles visible to the team lead
107+
[source,bash]
108+
----
109+
curl -X GET 'http://localhost:7007/api/permission/roles' \
110+
--header "Authorization: Bearer $TEAM_LEAD_TOKEN"
111+
112+
----
113+
114+
.. Use the following request to create a new role for their team:
115+
+
116+
.Example `curl` of team lead creating a new role for their team with ownership assigned
117+
[source,bash]
118+
----
119+
curl -X POST 'http://localhost:7007/api/permission/roles' \
120+
--header "Authorization: Bearer $TEAM_LEAD_TOKEN" \
121+
--header "Content-Type: application/json" \
122+
--data '{
123+
"memberReferences": ["user:default/team_member"],
124+
"name": "role:default/team_a",
125+
"metadata": {
126+
"description": "This is an example team_a role",
127+
"owner": "user:default/team_lead"
128+
}
129+
}'
130+
----
131+
+
132+
[NOTE]
133+
====
134+
You can set the ownership during creation, but you can also update the ownership at any time.
135+
====
136+
137+
.. Use the following request to assign a permission policy to the new role:
138+
+
139+
.Example `curl` for granting read access to catalog entities for the new role
140+
[source,bash]
141+
----
142+
curl -X POST 'http://localhost:7007/api/permission/policies' \
143+
--header "Authorization: Bearer $ADMIN_TOKEN" \
144+
--header "Content-Type: application/json" \
145+
--data '[
146+
{
147+
"entityReference": "role:default/team_a",
148+
"permission": "catalog-entity",
149+
"policy": "read",
150+
"effect": "allow"
151+
}
152+
]'
153+
----
154+
155+
.. Use the following request to verify that only team-owned roles and policies are visible:
156+
+
157+
.Example `curl` to retrieve roles and permission policies visible to the team lead
158+
[source,bash]
159+
----
160+
curl -X GET 'http://localhost:7007/api/permission/roles' \
161+
--header "Authorization: Bearer $TEAM_LEAD_TOKEN"
162+
163+
curl -X GET 'http://localhost:7007/api/permission/policies' \
164+
--header "Authorization: Bearer $TEAM_LEAD_TOKEN"
165+
----
166+
--
167+
168+
.Verification
169+
* Log in as a team lead and verify the following:
170+
+
171+
--
172+
** The RBAC UI is accessible.
173+
** Only the assigned users or group is visible.
174+
** Permissions outside the scoped team are not viewable or editable.
175+
--
176+
* Log in as an administrator and verify that you retain full visibility and control.
177+
178+
179+

modules/authorization/ref-rbac-permission-policies.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -158,7 +158,7 @@ RBAC permissions::
158158
|Allows a user or role to read permission policies and roles
159159

160160
|`policy.entity.create`
161-
|`policy-entity`
161+
|
162162
|`create`
163163
|Allows a user or role to create a single or multiple permission policies and roles
164164

0 commit comments

Comments
 (0)