Authorization in Red Hat Developer Hub
Configuring authorization by using role based access control (RBAC) in Red Hat Developer Hub
Abstract
Preface Copy linkLink copied to clipboard!
Administrators can authorize users to perform actions and define what users can do in Developer Hub.
Role-based access control (RBAC) is a security concept that defines how to control access to resources in a system by specifying a mapping between users of the system and the actions that those users can perform on resources in the system. You can use RBAC to define roles with specific permissions and then assign the roles to users and groups.
RBAC on Developer Hub is built on top of the Permissions framework, which defines RBAC policies in code. Rather than defining policies in code, you can use the Developer Hub RBAC feature to define policies in a declarative fashion by using a simple CSV based format. You can define the policies by using Developer Hub web interface or REST API instead of editing the CSV directly.
An administrator can define authorizations in Developer Hub by taking the following steps:
- Enable the RBAC feature and give authorized users access to the feature.
Define roles and policies by combining the following methods:
- The Developer Hub policy administrator uses the Developer Hub web interface or REST API.
- The Developer Hub administrator edits the main Developer Hub configuration file.
- The Developer Hub administrator edits external files.
Chapter 1. Enabling and giving access to the Role-Based Access Control (RBAC) feature Copy linkLink copied to clipboard!
The Role-Based Access Control (RBAC) feature is disabled by default. Enable the RBAC plugin and declare policy administrators to start using RBAC features.
The permission policies for users and groups in the Developer Hub are managed by permission policy administrators. Only permission policy administrators can access the Role-Based Access Control REST API.
Prerequisites
- You have added a custom Developer Hub application configuration, and have necessary permissions to modify it.
- You have enabled an authentication provider.
Procedure
The RBAC plugin is installed but disabled by default. To enable the
./dynamic-plugins/dist/backstage-community-plugin-rbacplugin, edit yourdynamic-plugins.yamlwith the following content.dynamic-plugins.yamlfragmentplugins: - package: ./dynamic-plugins/dist/backstage-community-plugin-rbac disabled: falseplugins: - package: ./dynamic-plugins/dist/backstage-community-plugin-rbac disabled: falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow See Installing and viewing plugins in Red Hat Developer Hub.
Declare policy administrators to enable a select number of authenticated users to configure RBAC policies through the REST API or Web UI, instead of modifying the CSV file directly. The permissions can be specified in a separate CSV file referenced in your
my-rhdh-app-configconfig map, or permissions can be created using the REST API or Web UI.To declare users such as <your_policy_administrator_name> as policy administrators, edit your custom Developer Hub ConfigMap, such as
app-config-rhdh, and add following code to theapp-config.yamlcontent:app-config.yamlfragmentCopy to Clipboard Copied! Toggle word wrap Toggle overflow In order for the Developer Hub Web UI to display available permissions provided by installed plugins, add the corresponding plugin IDs to your custom
app-config.yamlDeveloper Hub configuration file.To display available permissions in RBAC UI, edit your custom Developer Hub ConfigMap, such as
app-config-rhdh, and add following code to theapp-config.yamlcontent:app-config.yamlfragmentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
- Sign out from the existing Red Hat Developer Hub session and log in again using the declared policy administrator account.
With RBAC enabled, most features are disabled by default.
- Navigate to the Catalog page in RHDH. The Create button is not visible. You cannot create new components.
- Navigate to the API page. The Register button is not visible.
Next steps
- Explicitly enable permissions to resources in Developer Hub.
Chapter 2. Determining permission policy and role configuration source Copy linkLink copied to clipboard!
You can configure Red Hat Developer Hub policy and roles by using different sources. To maintain data consistency, Developer Hub associates each permission policy and role with one unique source. You can only use this source to change the resource.
The available sources are:
- Configuration file
Configure roles and policies in the Developer Hub
app-config.yamlconfiguration file, for instance to declare your policy administrators.The Configuration file pertains to the default
role:default/rbac_adminrole provided by the RBAC plugin. The default role has limited permissions to create, read, update, delete permission policies or roles, and to read catalog entities.NoteIn case the default permissions are insufficient for your administrative requirements, you can create a custom admin role with the required permission policies.
- REST API
- Configure roles and policies by using the Developer Hub Web UI or by using the REST API.
- CSV file
- Configure roles and policies by using external CSV files.
- Legacy
The legacy source applies to policies and roles defined before RBAC backend plugin version
2.1.3, and is the least restrictive among the source location options.ImportantReplace the permissions and roles using the legacy source with the permissions using the REST API or the CSV file sources.
Procedure
-
To determine the source of a role or policy, use a
GETrequest.
Chapter 3. Managing role-based access controls (RBAC) using the Red Hat Developer Hub Web UI Copy linkLink copied to clipboard!
Policy administrators can use the Developer Hub web interface (Web UI) to allocate specific roles and permissions to individual users or groups. Allocating roles ensures that access to resources and functionalities is regulated across the Developer Hub.
With the policy administrator role in Developer Hub, you can assign permissions to users and groups. This role allows you to view, create, modify, and delete the roles using Developer Hub Web UI.
3.1. Creating a role in the Red Hat Developer Hub Web UI Copy linkLink copied to clipboard!
You can create a role in the Red Hat Developer Hub using the Web UI.
Prerequisites
Procedure
Go to Administration at the bottom of the sidebar in the Developer Hub.
The RBAC tab appears, displaying all the created roles in the Developer Hub.
- (Optional) Click any role to view the role information on the OVERVIEW page.
- Click CREATE to create a role.
- Enter the name and description of the role in the given fields and click NEXT.
- Add users and groups using the search field, and click NEXT.
- Select Plugin and Permission from the drop-downs in the Add permission policies section.
- Select or clear the Policy that you want to set in the Add permission policies section, and click NEXT.
- Review the added information in the Review and create section.
- Click CREATE.
Verification
The created role appears in the list available in the RBAC tab.
3.2. Editing a role in the Red Hat Developer Hub Web UI Copy linkLink copied to clipboard!
You can edit a role in the Red Hat Developer Hub using the Web UI.
The policies generated from a policy.csv or ConfigMap file cannot be edited or deleted using the Developer Hub Web UI.
Prerequisites
- You have enabled RBAC, have a policy administrator role in Developer Hub, and have added plugins with permission.
- The role that you want to edit is created in the Developer Hub.
Procedure
Go to Administration at the bottom of the sidebar in the Developer Hub.
The RBAC tab appears, displaying all the created roles in the Developer Hub.
- (Optional) Click any role to view the role information on the OVERVIEW page.
- Select the edit icon for the role that you want to edit.
- Edit the details of the role, such as name, description, users and groups, and permission policies, and click NEXT.
- Review the edited details of the role and click SAVE.
After editing a role, you can view the edited details of a role on the OVERVIEW page of a role. You can also edit a role’s users and groups or permissions by using the edit icon on the respective cards on the OVERVIEW page.
3.3. Deleting a role in the Red Hat Developer Hub Web UI Copy linkLink copied to clipboard!
You can delete a role in the Red Hat Developer Hub using the Web UI.
The policies generated from a policy.csv or ConfigMap file cannot be edited or deleted using the Developer Hub Web UI.
Prerequisites
- You have enabled RBAC and have a policy administrator role in Developer Hub.
- The role that you want to delete is created in the Developer Hub.
Procedure
Go to Administration at the bottom of the sidebar in the Developer Hub.
The RBAC tab appears, displaying all the created roles in the Developer Hub.
- (Optional) Click any role to view the role information on the OVERVIEW page.
Select the delete icon from the Actions column for the role that you want to delete.
Delete this role? pop-up appears on the screen.
- Click DELETE.
Chapter 4. Managing authorizations by using the REST API Copy linkLink copied to clipboard!
To automate the maintenance of Red Hat Developer Hub permission policies and roles, you can use Developer Hub role-based access control (RBAC) REST API.
You can perform the following actions with the REST API:
Retrieve information about:
- All permission policies
- Specific permission policies
- Specific roles
- Static plugins permission policies
Create, update, or delete:
- Permission policy
- Role
4.1. Sending requests to the RBAC REST API by using the curl utility Copy linkLink copied to clipboard!
You can send RBAC REST API requests by using the curl utility.
Prerequisites
Procedure
Find your Bearer token to authenticate to the REST API.
- In your browser, open the web console Network tab.
- In the main screen, reload the Developer Hub Homepage.
-
In the web console Network tab, search for the
query?term=network call. - Save the token in the response JSON for the next steps.
In a terminal, run the curl command and review the response:
GETorDELETErequestcurl -v \ -H "Authorization: Bearer <token>" \ -X <method> "https://<my_developer_hub_url>/<endpoint>" \
curl -v \ -H "Authorization: Bearer <token>" \ -X <method> "https://<my_developer_hub_url>/<endpoint>" \Copy to Clipboard Copied! Toggle word wrap Toggle overflow POSTorPUTrequest requiring JSON body datacurl -v -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -X POST "https://<my_developer_hub_url>/<endpoint>" \ -d <body>
curl -v -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -X POST "https://<my_developer_hub_url>/<endpoint>" \ -d <body>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <token>
- Enter your saved authorization token.
- <method>
Enter the HTTP method for your API endpoint.
-
GET: To retrieve specified information from a specified resource endpoint. -
POST: To create or update a resource. -
PUT: To update a resource. -
DELETE: To delete a resource.
-
- https://<my_developer_hub_url>
- Enter your Developer Hub URL.
- <endpoint>
-
Enter the API endpoint to which you want to send a request, such as
/api/permission/policies. - <body>
-
Enter the JSON body with data that your API endpoint might need with the HTTP
POSTorPUTrequest.
Example request to create a role
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example request to update a role
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example request to create a permission policy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example request to update a permission policy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example request to create a condition
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example request to update a condition
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Review the returned HTTP status code:
200OK- The request was successful.
201Created- The request resulted in a new resource being successfully created.
204No Content- The request was successful, and the response payload has no more content.
400Bad Request- Input error with the request.
401Unauthorized- Lacks valid authentication for the requested resource.
403Forbidden- Refusal to authorize request.
404Not Found- Could not find requested resource.
409Conflict- Request conflict with the current state and the target resource.
4.2. Sending requests to the RBAC REST API by using a REST client Copy linkLink copied to clipboard!
You can send RBAC REST API requests using any REST client.
Prerequisites
Procedure
Find your Bearer token to authenticate to the REST API.
- In your browser, open the web console Network tab.
- In the main screen, reload the Developer Hub Homepage.
-
In the web console Network tab, search for the
query?term=network call. - Save the token in the response JSON for the next steps.
In your REST client, run a command with the following parameters and review the response:
- Authorization
- Enter your saved authorization token.
- HTTP method
Enter the HTTP method for your API endpoint.
-
GET: To retrieve specified information from a specified resource endpoint. -
POST: To create or update a resource. -
PUT: To update a resource. -
DELETE: To delete a resource.
-
- URL
-
Enter your Developer Hub URL and API endpoint: https://<my_developer_hub_url>/<endpoint>, such as
https://<my_developer_hub_url>/api/permission/policies. - Body
-
Enter the JSON body with data that your API endpoint might need with the HTTP
POSTrequest.
4.3. Supported RBAC REST API endpoints Copy linkLink copied to clipboard!
The RBAC REST API provides endpoints for managing roles, permissions, and conditional policies in the Developer Hub and for retrieving information about the roles and policies.
4.3.1. Roles Copy linkLink copied to clipboard!
The RBAC REST API supports the following endpoints for managing roles in the Red Hat Developer Hub.
- [GET] /api/permission/roles
Returns all roles in Developer Hub.
Example response (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [GET] /api/permission/roles/<kind>/<namespace>/<name>
Returns information for a single role in Developer Hub.
Example response (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [POST] /api/permission/roles/<kind>/<namespace>/<name>
Creates a role in Developer Hub.
Expand Table 4.1. Request parameters Name Description Type Presence bodyThe
memberReferences,group,namespace, andnamethe new role to be created.Request body
Required
Example request body (JSON)
{ "memberReferences": ["group:default/test"], "name": "role:default/test_admin" }{ "memberReferences": ["group:default/test"], "name": "role:default/test_admin" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example response
201 Created
201 CreatedCopy to Clipboard Copied! Toggle word wrap Toggle overflow - [PUT] /api/permission/roles/<kind>/<namespace>/<name>
Updates
memberReferences,kind,namespace, ornamefor a role in Developer Hub.Request parameters
The request body contains the
oldRoleandnewRoleobjects:Expand Name Description Type Presence bodyThe
memberReferences,group,namespace, andnamethe new role to be created.Request body
Required
Example request body (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example response
200 OK
200 OKCopy to Clipboard Copied! Toggle word wrap Toggle overflow - [DELETE] /api/permission/roles/<kind>/<namespace>/<name>?memberReferences=<VALUE>
Deletes the specified user or group from a role in Developer Hub.
Expand Table 4.2. Request parameters Name Description Type Presence kindKind of the entity
String
Required
namespaceNamespace of the entity
String
Required
nameName of the entity
String
Required
memberReferencesAssociated group information
String
Required
Example response
204
204Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [DELETE] /api/permission/roles/<kind>/<namespace>/<name>
Deletes a specified role from Developer Hub.
Expand Table 4.3. Request parameters Name Description Type Presence kindKind of the entity
String
Required
namespaceNamespace of the entity
String
Required
nameName of the entity
String
Required
Example response
204
204Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.2. Permission policies Copy linkLink copied to clipboard!
The RBAC REST API supports the following endpoints for managing permission policies in the Red Hat Developer Hub.
- [GET] /api/permission/policies
Returns permission policies list for all users.
Example response (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [GET] /api/permission/policies/<kind>/<namespace>/<name>
Returns permission policies related to the specified entity reference.
Expand Table 4.4. Request parameters Name Description Type Presence kindKind of the entity
String
Required
namespaceNamespace of the entity
String
Required
nameName related to the entity
String
Required
Example response (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [POST] /api/permission/policies
Creates a permission policy for a specified entity.
Expand Table 4.5. Request parameters Name Description Type Presence entityReferenceReference values of an entity including
kind,namespace, andnameString
Required
permissionPermission from a specific plugin, resource type, or name
String
Required
policyPolicy action for the permission, such as
create,read,update,delete, oruseString
Required
effectIndication of allowing or not allowing the policy
String
Required
Example request body (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example response
201 Created
201 CreatedCopy to Clipboard Copied! Toggle word wrap Toggle overflow - [PUT] /api/permission/policies/<kind>/<namespace>/<name>
Updates a permission policy for a specified entity.
Request parameters
The request body contains the
oldPolicyandnewPolicyobjects:Expand Name Description Type Presence permissionPermission from a specific plugin, resource type, or name
String
Required
policyPolicy action for the permission, such as
create,read,update,delete, oruseString
Required
effectIndication of allowing or not allowing the policy
String
Required
Example request body (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example response
200
200Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [DELETE] /api/permission/policies/<kind>/<namespace>/<name>?permission={value1}&policy={value2}&effect={value3}
Deletes a permission policy added to the specified entity.
Expand Table 4.6. Request parameters Name Description Type Presence kindKind of the entity
String
Required
namespaceNamespace of the entity
String
Required
nameName related to the entity
String
Required
permissionPermission from a specific plugin, resource type, or name
String
Required
policyPolicy action for the permission, such as
create,read,update,delete, oruseString
Required
effectIndication of allowing or not allowing the policy
String
Required
Example response
204 No Content
204 No ContentCopy to Clipboard Copied! Toggle word wrap Toggle overflow - [DELETE] /api/permission/policies/<kind>/<namespace>/<name>
Deletes all permission policies added to the specified entity.
Expand Table 4.7. Request parameters Name Description Type Presence kindKind of the entity
String
Required
namespaceNamespace of the entity
String
Required
nameName related to the entity
String
Required
Example response
204 No Content
204 No ContentCopy to Clipboard Copied! Toggle word wrap Toggle overflow - [GET] /api/permission/plugins/policies
Returns permission policies for all static plugins.
Example response (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.3. Conditional policies Copy linkLink copied to clipboard!
The RBAC REST API supports the following endpoints for managing conditional policies in the Red Hat Developer Hub.
- [GET] /api/permission/plugins/condition-rules
Returns available conditional rule parameter schemas for the available plugins that are enabled in Developer Hub.
Example response (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [GET] /api/permission/roles/conditions/:id
Returns conditions for the specified ID.
Example response (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [GET] /api/permission/roles/conditions
Returns list of all conditions for all roles.
Example response (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [POST] /api/permission/roles/conditions
Creates a conditional policy for the specified role.
Expand Table 4.8. Request parameters Name Description Type Presence resultAlways has the value
CONDITIONALString
Required
roleEntityRefString entity reference to the RBAC role, such as
role:default/devString
Required
pluginIdCorresponding plugin ID, such as
catalogString
Required
permissionMappingArray permission action, such as
['read', 'update', 'delete']String array
Required
resourceTypeResource type provided by the plugin, such as
catalog-entityString
Required
conditionsCondition JSON with parameters or array parameters joined by criteria
JSON
Required
nameName of the role
String
Required
metadata.descriptionThe description of the role
String
Optional
Example request body (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example response (JSON)
{ "id": 1 }{ "id": 1 }Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [PUT] /permission/roles/conditions/:id
Updates a condition policy for a specified ID.
Expand Table 4.9. Request parameters Name Description Type Presence resultAlways has the value
CONDITIONALString
Required
roleEntityRefString entity reference to the RBAC role, such as
role:default/devString
Required
pluginIdCorresponding plugin ID, such as
catalogString
Required
permissionMappingArray permission action, such as
['read', 'update', 'delete']String array
Required
resourceTypeResource type provided by the plugin, such as
catalog-entityString
Required
conditionsCondition JSON with parameters or array parameters joined by criteria
JSON
Required
nameName of the role
String
Required
metadata.descriptionThe description of the role
String
Optional
Example request body (JSON)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example response
200
200Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [DELETE] /api/permission/roles/conditions/:id
Deletes a conditional policy for the specified ID.
Example response
204
204Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.4. User statistics Copy linkLink copied to clipboard!
The licensed-users-info-backend plugin exposes various REST API endpoints to retrieve data related to logged-in users.
No additional configuration is required for the licensed-users-info-backend plugin. If the RBAC backend plugin is enabled, then an administrator role must be assigned to access the endpoints, as the endpoints are protected by the policy.entity.read permission.
The base URL for user statistics endpoints is http://SERVER:PORT/api/licensed-users-info, such as http://localhost:7007/api/licensed-users-info.
- [GET] /users/quantity
Returns the total number of logged-in users.
Example request
curl -X GET "http://localhost:7007/api/licensed-users-info/users/quantity" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $token"
curl -X GET "http://localhost:7007/api/licensed-users-info/users/quantity" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $token"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example response
{ "quantity": "2" }{ "quantity": "2" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [GET] /users
Returns a list of logged-in users with their details.
Example request
curl -X GET "http://localhost:7007/api/licensed-users-info/users" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $token"
curl -X GET "http://localhost:7007/api/licensed-users-info/users" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $token"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example response
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - [GET] /users
Returns a list of logged-in users in CSV format.
Example request
curl -X GET "http://localhost:7007/api/licensed-users-info/users" \ -H "Content-Type: text/csv" \ -H "Authorization: Bearer $token"
curl -X GET "http://localhost:7007/api/licensed-users-info/users" \ -H "Content-Type: text/csv" \ -H "Authorization: Bearer $token"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example response
userEntityRef,displayName,email,lastTimeLogin user:default/dev,John Leavy,dev@redhat.com,"Thu, 22 Aug 2024 16:27:41 GMT"
userEntityRef,displayName,email,lastTimeLogin user:default/dev,John Leavy,dev@redhat.com,"Thu, 22 Aug 2024 16:27:41 GMT"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 5. Managing authorizations by using external files Copy linkLink copied to clipboard!
To automate Red Hat Developer Hub maintenance, you can configure permissions and roles in external files, before starting Developer Hub.
5.1. Defining authorizations in external files by using the operator Copy linkLink copied to clipboard!
To automate Red Hat Developer Hub maintenance, you can define permissions and roles in external files, before starting Developer Hub. You need to prepare your files, upload them to your OpenShift Container Platform project, and configure Developer Hub to use the external files.
Prerequisites
Procedure
Define your policies in a
rbac-policies.csvCSV file by using the following format:Define role permissions:
p, <role_entity_reference>, <permission>, <action>, <allow_or_deny>
p, <role_entity_reference>, <permission>, <action>, <allow_or_deny>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <role_entity_reference>
-
Role entity reference, such as:
role:default/guest. - <permission>
Permission, such as:
bulk.import,catalog.entity.read, orcatalog.entity.refresh, or permission resource type, such as:bulk-importorcatalog-entity.- <action>
-
Action type, such as:
use,read,create,update,delete. - <allow_or_deny>
-
Access granted:
allowordeny.
Assign the role to a group or a user:
g, <group_or_user>, <role_entity_reference>
g, <group_or_user>, <role_entity_reference>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <group_or_user>
Group, such as:
user:default/mygroup, or user, such as:user:default/myuser.Sample
rbac-policies.csvp, role:default/guests, catalog-entity, read, allow p, role:default/guests, catalog.entity.create, create, allow g, user:default/my-user, role:default/guests g, group:default/my-group, role:default/guests
p, role:default/guests, catalog-entity, read, allow p, role:default/guests, catalog.entity.create, create, allow g, user:default/my-user, role:default/guests g, group:default/my-group, role:default/guestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Define your conditional policies in a
rbac-conditional-policies.yamlYAML file by using the following format:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Upload your
rbac-policies.csvandrbac-conditional-policies.yamlfiles to arbac-policiesconfig map in your OpenShift Container Platform project containing Developer Hub.oc create configmap rbac-policies \ --from-file=rbac-policies.csv \ --from-file=rbac-conditional-policies.yaml$ oc create configmap rbac-policies \ --from-file=rbac-policies.csv \ --from-file=rbac-conditional-policies.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Update your
Backstagecustom resource to mount in the Developer Hub filesystem your files from therbac-policiesconfig map:Backstagecustom resource fragmentCopy to Clipboard Copied! Toggle word wrap Toggle overflow Update your Developer Hub
app-config.yamlconfiguration file to use therbac-policies.csvandrbac-conditional-policies.yamlexternal files:app-config.yamlfile fragmentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. Defining authorizations in external files by using Helm Copy linkLink copied to clipboard!
To automate Red Hat Developer Hub maintenance, you can define permissions and roles in external files, before starting Developer Hub. You need to prepare your files, upload them to your OpenShift Container Platform project, and configure Developer Hub to use the external files.
Prerequisites
Procedure
Define your policies in a
rbac-policies.csvCSV file by using the following format:Define role permissions:
p, <role_entity_reference>, <permission>, <action>, <allow_or_deny>
p, <role_entity_reference>, <permission>, <action>, <allow_or_deny>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <role_entity_reference>
-
Role entity reference, such as:
role:default/guest. - <permission>
Permission, such as:
bulk.import,catalog.entity.read, orcatalog.entity.refresh, or permission resource type, such as:bulk-importorcatalog-entity.- <action>
-
Action type, such as:
use,read,create,update,delete. - <allow_or_deny>
-
Access granted:
allowordeny.
Assign the role to a group or a user:
g, <group_or_user>, <role_entity_reference>
g, <group_or_user>, <role_entity_reference>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - <group_or_user>
Group, such as:
user:default/mygroup, or user, such as:user:default/myuser.Sample
rbac-policies.csvp, role:default/guests, catalog-entity, read, allow p, role:default/guests, catalog.entity.create, create, allow g, user:default/my-user, role:default/guests g, group:default/my-group, role:default/guests
p, role:default/guests, catalog-entity, read, allow p, role:default/guests, catalog.entity.create, create, allow g, user:default/my-user, role:default/guests g, group:default/my-group, role:default/guestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Define your conditional policies in a
rbac-conditional-policies.yamlYAML file by using the following format:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Upload your
rbac-policies.csvandrbac-conditional-policies.yamlfiles to arbac-policiesconfig map in your OpenShift Container Platform project containing Developer Hub.oc create configmap rbac-policies \ --from-file=rbac-policies.csv \ --from-file=rbac-conditional-policies.yaml$ oc create configmap rbac-policies \ --from-file=rbac-policies.csv \ --from-file=rbac-conditional-policies.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Update your Developer Hub
BackstageHelm chart to mount in the Developer Hub filesystem your files from therbac-policiesconfig map:- In the Developer Hub Helm Chart, go to Root Schema → Backstage chart schema → Backstage parameters → Backstage container additional volume mounts.
Select Add Backstage container additional volume mounts and add the following values:
- mountPath
-
/opt/app-root/src/rbac - Name
-
rbac-policies
Add the RBAC policy to the Backstage container additional volumes in the Developer Hub Helm Chart:
- name
-
rbac-policies - configMap
- defaultMode
-
420 - name
-
rbac-policies
Update your Developer Hub
app-config.yamlconfiguration file to use therbac-policies.csvandrbac-conditional-policies.yamlexternal files:app-config.yamlfile fragmentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 6. Configuring guest access with RBAC UI Copy linkLink copied to clipboard!
Use guest access with the role-based access control (RBAC) front-end plugin to allow a user to test role and policy creation without the need to set up and configure an authentication provider.
Guest access is not recommended for production.
6.1. Configuring the RBAC backend plugin Copy linkLink copied to clipboard!
You can configure the RBAC backend plugin by updating the app-config.yaml file to enable the permission framework.
Prerequisites
-
You have installed the
@janus-idp/backstage-plugin-rbacplugin in Developer Hub. For more information, see {plugins-configure-book-title}.
Procedure
-
Update the
app-config.yamlfile to enable the permission framework as shown:
The pluginsWithPermission section of the app-config.yaml file includes only three plugins by default. Update the section as needed to include any additional plugins that also incorporate permissions.
6.2. Setting up the guest authentication provider Copy linkLink copied to clipboard!
You can enable guest authentication and use it alongside the RBAC frontend plugin.
Prerequisites
-
You have installed the
@janus-idp/backstage-plugin-rbacplugin in Developer Hub. For more information, see {plugins-configure-book-title}.
Procedure
-
In the
app-config.yamlfile, add the user entity reference to resolve and enable thedangerouslyAllowOutsideDevelopmentoption, as shown in the following example:
You can use user:default/guest as the user entity reference to match the added user under the permission.rbac.admin.users section of the app-config.yaml file.
Chapter 7. Delegating role-based access controls (RBAC) access in Red Hat Developer Hub Copy linkLink copied to clipboard!
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.
In Red Hat Developer Hub, you can delegate RBAC access using the multitenancy feature of the RBAC plugin, specifically the IS_OWNER conditional rule. You can either use the web UI or the RBAC backend API, depending on your preferred workflow and level of automation:
- Use the web UI to create roles, assign users or groups, define permissions, and apply ownership conditions through an intuitive interface.
- Use the API for a more flexible and automatable approach, where you can programmatically manage roles, permissions, and ownership conditions using authenticated curl requests.
By delegating RBAC access through either method, you can expect the following outcomes:
- Team leads can manage RBAC settings for their teams independently.
- Visibility of other users' or teams' permissions is restricted.
- Administrators retain overarching control while delegating team-specific access.
Prerequisites
- Your RHDH instance is running with the RBAC plugin installed and configured.
- You have administrative access to RHDH.
7.1. Delegating RBAC access in Red Hat Developer Hub by using the web UI Copy linkLink copied to clipboard!
You can delegate the RBAC access in Red Hat Developer Hub by using the web UI.
Procedure
- Log in to your RHDH instance with administrator credentials.
- Navigate to Administration → RBAC.
-
Click Create Role and define a new role for team leads, such as
role:default/team_lead. -
In the Members section, add the user or group, such as
user:default/team_lead. Grant permissions required by team leads, such as:
-
policy.entity.createto allow policy creation. -
catalog-entity:readto allow catalog access.
-
Apply conditions to limit access as follows:
-
Use the
IS_OWNERrule to ensure team leads can only manage resources they own.
-
Use the
- Click Save to create the role and apply changes.
Verification
- Log in as a team lead.
Verify the following:
- RBAC UI is accessible.
- Only users or roles related to their team are visible.
- No access to roles or permissions outside their scope is granted.
7.2. Delegating RBAC access in Red Hat Developer Hub by using API Copy linkLink copied to clipboard!
You can delegate the RBAC access in Red Hat Developer Hub by using the RBAC backend API.
Prerequisites
-
You have API access using
curlor another tool.
Procedure
Create a new role designated for team leads using the RBAC backend API:
Example of creating a new role for the team lead using the RBAC backend API
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Allow team leads to read catalog entities and create permissions in the RBAC plugin using the following API request:
Example of granting the team lead role permission to create RBAC policies and read catalog entities
Copy to Clipboard Copied! Toggle word wrap Toggle overflow To ensure team leads can only manage what they own, use the
IS_OWNERconditional rule as follows:Example
curlof applying a conditional access policy using theIS_OWNERrule for the team lead roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow The previous example of conditional policy limits visibility and control to only owned roles and policies.
Log in to RHDH as team lead and verify the following:
Use the following request and verify that you do not see any roles:
Example
curlto retrieve roles visible to the team leadcurl -X GET 'http://localhost:7007/api/permission/roles' \ --header "Authorization: Bearer $TEAM_LEAD_TOKEN"
curl -X GET 'http://localhost:7007/api/permission/roles' \ --header "Authorization: Bearer $TEAM_LEAD_TOKEN"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Use the following request to create a new role for their team:
Example
curlof team lead creating a new role for their team with ownership assignedCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteYou can set the ownership during creation, but you can also update the ownership at any time.
Use the following request to assign a permission policy to the new role:
Example
curlfor granting read access to catalog entities for the new roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow Use the following request to verify that only team-owned roles and policies are visible:
Example
curlto retrieve roles and permission policies visible to the team leadcurl -X GET 'http://localhost:7007/api/permission/roles' \ --header "Authorization: Bearer $TEAM_LEAD_TOKEN" curl -X GET 'http://localhost:7007/api/permission/policies' \ --header "Authorization: Bearer $TEAM_LEAD_TOKEN"
curl -X GET 'http://localhost:7007/api/permission/roles' \ --header "Authorization: Bearer $TEAM_LEAD_TOKEN" curl -X GET 'http://localhost:7007/api/permission/policies' \ --header "Authorization: Bearer $TEAM_LEAD_TOKEN"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Log in as a team lead and verify the following:
- The RBAC UI is accessible.
- Only the assigned users or group is visible.
- Permissions outside the scoped team are not viewable or editable.
- Log in as an administrator and verify that you retain full visibility and control.
Chapter 8. Permission policies reference Copy linkLink copied to clipboard!
Permission policies in Red Hat Developer Hub are a set of rules to govern access to resources or functionalities. These policies state the authorization level that is granted to users based on their roles. The permission policies are implemented to maintain security and confidentiality within a given environment.
You can define the following types of permissions in Developer Hub:
- resource type
- basic
The distinction between the two permission types depends on whether a permission includes a defined resource type.
You can define the resource type permission using either the associated resource type or the permission name as shown in the following example:
Example resource type permission definition
p, role:default/myrole, catalog.entity.read, read, allow g, user:default/myuser, role:default/myrole p, role:default/another-role, catalog-entity, read, allow g, user:default/another-user, role:default/another-role
p, role:default/myrole, catalog.entity.read, read, allow
g, user:default/myuser, role:default/myrole
p, role:default/another-role, catalog-entity, read, allow
g, user:default/another-user, role:default/another-role
You can define the basic permission in Developer Hub using the permission name as shown in the following example:
Example basic permission definition
p, role:default/myrole, catalog.entity.create, create, allow g, user:default/myuser, role:default/myrole
p, role:default/myrole, catalog.entity.create, create, allow
g, user:default/myuser, role:default/myrole
Developer Hub supports following permission policies:
- Catalog permissions
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
|
| Enables a user or role to read from the catalog |
|
|
| Enables a user or role to create catalog entities, including registering an existing component in the catalog | |
|
|
|
| Enables a user or role to refresh a single or multiple entities from the catalog |
|
|
|
| Enables a user or role to delete a single or multiple entities from the catalog |
|
|
| Enables a user or role to read a single or multiple locations from the catalog | |
|
|
| Enables a user or role to create locations within the catalog | |
|
|
| Enables a user or role to delete locations from the catalog |
- Bulk import permission
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
|
| Enables the user to access the bulk import endpoints, such as listing all repositories and organizations accessible by all GitHub integrations and managing the import requests |
- Scaffolder permissions
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
|
| Enables the execution of an action from a template |
|
|
|
| Enables a user or role to read a single or multiple one parameters from a template |
|
|
|
| Enables a user or role to read a single or multiple steps from a template |
|
|
| Enables a user or role to trigger software templates which create new scaffolder tasks | |
|
|
| Enables a user or role to cancel currently running scaffolder tasks | |
|
|
| Enables a user or role to read all scaffolder tasks and their associated events and logs | |
|
|
| Enables a user or role to access frontend template management features, including editing, previewing, and trying templates, forms, and custom fields. |
- RBAC permissions
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
|
| Enables a user or role to read permission policies and roles |
|
|
| Enables a user or role to create a single or multiple permission policies and roles | |
|
|
|
| Enables a user or role to update a single or multiple permission policies and roles |
|
|
|
| Enables a user or role to delete a single or multiple permission policies and roles |
- Kubernetes permissions
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
|
Enables a user to read Kubernetes cluster details under the | |
|
|
|
Enables a user to read information about Kubernetes resources located at | |
|
|
| Enables a user or role to access the proxy endpoint |
- OCM permissions
-
Basic OCM permissions only restrict access to the cluster view, but they do not prevent access to the Kubernetes clusters in the resource view. For more effective permissions, consider applying a conditional policy to restrict access to catalog entities that are of type
kubernetes-cluster. Access restriction is dependent on the set of permissions granted to a role. For example, if the role had full permissions (read,update, anddelete), then you must specify all its permissions in thepermissionMappingfield.
Example permissionMapping definition
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
| Enables a user or role to read from the OCM plugin | |
|
|
| Enables a user or role to read the cluster information in the OCM plugin |
- Topology permissions
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
|
Enables a user to read Kubernetes cluster details under the | |
|
|
|
Enables a user to read information about Kubernetes resources located at | |
|
|
| Enables a user or role to access the proxy endpoint, allowing the user or role to read pod logs and events within RHDH |
- Tekton permissions
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
|
Enables a user to read Kubernetes cluster details under the | |
|
|
|
Enables a user to read information about Kubernetes resources located at | |
|
|
| Enables a user or role to access the proxy endpoint, allowing the user or role to read pod logs and events within RHDH |
- ArgoCD permissions
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
| Enables a user to read from the ArgoCD plugin |
- Quay permissions
| Name | Resource type | Policy | Description |
|---|---|---|---|
|
|
| Enables a user to read from the Quay plugin |
Chapter 9. Conditional policies in Red Hat Developer Hub Copy linkLink copied to clipboard!
The permission framework in Red Hat Developer Hub provides conditions, supported by the RBAC backend plugin (backstage-plugin-rbac-backend). The conditions work as content filters for the Developer Hub resources that are provided by the RBAC backend plugin.
The RBAC backend API stores conditions assigned to roles in the database. When you request to access the frontend resources, the RBAC backend API searches for the corresponding conditions and delegates them to the appropriate plugin using its plugin ID. If you are assigned to multiple roles with different conditions, then the RBAC backend merges the conditions using the anyOf criteria.
- Conditional criteria
A condition in Developer Hub is a simple condition with a rule and parameters. However, a condition can also contain a parameter or an array of parameters combined by conditional criteria. The supported conditional criteria includes:
-
allOf: Ensures that all conditions within the array must be true for the combined condition to be satisfied. -
anyOf: Ensures that at least one of the conditions within the array must be true for the combined condition to be satisfied. -
not: Ensures that the condition within it must not be true for the combined condition to be satisfied.
-
- Conditional object
The plugin specifies the parameters supported for conditions. You can access the conditional object schema from the RBAC API endpoint to understand how to construct a conditional JSON object, which is then used by the RBAC backend plugin API.
A conditional object contains the following parameters:
Expand Table 9.1. Conditional object parameters Parameter Type Description resultString
Always has the value
CONDITIONALroleEntityRefString
String entity reference to the RBAC role, such as
role:default/devpluginIdString
Corresponding plugin ID, such as
catalogpermissionMappingString array
Array permission actions, such as
['read', 'update', 'delete']resourceTypeString
Resource type provided by the plugin, such as
catalog-entityconditionsJSON
Condition JSON with parameters or array parameters joined by criteria
- Conditional policy aliases
The RBAC backend plugin (
backstage-plugin-rbac-backend) supports the use of aliases in conditional policy rule parameters. The conditional policy aliases are dynamically replaced with the corresponding values during policy evaluation. Each alias in conditional policy is prefixed with a$sign indicating its special function.The supported conditional aliases include:
-
$currentUser: This alias is replaced with the user entity reference for the user who requests access to the resource. For example, if user Tom from the default namespace requests access,$currentUserbecomesuser:default/tom.
-
Example conditional policy object with $currentUser alias
-
$ownerRefs: This alias is replaced with ownership references, usually as an array that includes the user entity reference and the user’s parent group entity reference. For example, for user Tom from team-a,$ownerRefsbecomes['user:default/tom', 'group:default/team-a'].
Example conditional policy object with $ownerRefs alias
9.1. Conditional policies reference Copy linkLink copied to clipboard!
You can access API endpoints for conditional policies in Red Hat Developer Hub. For example, to retrieve the available conditional rules, which can help you define these policies, you can access the GET [api/plugins/condition-rules] endpoint.
The api/plugins/condition-rules returns the condition parameters schemas, for example:
The RBAC backend API constructs a condition JSON object based on the previous condition schema.
9.1.1. Examples of conditional policies Copy linkLink copied to clipboard!
In Red Hat Developer Hub, you can define conditional policies with or without criteria. You can use the following examples to define the conditions based on your use case:
- A condition without criteria
Consider a condition without criteria displaying catalogs only if user is a member of the owner group. To add this condition, you can use the catalog plugin schema
IS_ENTITY_OWNERas follows:Example condition without criteria
Copy to Clipboard Copied! Toggle word wrap Toggle overflow In the previous example, the only conditional parameter used is
claims, which contains a list of user or group entity references.You can apply the previous example condition to the RBAC REST API by adding additional parameters as follows:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - A condition with criteria
Consider a condition with criteria, which displays catalogs only if user is a member of owner group OR displays list of all catalog user groups.
To add the criteria, you can add another rule as
IS_ENTITY_KINDin the condition as follows:Example condition with criteria
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteRunning conditions in parallel during creation is not supported. Therefore, consider defining nested conditional policies based on the available criteria.
Example of nested conditions
Copy to Clipboard Copied! Toggle word wrap Toggle overflow You can apply the previous example condition to the RBAC REST API by adding additional parameters as follows:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
The following examples can be used with Developer Hub plugins. These examples can help you determine how to define conditional policies:
Conditional policy defined for Keycloak plugin
The previous example of Keycloak plugin prevents users in the role:default/developer from updating or deleting users that are ingested into the catalog from the Keycloak plugin.
In the previous example, the annotation keycloak.org/realm requires the value of <YOUR_REALM>.
Conditional policy defined for Quay plugin
The previous example of Quay plugin prevents the role role:default/developer from using the Quay scaffolder action. Note that permissionMapping contains use, signifying that scaffolder-action resource type permission does not have a permission policy.
For more information about permissions in Red Hat Developer Hub, see Chapter 8, Permission policies reference.
Chapter 10. User statistics in Red Hat Developer Hub Copy linkLink copied to clipboard!
In Red Hat Developer Hub, the licensed-users-info-backend plugin provides statistical information about the logged-in users using the Web UI or REST API endpoints.
The licensed-users-info-backend plugin enables administrators to monitor the number of active users on Developer Hub. Using this feature, organizations can compare their actual usage with the number of licenses they have purchased. Additionally, you can share the user metrics with Red Hat for transparency and accurate licensing.
The licensed-users-info-backend plugin is enabled by default. This plugin enables a Download User List link at the bottom of the Administration → RBAC tab.
10.1. Downloading active users list in Red Hat Developer Hub Copy linkLink copied to clipboard!
You can download the list of users in CSV format using the Developer Hub web interface.
Prerequisites
-
RBAC plugins (
@backstage-community/plugin-rbacand@backstage-community/plugin-rbac-backend) must be enabled in Red Hat Developer Hub. - An administrator role must be assigned.
Procedure
- In Red Hat Developer Hub, navigate to Administration and select the RBAC tab.
- At the bottom of the RBAC page, click Download User List.
- Optional: Modify the file name in the Save as field and click Save.
- To access the downloaded users list, go to the Downloads folder on your local machine and open the CSV file.