Authorization

Chapter 1. Role-Based Access Control (RBAC) in Red Hat Developer Hub

Role-Based Access Control is a security paradigm that restricts access to authorized users. This feature includes defining roles with specific permissions and then assigning those roles to the users.

The Red Hat Developer Hub uses RBAC to improve the permission system within the platform. The RBAC feature in Developer Hub introduces an administrator role and leverages the organizational structure including teams, groups, and users by facilitating efficient access control.

Chapter 2. Permission policies in Red Hat Developer Hub

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 depend 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

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

The following permission policies are supported in the Developer Hub:

Catalog permissions

Name	Resource type	Policy	Description
`catalog.entity.read`	`catalog-entity`	read	Allows user or role to read from the catalog
`catalog.entity.create`		create	Allows user or role to create catalog entities, including registering an existing component in the catalog
`catalog.entity.refresh`	`catalog-entity`	update	Allows user or role to refresh a single or multiple entities from the catalog
`catalog.entity.delete`	`catalog-entity`	delete	Allows user or role to delete a single or multiple entities from the catalog
`catalog.location.read`		read	Allows user or role to read a single or multiple locations from the catalog
`catalog.location.create`		create	Allows user or role to create locations within the catalog
`catalog.location.delete`		delete	Allows user or role to delete locations from the catalog

Scaffolder permissions

Name	Resource type	Policy	Description
`scaffolder.action.execute`	`scaffolder-action`		Allows the execution of an action from a template
`scaffolder.template.parameter.read`	`scaffolder-template`	read	Allows user or role to read a single or multiple one parameters from a template
`scaffolder.template.step.read`	`scaffolder-template`	read	Allows user or role to read a single or multiple steps from a template
`scaffolder.task.create`		create	Allows the user or role to trigger software templates which create new scaffolder tasks
`scaffolder.task.cancel`			Allows the user or role to cancel currently running scaffolder tasks
`scaffolder.task.read`		read	Allows user or role to read all scaffolder tasks and their associated events and logs

RBAC permissions

Name	Resource type	Policy	Description
`policy.entity.read`	`policy-entity`	read	Allows user or role to read permission policies and roles
`policy.entity.create`	`policy-entity`	create	Allows user or role to create a single or multiple permission policies and roles
`policy.entity.update`	`policy-entity`	update	Allows user or role to update a single or multiple permission policies and roles
`policy.entity.delete`	`policy-entity`	delete	Allows user or role to delete a single or multiple permission policies and roles

Kubernetes permissions

Name	Resource type	Policy	Description
`kubernetes.proxy`			Allows user or role to access the proxy endpoint

OCM permissions

Name	Resource type	Policy	Description
`ocm.entity.read`		read	Allows user or role to read from the OCM plugin
`ocm.cluster.read`		read	Allows user or role to read the cluster information in the OCM plugin

Topology permissions

Name	Resource type	Policy	Description
`topology.view.read`		read	Allows user or role to view the topology plugin
`kubernetes.proxy`			Allows user or role to access the proxy endpoint, allowing them to read pod logs and events within RHDH

2.1. Permission policies configuration

There are two approaches to configure the permission policies in Red Hat Developer Hub, including:

Configuration of permission policies administrators
Configuration of permission policies defined in an external file

2.1.1. Configuration of permission policies administrators

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.

The purpose of configuring policy administrators is to enable a specific, restricted number of authenticated users to access the RBAC REST API. The permission policies are defined in a policy.csv file, which is referenced in the app-config-rhdh ConfigMap. OpenShift platform administrators or cluster administrators can perform this task with access to the namespace where Red Hat Developer Hub is deployed.

You can enable a permission policy administrator by configuring the app-config.yaml file as follows:

permission:
  enabled: true
  rbac:
    admin:
      users:
        - name: user:default/joeuser

The permission policy role (role:default/rbac_admin) is a default role in Developer Hub and includes some permissions upon creation, such as creating, reading, updating, and deleting permission policies/roles, as well as reading from the catalog.

If the default permissions are not adequate for your requirements, you can define a new administrator role tailored to your requirements using relevant permission policies. Alternatively, you can use the optional superUsers configuration value, which grants unrestricted permissions across Developer Hub.

You can set the superUsers in the app-config.yaml file as follows:

# ...
permission:
  enabled: true
  rbac:
    admin:
      superUsers:
        - name: user:default/joeuser
        # ...

2.1.2. Configuration of permission policies defined in an external file

You can configure the permission policies before starting the Red Hat Developer Hub. If permission policies are defined in an external file, then you can import the same file in the Developer Hub. You must define the permission policies using the following Casbin rules format:

---
`p, <ROLE>, <PERMISSION_NAME or PERMISSION_RESOURCE_TYPE>, <PERMISSION_POLICY_ACTION>, <ALLOW or DENY>`
---

You can define roles using the following Casbin rules format:

---
`g, <USER or GROUP>, <ROLE>`
---

Note

For information about the Casbin rules format, see Basics of Casbin rules.

The following is an example of permission policies configuration:

---
`p, role:default/guests, catalog-entity, read, allow`

p, role:default/guests, catalog.entity.create, create, allow

g, user:default/<USER_TO_ROLE>, role:default/guests

g, group:default/<GROUP_TO_ROLE>, role:default/guests ---

If a defined permission does not contain an action associated with it, then add use as a policy. See the following example:

---
`p, role:default/guests, kubernetes.proxy, use, allow`
---

You can define the policy.csv file path in the app-config.yaml file:

permission:
  enabled: true
  rbac:
    policies-csv-file: /some/path/rbac-policy.csv

You can use an optional configuration value that enables reloading the CSV file without restarting the Developer Hub instance.

Set the value of the policyFileReload option in the app-config.yaml file:

# ...
permission:
  enabled: true
  rbac:
    policies-csv-file: /some/path/rbac-policy.csv
    policyFileReload: true
    # ...

2.1.2.1. Mounting `policy.csv` file to the Developer Hub Helm chart

When the Red Hat Developer Hub is deployed with the Helm chart, you must define the policy.csv file by mounting it to the Developer Hub Helm chart.

You can add your policy.csv file to the Developer Hub Helm Chart by creating a configMap and mounting it.

Prerequisites

You are logged in to your OpenShift Container Platform account using the OpenShift Container Platform web console.
Red Hat Developer Hub is installed and deployed using Helm Chart.

Procedure

In OpenShift Container Platform, create a ConfigMap to hold the policies as shown in the following example:

Example ConfigMap

kind: ConfigMap
apiVersion: v1
metadata:
  name: rbac-policy
  namespace: rhdh
data:
  rbac-policy.csv: |
    p, role:default/guests, catalog-entity, read, allow
    p, role:default/guests, catalog.entity.create, create, allow

    g, user:default/<YOUR_USER>, role:default/guests

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-policy
Add the RBAC policy to the Backstage container additional volumes in the Developer Hub Helm Chart:
- name: rbac-policy
- configMap
  - defaultMode: 420
  - name: rbac-policy
Update the policy path in the app-config.yaml file as follows:
Example app-config.yaml file
```
permission:
  enabled: true
  rbac:
    policies-csv-file: ./rbac/rbac-policy.csv
```

Chapter 3. Conditional policies in Red Hat Developer Hub

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:

Table 3.1. Conditional object parameters
Parameter	Type	Description
`result`	String	Always has the value `CONDITIONAL`
`roleEntityRef`	String	String entity reference to the RBAC role, such as `role:default/dev`
`pluginId`	String	Corresponding plugin ID, such as `catalog`
`permissionMapping`	String array	Array permission actions, such as `['read', 'update', 'delete']`
`resourceType`	String	Resource type provided by the plugin, such as `catalog-entity`
`conditions`	JSON	Condition JSON with parameters or array parameters joined by criteria

3.1. Conditional policies definition

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:

[
   {
      "pluginId": "catalog",
      "rules": [
         {
            "name": "HAS_ANNOTATION",
            "description": "Allow entities with the specified annotation",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "annotation": {
                     "type": "string",
                     "description": "Name of the annotation to match on"
                  },
                  "value": {
                     "type": "string",
                     "description": "Value of the annotation to match on"
                  }
               },
               "required": [
                  "annotation"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "HAS_LABEL",
            "description": "Allow entities with the specified label",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "label": {
                     "type": "string",
                     "description": "Name of the label to match on"
                  }
               },
               "required": [
                  "label"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "HAS_METADATA",
            "description": "Allow entities with the specified metadata subfield",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "key": {
                     "type": "string",
                     "description": "Property within the entities metadata to match on"
                  },
                  "value": {
                     "type": "string",
                     "description": "Value of the given property to match on"
                  }
               },
               "required": [
                  "key"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "HAS_SPEC",
            "description": "Allow entities with the specified spec subfield",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "key": {
                     "type": "string",
                     "description": "Property within the entities spec to match on"
                  },
                  "value": {
                     "type": "string",
                     "description": "Value of the given property to match on"
                  }
               },
               "required": [
                  "key"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "IS_ENTITY_KIND",
            "description": "Allow entities matching a specified kind",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "kinds": {
                     "type": "array",
                     "items": {
                        "type": "string"
                     },
                     "description": "List of kinds to match at least one of"
                  }
               },
               "required": [
                  "kinds"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "IS_ENTITY_OWNER",
            "description": "Allow entities owned by a specified claim",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "claims": {
                     "type": "array",
                     "items": {
                        "type": "string"
                     },
                     "description": "List of claims to match at least one on within ownedBy"
                  }
               },
               "required": [
                  "claims"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         }
      ]
   }
   ... <another plugin condition parameter schemas>
]

The RBAC backend API constructs a condition JSON object based on the previous condition schema.

3.1.1. Examples of conditional policies

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_OWNER as follows:

Example condition without criteria

{
  "rule": "IS_ENTITY_OWNER",
  "resourceType": "catalog-entity",
  "params": {
    "claims": ["group:default/team-a"]
  }
}

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:

{
  "result": "CONDITIONAL",
  "roleEntityRef": "role:default/test",
  "pluginId": "catalog",
  "resourceType": "catalog-entity",
  "permissionMapping": ["read"],
  "conditions": {
    "rule": "IS_ENTITY_OWNER",
    "resourceType": "catalog-entity",
    "params": {
      "claims": ["group:default/team-a"]
    }
  }
}

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_KIND in the condition as follows:

Example condition with criteria

{
  "anyOf": [
    {
      "rule": "IS_ENTITY_OWNER",
      "resourceType": "catalog-entity",
      "params": {
        "claims": ["group:default/team-a"]
      }
    },
    {
      "rule": "IS_ENTITY_KIND",
      "resourceType": "catalog-entity",
      "params": {
        "kinds": ["Group"]
      }
    }
  ]
}

Note

Running conditions in parallel during creation is not supported. Therefore, consider defining nested conditional policies based on the available criteria.

Example of nested conditions

{
  "anyOf": [
    {
      "rule": "IS_ENTITY_OWNER",
      "resourceType": "catalog-entity",
      "params": {
        "claims": ["group:default/team-a"]
      }
    },
    {
      "rule": "IS_ENTITY_KIND",
      "resourceType": "catalog-entity",
      "params": {
        "kinds": ["Group"]
      }
    }
  ],
  "not": {
    "rule": "IS_ENTITY_KIND",
    "resourceType": "catalog-entity",
    "params": { "kinds": ["Api"] }
  }
}

You can apply the previous example condition to the RBAC REST API by adding additional parameters as follows:

{
  "result": "CONDITIONAL",
  "roleEntityRef": "role:default/test",
  "pluginId": "catalog",
  "resourceType": "catalog-entity",
  "permissionMapping": ["read"],
  "conditions": {
    "anyOf": [
      {
        "rule": "IS_ENTITY_OWNER",
        "resourceType": "catalog-entity",
        "params": {
          "claims": ["group:default/team-a"]
        }
      },
      {
        "rule": "IS_ENTITY_KIND",
        "resourceType": "catalog-entity",
        "params": {
          "kinds": ["Group"]
        }
      }
    ]
  }
}

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

{
  "result": "CONDITIONAL",
  "roleEntityRef": "role:default/developer",
  "pluginId": "catalog",
  "resourceType": "catalog-entity",
  "permissionMapping": ["update", "delete"],
  "conditions": {
    "not": {
      "rule": "HAS_ANNOTATION",
      "resourceType": "catalog-entity",
      "params": { "annotation": "keycloak.org/realm", "value": "<YOUR_REALM>" }
    }
  }
}

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.

Note

In the previous example, the annotation keycloak.org/realm requires the value of <YOUR_REALM>.

Conditional policy defined for Quay plugin

{
  "result": "CONDITIONAL",
  "roleEntityRef": "role:default/developer",
  "pluginId": "scaffolder",
  "resourceType": "scaffolder-action",
  "permissionMapping": ["use"],
  "conditions": {
    "not": {
      "rule": "HAS_ACTION_ID",
      "resourceType": "scaffolder-action",
      "params": { "actionId": "quay:create-repository" }
    }
  }
}

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 2, Permission policies in Red Hat Developer Hub.

Chapter 4. Managing role-based access controls (RBAC) using the Red Hat Developer Hub Web UI

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 administrator role in Developer Hub, you can assign permissions to users and groups, which allow users or groups to view, create, modify, and delete the roles using the Developer Hub Web UI.

To access the RBAC features in the Web UI, you must install and configure the @janus-idp/backstage-plugin-rbac plugin as a dynamic plugin. For more information about installing a dynamic plugin, see Configuring plugins in Red Hat Developer Hub.

After you install the @janus-idp/backstage-plugin-rbac plugin, the Administration option appears at the bottom of the sidebar. When you can click Administration, the RBAC tab appears by default, displaying all of the existing roles created in the Developer Hub. In the RBAC tab, you can also view the total number of users, groups, and the total number of permission policies associated with a role. You can also edit or delete a role using the Actions column.

4.1. Creating a role in the Red Hat Developer Hub Web UI

You can create a role in the Red Hat Developer Hub using the Web UI.

Prerequisites

You have an administrator role in the Developer Hub.
You have installed the @janus-idp/backstage-plugin-rbac plugin in Developer Hub. For more information, see Configuring plugins in Red Hat Developer Hub.
You have configured the required permission policies. For more information, see Section 2.1, “Permission policies configuration”.

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.

4.2. Editing a role in the Red Hat Developer Hub Web UI

You can edit a role in the Red Hat Developer Hub using the Web UI.

Note

The policies generated from a policy.csv or ConfigMap file cannot be edited or deleted using the Developer Hub Web UI.

Prerequisites

You have an administrator role in the Developer Hub.
You have installed the @janus-idp/backstage-plugin-rbac plugin in Developer Hub. For more information, see Configuring plugins in Red Hat Developer Hub.
You have configured the required permission policies. For more information, see Section 2.1, “Permission policies configuration”.
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.

4.3. Deleting a role in the Red Hat Developer Hub Web UI

You can delete a role in the Red Hat Developer Hub using the Web UI.

Note

The policies generated from a policy.csv or ConfigMap file cannot be edited or deleted using the Developer Hub Web UI.

Prerequisites

You have an administrator role in the Developer Hub.
You have installed the @janus-idp/backstage-plugin-rbac plugin in Developer Hub. For more information, see Configuring plugins in Red Hat Developer Hub.
You have configured the required permission policies. For more information, see Section 2.1, “Permission policies configuration”.
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 5. Role-based Access Control (RBAC) REST API

Red Hat Developer Hub provides RBAC REST API that you can use to manage the permissions and roles in the Developer Hub. This API supports you to facilitate and automate the maintenance of Developer Hub permission policies and roles.

Using the RBAC REST API, you can perform the following actions:

Retrieve information about all permission policies or specific permission policies, or roles
Create, update, or delete a permission policy or a role
Retrieve permission policy information about static plugins

The RBAC REST API requires the following components:

Authorization

The RBAC REST API requires Bearer token authorization for the permitted user role. For development purposes, you can access a web console in a browser. When you refresh a token request in the list of network requests, you find the token in the response JSON.

Authorization: Bearer $token

For example, on the Developer Hub Homepage, navigate to the Network tab and search for the query?term= network call. Alternatively, you can go to the Catalog page and select any Catalog API network call to acquire the Bearer token.

HTTP methods

The RBAC REST API supports the following HTTP methods for API requests:

GET: Retrieves specified information from a specified resource endpoint
POST: Creates or updates a resource
PUT: Updates a resource
DELETE: Deletes a resource

Base URL

The base URL for RBAC REST API requests is http://SERVER:PORT/api/permission/policies, such as http://localhost:7007/api/permission/policies.

Endpoints

RBAC REST API endpoints, such as /api/permission/policies/[kind]/[namespace]/[name] for specified kind, namespace, and name, are the URI that you append to the base URL to access the corresponding resource.

Example request URL for /api/permission/policies/[kind]/[namespace]/[name] endpoint is:

http://localhost:7007/api/permission/policies/user/default/johndoe

Note

If at least one permission is assigned to user:default/johndoe, then the example request URL mentioned previously returns a result if sent in a GET response with a valid authorization token. However, if permission is only assigned to roles, then the example request URL does not return an output.

Request data

HTTP POST requests in the RBAC REST API may require a JSON request body with data to accompany the request.

Example POST request URL and JSON request body data for http://localhost:7007/api/permission/policies:

{
    "entityReference": "role:default/test",
    "permission": "catalog-entity",
    "policy": "delete",
    "effect": "allow"
}

HTTP status codes

The RBAC REST API supports the following HTTP status codes to return as responses:

200 OK: The request was successful.
201 Created: The request resulted in a new resource being successfully created.
204 No Content: The request was successful, but there is no additional content to send in the response payload.
400 Bad Request: input error with the request
401 Unauthorized: lacks valid authentication for the requested resource
403 Forbidden: refusal to authorize request
404 Not Found: could not find requested resource
409 Conflict: request conflict with the current state and the target resource

Source

Each permission policy and role created using the RBAC plugin is associated with a source to maintain data consistency within the plugin. You can manipulate permission policies and roles based on the following designated source information:

CSV file
Configuration file
REST API
Legacy

Managing roles and permission policies originating from CSV files and REST API involves straightforward modification based on their initial source information.

The Configuration file pertains to the default role:default/rbac_admin role provided by the RBAC plugin. The default role has limited permissions to create, read, update, and delete permission policies or roles, and to read catalog entities.

Note

In case the default permissions are insufficient for your administrative requirements, you can create a custom admin role with required permission policies.

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. You must update the permissions and roles in legacy source to use either REST API or the CSV file sources.

You can use the GET requests to query roles and policies and determine the source information, if required.

5.1. Sending requests with the RBAC REST API using a REST client or curl utility

The RBAC REST API enables you to interact with the permission policies and roles in Developer Hub without using the user interface. You can send RBAC REST API requests using any REST client or curl utility.

Prerequisites

Red Hat Developer Hub is installed and running.

For more information about installing Red Hat Developer Hub, see Installing Red Hat Developer Hub on OpenShift Container Platform with the Helm chart.

You have access to the Developer Hub.

Procedure

Identify a relevant API endpoint to which you want to send a request, such as POST /api/permission/policies. Adjust any request details according to your use case.
For REST client:
- Authorization: Enter the generated token from the web console.
- HTTP method: Set to POST.
- URL: Enter the RBAC REST API base URL and endpoint such as http://localhost:7007/api/permission/policies.
For curl utility:
- -X: Set to POST
- -H: Set the following header:
  Content-type: application/json
  Authorization: Bearer $token
  $token is the requested token from the web console in a browser.
- URL: Enter the following RBAC REST API base URL endpoint, such as http://localhost:7007/api/permission/policies
- -d: Add a request JSON body
Example requests:
curl -X POST "http://localhost:7007/api/permission/roles" -d '{"memberReferences": ["group:default/example"], "name": "role:default/test", "metadata": { "description": "This is a test role" } }' -H "Content-Type: application/json" -H "Authorization: Bearer $token" -v
curl -X POST "http://localhost:7007/api/permission/policies" -d '[{"entityReference":"role:default/test", "permission": "catalog-entity", "policy": "read", "effect":"allow"}]' -H "Content-Type: application/json" -H "Authorization: Bearer $token" -v
curl -X POST "http://localhost:7007/api/permission/roles/conditions" -d '{"result": "CONDITIONAL", "roleEntityRef": "role:default/test", "pluginId": "catalog", "resourceType": "catalog-entity", "permissionMapping": ["read"], "conditions": {"rule": "IS_ENTITY_OWNER", "resourceType": "catalog-entity", "params": {"claims": ["group:default/janus-authors"]}}}' -H "Content-Type: application/json" -H "Authorization: Bearer $token" -v
Execute the request and review the response.

5.2. Supported RBAC REST API endpoints

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.

5.2.1. Roles

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)

[
  {
    "memberReferences": ["user:default/username"],
    "name": "role:default/guests"
  },
  {
    "memberReferences": [
      "group:default/groupname",
      "user:default/username"
    ],
    "name": "role:default/rbac_admin"
  }
]

[GET] /api/permission/roles/{kind}/{namespace}/{name}

Returns information for a single role in Developer Hub.

Example response (JSON)

[
  {
    "memberReferences": [
      "group:default/groupname",
      "user:default/username"
    ],
    "name": "role:default/rbac_admin"
  }
]

[POST] /api/permission/roles/{kind}/{namespace}/{name}

Creates a role in Developer Hub.

Table 5.1. Request parameters
Name	Description	Type	Presence
`body`	The `memberReferences`, `group`, `namespace`, and `name` the new role to be created.	Request body	Required

Example request body (JSON)

{
  "memberReferences": ["group:default/test"],
  "name": "role:default/test_admin"
}

Example response

201 Created

[PUT] /api/permission/roles/{kind}/{namespace}/{name}

Updates memberReferences, kind, namespace, or name for a role in Developer Hub.

Request parameters

The request body contains the oldRole and newRole objects:

Name	Description	Type	Presence
`body`	The `memberReferences`, `group`, `namespace`, and `name` the new role to be created.	Request body	Required

Example request body (JSON)

{
  "oldRole": {
    "memberReferences": ["group:default/test"],
    "name": "role:default/test_admin"
  },
  "newRole": {
    "memberReferences": ["group:default/test", "user:default/test2"],
    "name": "role:default/test_admin"
  }
}

Example response

200 OK

[DELETE] /api/permission/roles/{kind}/{namespace}/{name}?memberReferences=<VALUE>

Deletes the specified user or group from a role in Developer Hub.

Table 5.2. Request parameters
Name	Description	Type	Presence
`kind`	Kind of the entity	String	Required
`namespace`	Namespace of the entity	String	Required
`name`	Name of the entity	String	Required
`memberReferences`	Associated group information	String	Required

Example response

[DELETE] /api/permission/roles/{kind}/{namespace}/{name}

Deletes a specified role from Developer Hub.

Table 5.3. Request parameters
Name	Description	Type	Presence
`kind`	Kind of the entity	String	Required
`namespace`	Namespace of the entity	String	Required
`name`	Name of the entity	String	Required

Example response

5.2.2. Permission policies

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)

[
  {
    "entityReference": "role:default/test",
    "permission": "catalog-entity",
    "policy": "read",
    "effect": "allow",
    "metadata": {
      "source": "csv-file"
    }
  },
  {
    "entityReference": "role:default/test",
    "permission": "catalog.entity.create",
    "policy": "use",
    "effect": "allow",
    "metadata": {
      "source": "csv-file"
    }
  },
]

[GET] /api/permission/policies/{kind}/{namespace}/{name}

Returns permission policies related to the specified entity reference.

Table 5.4. Request parameters
Name	Description	Type	Presence
`kind`	Kind of the entity	String	Required
`namespace`	Namespace of the entity	String	Required
`name`	Name related to the entity	String	Required

Example response (JSON)

[
  {
    "entityReference": "role:default/test",
    "permission": "catalog-entity",
    "policy": "read",
    "effect": "allow",
    "metadata": {
      "source": "csv-file"
    }
  },
  {
    "entityReference": "role:default/test",
    "permission": "catalog.entity.create",
    "policy": "use",
    "effect": "allow",
    "metadata": {
      "source": "csv-file"
    }
  }
]

[POST] /api/permission/policies

Creates a permission policy for a specified entity.

Table 5.5. Request parameters
Name	Description	Type	Presence
`entityReference`	Reference values of an entity including `kind`, `namespace`, and `name`	String	Required
`permission`	Permission from a specific plugin, resource type, or name	String	Required
`policy`	Policy action for the permission, such as `create`, `read`, `update`, `delete`, or `use`	String	Required
`effect`	Indication of allowing or not allowing the policy	String	Required

Example request body (JSON)

[
  {
    "entityReference": "role:default/test",
    "permission": "catalog-entity",
    "policy": "read",
    "effect": "allow"
  }
]

Example response

201 Created

[PUT] /api/permission/policies/{kind}/{namespace}/{name}

Updates a permission policy for a specified entity.

Request parameters

The request body contains the oldPolicy and newPolicy objects:

Name	Description	Type	Presence
`permission`	Permission from a specific plugin, resource type, or name	String	Required
`policy`	Policy action for the permission, such as `create`, `read`, `update`, `delete`, or `use`	String	Required
`effect`	Indication of allowing or not allowing the policy	String	Required

Example request body (JSON)

{
  "oldPolicy": [
    {
      "permission": "catalog-entity",
      "policy": "read",
      "effect": "allow"
    },
    {
      "permission": "catalog.entity.create",
      "policy": "create",
      "effect": "allow"
    }
  ],
  "newPolicy": [
    {
      "permission": "catalog-entity",
      "policy": "read",
      "effect": "deny"
    },
    {
      "permission": "policy-entity",
      "policy": "read",
      "effect": "allow"
    }
  ]
}

Example response

[DELETE] /api/permission/policies/{kind}/{namespace}/{name}?permission={value1}&policy={value2}&effect={value3}

Deletes a permission policy added to the specified entity.

Table 5.6. Request parameters
Name	Description	Type	Presence
`kind`	Kind of the entity	String	Required
`namespace`	Namespace of the entity	String	Required
`name`	Name related to the entity	String	Required
`permission`	Permission from a specific plugin, resource type, or name	String	Required
`policy`	Policy action for the permission, such as `create`, `read`, `update`, `delete`, or `use`	String	Required
`effect`	Indication of allowing or not allowing the policy	String	Required

Example response

204 No Content

[DELETE] /api/permission/policies/{kind}/{namespace}/{name}

Deletes all permission policies added to the specified entity.

Table 5.7. Request parameters
Name	Description	Type	Presence
`kind`	Kind of the entity	String	Required
`namespace`	Namespace of the entity	String	Required
`name`	Name related to the entity	String	Required

Example response

204 No Content

[GET] /api/permission/plugins/policies

Returns permission policies for all static plugins.

Example response (JSON)

[
  {
    "pluginId": "catalog",
    "policies": [
      {
        "isResourced": true,
        "permission": "catalog-entity",
        "policy": "read"
      },
      {
        "isResourced": false,
        "permission": "catalog.entity.create",
        "policy": "create"
      },
      {
        "isResourced": true,
        "permission": "catalog-entity",
        "policy": "delete"
      },
      {
        "isResourced": true,
        "permission": "catalog-entity",
        "policy": "update"
      },
      {
        "isResourced": false,
        "permission": "catalog.location.read",
        "policy": "read"
      },
      {
        "isResourced": false,
        "permission": "catalog.location.create",
        "policy": "create"
      },
      {
        "isResourced": false,
        "permission": "catalog.location.delete",
        "policy": "delete"
      }
    ]
  },
  ...
]

5.2.3. Conditional policies

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)

[
   {
      "pluginId": "catalog",
      "rules": [
         {
            "name": "HAS_ANNOTATION",
            "description": "Allow entities with the specified annotation",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "annotation": {
                     "type": "string",
                     "description": "Name of the annotation to match on"
                  },
                  "value": {
                     "type": "string",
                     "description": "Value of the annotation to match on"
                  }
               },
               "required": [
                  "annotation"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "HAS_LABEL",
            "description": "Allow entities with the specified label",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "label": {
                     "type": "string",
                     "description": "Name of the label to match on"
                  }
               },
               "required": [
                  "label"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "HAS_METADATA",
            "description": "Allow entities with the specified metadata subfield",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "key": {
                     "type": "string",
                     "description": "Property within the entities metadata to match on"
                  },
                  "value": {
                     "type": "string",
                     "description": "Value of the given property to match on"
                  }
               },
               "required": [
                  "key"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "HAS_SPEC",
            "description": "Allow entities with the specified spec subfield",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "key": {
                     "type": "string",
                     "description": "Property within the entities spec to match on"
                  },
                  "value": {
                     "type": "string",
                     "description": "Value of the given property to match on"
                  }
               },
               "required": [
                  "key"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "IS_ENTITY_KIND",
            "description": "Allow entities matching a specified kind",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "kinds": {
                     "type": "array",
                     "items": {
                        "type": "string"
                     },
                     "description": "List of kinds to match at least one of"
                  }
               },
               "required": [
                  "kinds"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         },
         {
            "name": "IS_ENTITY_OWNER",
            "description": "Allow entities owned by a specified claim",
            "resourceType": "catalog-entity",
            "paramsSchema": {
               "type": "object",
               "properties": {
                  "claims": {
                     "type": "array",
                     "items": {
                        "type": "string"
                     },
                     "description": "List of claims to match at least one on within ownedBy"
                  }
               },
               "required": [
                  "claims"
               ],
               "additionalProperties": false,
               "$schema": "http://json-schema.org/draft-07/schema#"
            }
         }
      ]
   }
   ... <another plugin condition parameter schemas>
]

[GET] /api/permission/roles/conditions/:id

Returns conditions for the specified ID.

Example response (JSON)

{
  "id": 1,
  "result": "CONDITIONAL",
  "roleEntityRef": "role:default/test",
  "pluginId": "catalog",
  "resourceType": "catalog-entity",
  "permissionMapping": ["read"],
  "conditions": {
    "anyOf": [
      {
        "rule": "IS_ENTITY_OWNER",
        "resourceType": "catalog-entity",
        "params": {
          "claims": ["group:default/team-a"]
        }
      },
      {
        "rule": "IS_ENTITY_KIND",
        "resourceType": "catalog-entity",
        "params": {
          "kinds": ["Group"]
        }
      }
    ]
  }
}

[GET] /api/permission/roles/conditions

Returns list of all conditions for all roles.

Example response (JSON)

[
  {
    "id": 1,
    "result": "CONDITIONAL",
    "roleEntityRef": "role:default/test",
    "pluginId": "catalog",
    "resourceType": "catalog-entity",
    "permissionMapping": ["read"],
    "conditions": {
      "anyOf": [
        {
          "rule": "IS_ENTITY_OWNER",
          "resourceType": "catalog-entity",
          "params": {
            "claims": ["group:default/team-a"]
          }
        },
        {
          "rule": "IS_ENTITY_KIND",
          "resourceType": "catalog-entity",
          "params": {
            "kinds": ["Group"]
          }
        }
      ]
    }
  }
]

[POST] /api/permission/roles/conditions

Creates a conditional policy for the specified role.

Table 5.8. Request parameters
Name	Description	Type	Presence
`result`	Always has the value `CONDITIONAL`	String	Required
`roleEntityRef`	String entity reference to the RBAC role, such as `role:default/dev`	String	Required
`pluginId`	Corresponding plugin ID, such as `catalog`	String	Required
`permissionMapping`	Array permission action, such as `['read', 'update', 'delete']`	String array	Required
`resourceType`	Resource type provided by the plugin, such as `catalog-entity`	String	Required
`conditions`	Condition JSON with parameters or array parameters joined by criteria	JSON	Required
`name`	Name of the role	String	Required
`metadata.description`	The description of the role	String	Optional

Example request body (JSON)

{
  "result": "CONDITIONAL",
  "roleEntityRef": "role:default/test",
  "pluginId": "catalog",
  "resourceType": "catalog-entity",
  "permissionMapping": ["read"],
  "conditions": {
    "rule": "IS_ENTITY_OWNER",
    "resourceType": "catalog-entity",
    "params": {
      "claims": ["group:default/team-a"]
    }
  }
}

Example response (JSON)

{
  "id": 1
}

[PUT] /permission/roles/conditions/:id

Updates a condition policy for a specified ID.

Table 5.9. Request parameters
Name	Description	Type	Presence
`result`	Always has the value `CONDITIONAL`	String	Required
`roleEntityRef`	String entity reference to the RBAC role, such as `role:default/dev`	String	Required
`pluginId`	Corresponding plugin ID, such as `catalog`	String	Required
`permissionMapping`	Array permission action, such as `['read', 'update', 'delete']`	String array	Required
`resourceType`	Resource type provided by the plugin, such as `catalog-entity`	String	Required
`conditions`	Condition JSON with parameters or array parameters joined by criteria	JSON	Required
`name`	Name of the role	String	Required
`metadata.description`	The description of the role	String	Optional

Example request body (JSON)

{
  "result": "CONDITIONAL",
  "roleEntityRef": "role:default/test",
  "pluginId": "catalog",
  "resourceType": "catalog-entity",
  "permissionMapping": ["read"],
  "conditions": {
    "anyOf": [
      {
        "rule": "IS_ENTITY_OWNER",
        "resourceType": "catalog-entity",
        "params": {
          "claims": ["group:default/team-a"]
        }
      },
      {
        "rule": "IS_ENTITY_KIND",
        "resourceType": "catalog-entity",
        "params": {
          "kinds": ["Group"]
        }
      }
    ]
  }
}

Example response

[DELETE] /api/permission/roles/conditions/:id

Deletes a conditional policy for the specified ID.

Example response

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Configuring authorization by using role based access control (RBAC) in Red Hat Developer Hub

Chapter 1. Role-Based Access Control (RBAC) in Red Hat Developer Hub

Chapter 2. Permission policies in Red Hat Developer Hub

2.1. Permission policies configuration

2.1.1. Configuration of permission policies administrators

2.1.2. Configuration of permission policies defined in an external file

2.1.2.1. Mounting `policy.csv` file to the Developer Hub Helm chart

Chapter 3. Conditional policies in Red Hat Developer Hub

3.1. Conditional policies definition

3.1.1. Examples of conditional policies

Chapter 4. Managing role-based access controls (RBAC) using the Red Hat Developer Hub Web UI

4.1. Creating a role in the Red Hat Developer Hub Web UI

4.2. Editing a role in the Red Hat Developer Hub Web UI

4.3. Deleting a role in the Red Hat Developer Hub Web UI

Chapter 5. Role-based Access Control (RBAC) REST API

5.1. Sending requests with the RBAC REST API using a REST client or curl utility

5.2. Supported RBAC REST API endpoints

5.2.1. Roles

5.2.2. Permission policies

5.2.3. Conditional policies

Legal Notice

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Authorization

Configuring authorization by using role based access control (RBAC) in Red Hat Developer Hub

Chapter 1. Role-Based Access Control (RBAC) in Red Hat Developer Hub

Chapter 2. Permission policies in Red Hat Developer Hub

2.1. Permission policies configuration

2.1.1. Configuration of permission policies administrators

2.1.2. Configuration of permission policies defined in an external file

2.1.2.1. Mounting policy.csv file to the Developer Hub Helm chart

Chapter 3. Conditional policies in Red Hat Developer Hub

3.1. Conditional policies definition

3.1.1. Examples of conditional policies

Chapter 4. Managing role-based access controls (RBAC) using the Red Hat Developer Hub Web UI

4.1. Creating a role in the Red Hat Developer Hub Web UI

4.2. Editing a role in the Red Hat Developer Hub Web UI

4.3. Deleting a role in the Red Hat Developer Hub Web UI

Chapter 5. Role-based Access Control (RBAC) REST API

5.1. Sending requests with the RBAC REST API using a REST client or curl utility

5.2. Supported RBAC REST API endpoints

5.2.1. Roles

5.2.2. Permission policies

5.2.3. Conditional policies

Legal Notice

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links

2.1.2.1. Mounting `policy.csv` file to the Developer Hub Helm chart