Administration guide for Red Hat Developer Hub

The Red Hat Developer Hub is an enterprise-grade, open developer platform that is used for building developer portals. This platform contains a supported and opinionated framework that helps reduce the friction and frustration of developers while boosting their productivity.

Red Hat Developer Hub support

If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal at http://access.redhat.com. You can use the Red Hat Customer Portal to search or browse through the Red Hat Knowledgebase of technical support articles about Red Hat products. You can also create a support case for Red Hat Global Support Services (GSS). Please select "Red Hat Developer Hub" as the product and select the appropriate product version.

1. Overview of Red Hat Developer Hub

Red Hat Developer Hub (Developer Hub) serves as an open developer platform designed for building developer portals. Using Developer Hub, the engineering teams can access a unified platform that streamlines the development process and provides a variety of tools and resources to build high-quality software efficiently.

The goal of Developer Hub is to address the difficulties associated with creating and sustaining developer portals using:

A centralized dashboard to view all available developer tools and resources to increase productivity
Self-service capabilities, along with guardrails, for cloud-native application development that complies with enterprise-class best practices
Proper security and governance for all developers across the enterprise

The Red Hat Developer Hub simplifies decision-making by providing a developer experience that presents a selection of internally approved tools, programming languages, and various developer resources within a self-managed portal. This approach contributes to the acceleration of application development and the maintenance of code quality, all while fostering innovation.

2. Installing Red Hat Developer Hub using Helm Chart

You can use a Helm Chart in Red Hat OpenShift (OpenShift) to install Red Hat Developer Hub, which is a flexible installation method.

Helm is a package manager on OpenShift that provides the following features:

Applies regular application updates using custom hooks
Manages the installation of complex applications
Provides charts that you can host on public and private servers
Supports rolling back to previous application versions

The Red Hat Developer Hub Helm Chart is available in the Helm catalog in Red Hat OpenShift Dedicated and OpenShift Container Platform (OCP).

Prerequisites

You are logged in to the OCP using the OpenShift web console.
You have configured the appropriate roles and permissions within your project to create an application.

Procedure

Create a project in the OpenShift, if not present.

For more information about creating a project in OpenShift, see Red Hat OpenShift documentation.
Switch to Developer mode on your Red Hat OpenShift web console.
Click +Add.
From the Developer Catalog panel, click Helm Chart.
Search for Developer Hub in the search bar and select the Red Hat Developer Hub card.
Click Create.
Copy the OpenShift router host (for example: apps.<clusterName>.com) to Root Schema → global → Shorthand for users who do not want to specify a custom HOSTNAME. Used ONLY with the DEFAULT upstream.backstage.appConfig value and with OCP Route enabled., and adjust the other values if needed.
Alternatively, copy the OpenShift router host (for example: apps.<clusterName>.com) to global.clusterRouterBase, and adjust other values if needed, such as global.clusterRouterBase: apps.example.com.

In the previous steps, the information about the host is copied, which is accessed by the Developer Hub backend.

When an OCP route is generated automatically, the host value for the route is inferred and the same host information is sent to the Developer Hub. Also, if the Developer Hub is present on a custom domain by setting the host manually using values, the custom host takes precedence.
Click Create and wait for the database and Red Hat Developer Hub to start.
Click the Open URL option to start using the Red Hat Developer Hub platform.

Note

If your developer-hub pod is stuck in a CrashLoopBackOff and you see the following logs:

Loaded config from app-config-from-configmap.yaml, env
...
2023-07-24T19:44:46.223Z auth info Configuring "database" as KeyStore provider type=plugin
Backend failed to start up Error: Missing required config value at 'backend.database.client'

Then, verify the configuration files. This is because the configuration files are not being accessed by the RHDH container.

3. Air-gapped environment

An air-gapped environment, also known as an air-gapped network or isolated network, ensures security by physically segregating the system or network. This isolation is established to prevent unauthorized access, data transfer, or communication between the air-gapped system and external sources.

You can install the Red Hat Developer Hub in an air-gapped environment to ensure security and meet specific regulatory requirements.

3.1. Installing Red Hat Developer Hub in an air-gapped environment

To install the Developer Hub in an air-gapped environment, you must have access to the registry.redhat.io and the registry for the air-gapped environment.

Prerequisites

You have installed an Openshift Container Platform (OCP) 4.10 or later.
You have access to the registry.redhat.io.
You have access to the OpenShift image registry of your cluster. For more information about exposing the OpenShift image registry, see Exposing the registry in OpenShift documentation.
You have installed the oc command line tool on your workstation.
You have installed the podman command line tools on your workstation.
You you have an account in Red Hat Developer portal.

Procedure

oc login -u <user> -p <password> https://api.<HOSTNAME>:6443

podman login -u kubeadmin -p $(oc whoami -t) default-route-openshift-image-registry.<HOSTNAME>

Note

You can use the following commands to get the full host name of the OpenShift image registry and than use the host name in a command to log in:

REGISTRY_HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')

podman login -u kubeadmin -p $(oc whoami -t) $REGISTRY_HOST

Log in to the registry.redhat.io in podman using the following command:
podman login registry.redhat.io
For more information about registry authentication, see Red Hat Container Registry Authentication.

Pull Developer Hub and PostgreSQL images from Red Hat Image registry to your workstation:

podman pull <DEVELOPERHUBIMAGE>
podman pull registry.redhat.io/rhel9/postgresql-15:latest

Push both images to the internal OCP registry.

For more information about pushing images directly to OCP registry, see How do I push an Image directly into the OpenShift 4 registry.

podman push --remove-signatures registry.redhat.io/rhel9/postgresql-15:latest default-route-openshift-image-registry.<hostname>/<yourProject>/postgresql-15:latest

Tip	If an x509 error occurs, ensure you install the CA certificate used for OpenShift routes on your system. Optionally, you can append `--tls-verify=false` to the `podman` push command, note that this approach is not recommended.

Use the following command to verify that both images are present in the internal OCP registry:
oc get imagestream -n <projectName>
Enable local image lookup for both images using the following commands:
oc set image-lookup postgresql-15 oc set image-lookup rhdh-hub-rhel9

Go to YAML view and update the image section for backstage and postgresql using the following values:

Example values for Developer Hub image

upstream:
  backstage:
    image:
      registry: ""
      repository: rhdh-hub-rhel9
      tag: latest

Example values for PostgreSQL image

upstream:
  postgresql:
    image:
      registry: ""
      repository: postgresql-15
      tag: latest

Install the Red Hat Developer Hub using Helm Chart. For more information about installing Developer Hub, see Installing Red Hat Developer Hub using Helm Chart.

4. 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.

4.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

4.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 set the credentials of a permission policy administrator in the app-config.yaml file as follows:

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

4.1.2. Configuration of permission policies defined in an external file

You can follow this approach of configuring 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. The permission policies need to be defined in Casbin rules format. 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, deny

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

g, user:default/<USER_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, deny

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

Mounting `policy.csv` file to the Developer Hub Helm Chart

When the Red Hat Developer Hub is deployed with the Helm Chart, then 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 the OCP using the OpenShift web console.
Red Hat Developer Hub is installed and deployed using Helm Chart.

For more information about installing the Red Hat Developer Hub using Helm Chart, see Installing Red Hat Developer Hub using Helm Chart.

Procedure

In Red Hat OpenShift, 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

4.1.3. 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.

The following permission policies are supported in the Developer Hub:

Catalog permissions

Name Resource type Policy Description

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

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

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

RBAC permissions

Name Resource type Policy Description

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

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

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

kubernetes.proxy

Allows user or role to access the proxy endpoint

4.2. 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 Homepage of the Developer Hub, you can navigate to the Network tab and search for the query?term= network call. Alternatively, you can go to the Catalog page and select any network call with entity-facets 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 username, 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

4.2.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 using 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 request:

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
Execute the request and review the response.

4.2.2. Supported RBAC REST API endpoints

The RBAC REST API provides the following endpoints for managing permission policies and roles in the Developer Hub and for retrieving information about the policies and roles.

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"
  },
  {
    "entityReference": "role:default/test",
    "permission": "catalog.entity.create",
    "policy": "use",
    "effect": "allow"
  },
]

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

Returns permission policies related to the specified entity reference.

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

Example response (JSON)

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

[POST] /api/permission/policies

Creates a permission policy for a specified entity.

Table 2. Request parameters
Name	Description	Type	Requirement
`entityReference`	Reference values of an entity including namespace and name	String	Required
`permission`	Type of the permission	String	Required
`policy`	Read or write policy to the permission	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 Requirement

Name	Description	Type	Requirement
`permission`	Type of the permission	String	Required
`policy`	Read or write policy to the permission	String	Required
`effect`	Indication of allowing or not allowing the policy	String	Required

permission

Type of the permission

String

Required

policy

Read or write policy to the permission

String

Required

effect

Indication of allowing or not allowing the policy

String

Required

Example request body (JSON)

{
    "oldPolicy": {
        "permission": "catalog-entity",
        "policy": "read",
        "effect": "deny"
    },
    "newPolicy": {
        "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 3. Request parameters
Name	Description	Type	Requirement
`kind`	Kind of the entity	String	Required
`namespace`	Namespace of the entity	String	Required
`name`	Username related to the entity	String	Required
`permission`	Type of the permission	String	Required
`policy`	Read or write policy to the permission	String	Required
`effect`	Indication of allowing or not allowing the policy	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": [
        {
          "permission": "catalog-entity",
          "policy": "read"
        },
        {
          "permission": "catalog.entity.create",
          "policy": "create"
        },
        {
          "permission": "catalog-entity",
          "policy": "delete"
        },
        {
          "permission": "catalog-entity",
          "policy": "update"
        },
        {
          "permission": "catalog.location.read",
          "policy": "read"
        },
        {
          "permission": "catalog.location.create",
          "policy": "create"
        },
        {
          "permission": "catalog.location.delete",
          "policy": "delete"
        }
      ]
    },
  ...
]

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/pataknight"],
    "name": "role:default/guests"
  },
  {
    "memberReferences": [
      "group:default/janus-authors",
      "user:default/matt"
    ],
    "name": "role:default/rbac_admin"
  }
]

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

Creates a role in Developer Hub.

Table 4. Request parameters
Name	Description	Type	Requirement
`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 Requirement

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. Request parameters
Name	Description	Type	Requirement
`kind`	Kind of the entity	String	Required
`namespace`	Namespace of the entity	String	Required
`name`	Username related to 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 6. Request parameters
Name	Description	Type	Requirement
`kind`	Kind of the entity	String	Required
`namespace`	Namespace of the entity	String	Required
`name`	Username related to the entity	String	Required

Example response

5. Installing dynamic plugins

The dynamic plugin support is based on the backend plugin manager package, which is a service that scans a configured root directory (dynamicPlugins.rootDirectory in the app config) for dynamic plugin packages, and loads them dynamically.

5.1. Helm deployment

To deploy a Red Hat Developer Hub (RHDH) instance, you use a Helm Chart which is a flexible installation method.

You can sideload dynamic plugins into your Developer Hub instance without having to recompile your code or rebuild the container.

To install dynamic plugins, you use the following global.dynamic parameters in your Helm Chart:

plugins: This field encompasses the list of dynamic plugins slated for installation. By default, it is an empty list. A package can be specified either as a local relative path (starting with ./) to the dynamic plugin’s folder or as a package specification in an NPM repository.
includes: This field contains a roster of YAML files utilizing the same syntax. The plugins list from these files will be incorporated, and potentially overridden, by the plugins list in the primary helm values. The default configuration includes the dynamic-plugins.default.yaml file, which encompasses all the dynamic plugins included in Developer Hub, whether enabled or disabled by default.

5.2. Dynamic plugin installation using the Helm Chart

You can include a dynamic plugin in RHDH by appending an entry to the global.dynamic.plugins list in your Helm Chart.

Each entry must contain the following fields:

package: a package specification of the dynamic plugin package to be installed (can be from a local path or an NPM repository)
integrity: (optional for local packages) An integrity checksum in the form of <alg>-<digest> for the specific package. Supported algorithms include sha256, sha384 and sha512.
pluginConfig: an optional plugin-specific app-config yaml fragment. See plugin configuration for more details.
disabled: disables the dynamic plugin if set to true. Default: false.

5.2.1. Examples

Example 1: Enabling two plugins from a local and remote source, one requiring a specific app-config

global:
  dynamic:
    plugins:
      - package: <a local package-spec used by npm pack>
      - package: <a remote package-spec used by npm pack>
        integrity: sha512-<some hash>
        pluginConfig: ...

Example 2: Disabling a plugin from an included file

global:
  dynamic:
    includes:
      - dynamic-plugins.default.yaml
    plugins:
      - package: <some imported plugins listed in dynamic-plugins.default.yaml>
        disabled: true

Example 3: Enabling a plugin from an included file

global:
  dynamic:
    includes:
      - dynamic-plugins.default.yaml
    plugins:
      - package: <some imported plugins listed in dynamic-plugins.custom.yaml>
        disabled: false

5.3. Dynamic plugins pre-loaded in Red Hat Developer Hub

Red Hat Developer Hub (Developer Hub) is pre-loaded with a selection of dynamic plugins. Most of these dynamic plugins are disabled by default due to the need for mandatory configuration.

For a complete list of dynamic plugins that are included in this release of RHDH, see the dynamic plugins matrix table.

Upon application startup, for each plugin that is disabled by default, the install-dynamic-plugins init container within the Developer Hub pod’s log displays a line similar to the following:

======= Skipping disabled dynamic plugin ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic

To activate this plugin, simply add a package with the same name and adjust the disabled field in the Helm Chart values as shown below:

global:
  dynamic:
    includes:
      - dynamic-plugins.default.yaml
    plugins:
      - package: ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic
        disabled: false

Note	The default configuration for a plugin is extracted from the `dynamic-plugins.default.yaml` file, however, you can use a `pluginConfig` entry to override this default configuration.

5.4. Basic configuration of dynamic plugins

Some dynamic plugins require environment variables to be set. If a mandatory environment variable is not set, and the plugin is enabled, then the application might fail at startup.

The mandatory environment variables for each plugin are listed in the dynamic plugins matrix table.

Note

Zib-bomb detection When installing some dynamic plugin containing large files, if the installation script considers the package archive to be a Zib-Bomb, the installation fails.

To increase the maximum permitted size of a file inside a package archive, you can increase the MAX_ENTRY_SIZE environment value of the deployment install-dynamic-plugins initContainer from the default size of 20000000 bytes.

5.5. Dynamic plugins included in Red Hat Developer Hub

Important

Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information on Red Hat Technology Preview features, see Technology Preview Features Scope.

Additional detail on how Red Hat provides support for bundled community dynamic plugins is available on the Red Hat Developer Support Policy page.

There are 47 plugins.

Table 7. Dynamic plugins support matrix
Name	Role	Plugin	Description	Version	Support Level	Path	Required Variables	Default
3scale	Backend	@janus-idp/backstage-plugin-3scale-backend	The 3scale Backstage provider plugin synchronizes the 3scale content into the Backstage catalog.	1.3.6	Red Hat Tech Preview	./dynamic-plugins/dist/janus-idp-backstage-plugin-3scale-backend-dynamic	`3SCALE_BASE_URL` `3SCALE_ACCESS_TOKEN`	Disabled
AAP	Backend	@janus-idp/backstage-plugin-aap-backend		1.4.5	Red Hat Tech Preview	./dynamic-plugins/dist/janus-idp-backstage-plugin-aap-backend-dynamic	`AAP_BASE_URL` `AAP_AUTH_TOKEN`	Disabled
ACR	Frontend	@janus-idp/backstage-plugin-acr		1.2.4	Red Hat Tech Preview	./dynamic-plugins/dist/janus-idp-backstage-plugin-acr		Disabled
Analytics Provider Segment	Frontend	@janus-idp/backstage-plugin-analytics-provider-segment	This plugin provides an implementation of the Backstage Analytics API for Segment. Once installed and configured, analytics events will be sent to Segment as your users navigate and use your Backstage instance.	1.2.0	Production	./dynamic-plugins/dist/janus-idp-backstage-plugin-analytics-provider-segment	`SEGMENT_WRITE_KEY` `SEGMENT_MASK_IP` `SEGMENT_TEST_MODE`	Disabled
Argo CD	Frontend	@roadiehq/backstage-plugin-argo-cd	Backstage plugin to view and interact with Argo CD.	2.3.5	Production	./dynamic-plugins/dist/roadiehq-backstage-plugin-argo-cd		Disabled
Argo CD	Backend	@roadiehq/backstage-plugin-argo-cd-backend	Backstage plugin Argo CD backend	2.11.3	Production	./dynamic-plugins/dist/roadiehq-backstage-plugin-argo-cd-backend-dynamic	`ARGOCD_USERNAME` `ARGOCD_PASSWORD` `ARGOCD_INSTANCE1_URL` `ARGOCD_AUTH_TOKEN` `ARGOCD_INSTANCE2_URL` `ARGOCD_AUTH_TOKEN2`	Disabled
Argo CD	Backend	@roadiehq/scaffolder-backend-argocd		1.1.17	Community Support	./dynamic-plugins/dist/roadiehq-scaffolder-backend-argocd-dynamic	`ARGOCD_USERNAME` `ARGOCD_PASSWORD` `ARGOCD_INSTANCE1_URL` `ARGOCD_AUTH_TOKEN` `ARGOCD_INSTANCE2_URL` `ARGOCD_AUTH_TOKEN2`	Disabled
Azure Devops	Frontend	@backstage/plugin-azure-devops		0.3.7	Community Support	./dynamic-plugins/dist/backstage-plugin-azure-devops		Disabled
Azure Devops	Backend	@backstage/plugin-azure-devops-backend	Azure DevOps backend plugin that contains the API for retrieving builds, pull requests, etc. which is used by the Azure DevOps frontend plugin.	0.4.3	Tech Preview	./dynamic-plugins/dist/backstage-plugin-azure-devops-backend-dynamic	`AZURE_TOKEN` `AZURE_ORG`	Disabled
Datadog	Frontend	@roadiehq/backstage-plugin-datadog	Embed Datadog graphs and dashboards into Backstage.	2.2.0	Community Support	./dynamic-plugins/dist/roadiehq-backstage-plugin-datadog		Disabled
Dynatrace	Frontend	@backstage/plugin-dynatrace	A Backstage plugin that integrates towards Dynatrace.	7.0.5	Community Support	./dynamic-plugins/dist/backstage-plugin-dynatrace		Disabled
Github	Backend	@backstage/plugin-catalog-backend-module-github	A Backstage catalog backend module that helps integrate towards Github	0.4.4	Community Support	./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic	`GITHUB_ORG`	Disabled
Github	Backend	@backstage/plugin-catalog-backend-module-github-org	The github-org backend module for the catalog plugin.	0.1.0	Community Support	./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic	`GITHUB_ORG_URL`	Disabled
Github	Frontend	@backstage/plugin-github-actions	A Backstage plugin that integrates towards GitHub Actions	0.6.6	Community Support	./dynamic-plugins/dist/backstage-plugin-github-actions		Disabled
Github	Frontend	@backstage/plugin-github-issues	A Backstage plugin that integrates towards GitHub Issues	0.2.14	Community Support	./dynamic-plugins/dist/backstage-plugin-github-issues		Disabled
Github	Frontend	@roadiehq/backstage-plugin-github-insights	Backstage plugin to provide Readmes, Top Contributors and other widgets.	2.3.21	Community Support	./dynamic-plugins/dist/roadiehq-backstage-plugin-github-insights		Disabled
Github	Frontend	@roadiehq/backstage-plugin-github-pull-requests	Backstage plugin to view and interact with GitHub pull requests.	2.5.18	Community Support	./dynamic-plugins/dist/roadiehq-backstage-plugin-github-pull-requests		Disabled
Github	Frontend	@roadiehq/backstage-plugin-security-insights	Backstage plugin to add security insights for GitHub repos.	2.3.9	Community Support	./dynamic-plugins/dist/roadiehq-backstage-plugin-security-insights		Disabled
Gitlab	Backend	@backstage/plugin-catalog-backend-module-gitlab	Extracts repositories out of an GitLab instance.	0.3.3	Community Support	./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-dynamic		Disabled
Gitlab	Backend	@backstage/plugin-scaffolder-backend-module-gitlab	A module for the scaffolder backend that lets you interact with gitlab	0.2.9	Community Support	./dynamic-plugins/dist/backstage-plugin-scaffolder-backend-module-gitlab-dynamic		Disabled
Gitlab	Frontend	@immobiliarelabs/backstage-plugin-gitlab	Backstage plugin to interact with GitLab	6.2.0	Community Support	./dynamic-plugins/dist/immobiliarelabs-backstage-plugin-gitlab		Disabled
Gitlab	Backend	@immobiliarelabs/backstage-plugin-gitlab-backend	Backstage plugin to interact with GitLab	6.2.0	Community Support	./dynamic-plugins/dist/immobiliarelabs-backstage-plugin-gitlab-backend-dynamic	`GITLAB_HOST` `GITLAB_TOKEN`	Disabled
Jenkins	Frontend	@backstage/plugin-jenkins	A Backstage plugin that integrates towards Jenkins	0.9.0	Community Support	./dynamic-plugins/dist/backstage-plugin-jenkins		Disabled
Jenkins	Backend	@backstage/plugin-jenkins-backend	A Backstage backend plugin that integrates towards Jenkins	0.3.0	Community Support	./dynamic-plugins/dist/backstage-plugin-jenkins-backend-dynamic	`JENKINS_URL` `JENKINS_USERNAME` `JENKINS_TOKEN`	Disabled
Jfrog Artifactory	Frontend	@janus-idp/backstage-plugin-jfrog-artifactory	The Jfrog Artifactory plugin displays information about your container images within the Jfrog Artifactory registry.	1.2.4	Red Hat Tech Preview	./dynamic-plugins/dist/janus-idp-backstage-plugin-jfrog-artifactory		Disabled
Jira	Frontend	@roadiehq/backstage-plugin-jira	Backstage plugin to view and interact with Jira	2.4.11	Community Support	./dynamic-plugins/dist/roadiehq-backstage-plugin-jira		Disabled
Keycloak	Backend	@janus-idp/backstage-plugin-keycloak-backend	The Keycloak backend plugin integrates Keycloak into Backstage.	1.7.6	Production	./dynamic-plugins/dist/janus-idp-backstage-plugin-keycloak-backend-dynamic	`KEYCLOAK_BASE_URL` `KEYCLOAK_LOGIN_REALM` `KEYCLOAK_REALM` `KEYCLOAK_CLIENT_ID` `KEYCLOAK_CLIENT_SECRET`	Disabled
Kubernetes	Frontend	@backstage/plugin-kubernetes	A Backstage plugin that integrates towards Kubernetes	0.11.0	Community Support	./dynamic-plugins/dist/backstage-plugin-kubernetes		Enabled
Kubernetes	Backend	@backstage/plugin-kubernetes-backend	A Backstage backend plugin that integrates towards Kubernetes	0.13.0	Production	./dynamic-plugins/dist/backstage-plugin-kubernetes-backend-dynamic	`K8S_CLUSTER_NAME` `K8S_CLUSTER_URL` `K8S_CLUSTER_TOKEN`	Enabled
Kubernetes	Frontend	@janus-idp/backstage-plugin-topology	The Topology plugin enables you to visualize the workloads such as Deployment, Job, Daemonset, Statefulset, CronJob, and Pods powering any service on the Kubernetes cluster.	1.16.4	Production	./dynamic-plugins/dist/janus-idp-backstage-plugin-topology		Enabled
Lighthouse	Frontend	@backstage/plugin-lighthouse	A Backstage plugin that integrates towards Lighthouse	0.4.10	Community Support	./dynamic-plugins/dist/backstage-plugin-lighthouse		Disabled
Nexus Repository Manager	Frontend	@janus-idp/backstage-plugin-nexus-repository-manager	The Nexus Repository Manager plugin displays the information about your build artifacts that are available in the Nexus Repository Manager in your Backstage application.	1.4.4	Red Hat Tech Preview	./dynamic-plugins/dist/janus-idp-backstage-plugin-nexus-repository-manager		Disabled
OCM	Frontend	@janus-idp/backstage-plugin-ocm	The Open Cluster Management (OCM) plugin integrates your Backstage instance with the `MultiClusterHub` and `MultiCluster` engines of OCM.	3.5.0	Production	./dynamic-plugins/dist/janus-idp-backstage-plugin-ocm		Disabled
OCM	Backend	@janus-idp/backstage-plugin-ocm-backend		3.4.6	Production	./dynamic-plugins/dist/janus-idp-backstage-plugin-ocm-backend-dynamic	`OCM_HUB_NAME` `OCM_HUB_URL` `moc_infra_token`	Disabled
Pagerduty	Frontend	@backstage/plugin-pagerduty	A Backstage plugin that integrates towards PagerDuty	0.6.6	Community Support	./dynamic-plugins/dist/backstage-plugin-pagerduty		Disabled
Quay	Frontend	@janus-idp/backstage-plugin-quay	The Quay plugin displays the information about your container images within the Quay registry in your Backstage application.	1.4.6	Production	./dynamic-plugins/dist/janus-idp-backstage-plugin-quay		Disabled
Quay	Backend	@janus-idp/backstage-scaffolder-backend-module-quay	This module provides Backstage template actions for Quay.	1.2.1	Production	./dynamic-plugins/dist/janus-idp-backstage-scaffolder-backend-module-quay-dynamic		Enabled
Regex	Backend	@janus-idp/backstage-scaffolder-backend-module-regex	This plugin provides Backstage template actions for RegExp.	1.2.1	Production	./dynamic-plugins/dist/janus-idp-backstage-scaffolder-backend-module-regex-dynamic		Enabled
Scaffolder	Backend	@roadiehq/scaffolder-backend-module-utils	This contains a collection of actions to use in scaffolder templates.	1.10.4	Community Support	./dynamic-plugins/dist/roadiehq-scaffolder-backend-module-utils-dynamic		Enabled
ServiceNow	Backend	@janus-idp/backstage-scaffolder-backend-module-servicenow	This plugin provides Backstage template actions for ServiceNow.	1.2.3	Red Hat Tech Preview	./dynamic-plugins/dist/janus-idp-backstage-scaffolder-backend-module-servicenow-dynamic	`SERVICENOW_BASE_URL` `SERVICENOW_USERNAME` `SERVICENOW_PASSWORD`	Disabled
SonarQube	Frontend	@backstage/plugin-sonarqube	A Backstage plugin to display SonarQube code quality and security results.	0.7.7	Community Support	./dynamic-plugins/dist/backstage-plugin-sonarqube		Disabled
SonarQube	Backend	@backstage/plugin-sonarqube-backend		0.2.8	Community Support	./dynamic-plugins/dist/backstage-plugin-sonarqube-backend-dynamic	`SONARQUBE_URL` `SONARQUBE_TOKEN`	Disabled
SonarQube	Backend	@janus-idp/backstage-scaffolder-backend-module-sonarqube	This module provides Backstage template actions for SonarQube.	1.2.1	Red Hat Tech Preview	./dynamic-plugins/dist/janus-idp-backstage-scaffolder-backend-module-sonarqube-dynamic		Disabled
Tech Radar	Frontend	@backstage/plugin-tech-radar	A Backstage plugin that lets you display a Tech Radar for your organization	0.6.9	Community Support	./dynamic-plugins/dist/backstage-plugin-tech-radar		Disabled
Techdocs	Frontend	@backstage/plugin-techdocs	The Backstage plugin that renders technical documentation for your components	1.8.0	Production	./dynamic-plugins/dist/backstage-plugin-techdocs		Disabled
Techdocs	Backend	@backstage/plugin-techdocs-backend	The Backstage backend plugin that renders technical documentation for your components	1.8.0	Production	./dynamic-plugins/dist/backstage-plugin-techdocs-backend-dynamic	`TECHDOCS_BUILDER_TYPE` `TECHDOCS_GENERATOR_TYPE` `TECHDOCS_PUBLISHER_TYPE` `BUCKET_NAME` `BUCKET_REGION_VAULT` `BUCKET_URL` `AWS_ACCESS_KEY_ID` `AWS_SECRET_ACCESS_KEY`	Disabled
Tekton	Frontend	@janus-idp/backstage-plugin-tekton	The Tekton plugin enables you to visualize the PipelineRun resources available on the Kubernetes cluster.	3.1.3	Production	./dynamic-plugins/dist/janus-idp-backstage-plugin-tekton		Disabled

5.6. Installation and configuration of Ansible Automation Platform

The Ansible Automation Platform (AAP) plugin synchronizes the accessible templates including job templates and workflow job templates from AAP into your Developer Hub catalog.

Important

The Ansible Automation Platform plugin is a Technology Preview feature only.

For more information on Red Hat Technology Preview features, see Technology Preview Features Scope.

Additional detail on how Red Hat provides support for bundled community dynamic plugins is available on the Red Hat Developer Support Policy page.

5.6.1. For administrators

Installing and configuring the AAP Backend plugin

The AAP backend plugin allows you to configure one or multiple providers using your app-config.yaml configuration file in Developer Hub.

Prerequisites

Your Developer Hub application is installed and running.
You have created an account in Ansible Automation Platform.

Installation

The AAP backend plugin is pre-loaded in Developer Hub with basic configuration properties. To enable it, set the disabled property to false as follows:

global:
  dynamic:
    includes:
      - dynamic-plugins.default.yaml
    plugins:
      - package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-aap-backend-dynamic
        disabled: false

Basic configuration

To enable the AAP plugin, you must set the following environment variables:

AAP_BASE_URL: Base URL of the service
AAP AUTH TOKEN: Authentication token for the service

Advanced configuration

You can use the aap marker to configure the app-config.yaml file of Developer Hub as follows:

   catalog:
     providers:
       aap:
         dev:
           baseUrl: $(AAP_BASE_URL)
           authorization: 'Bearer ${AAP_AUTH_TOKEN}'
           owner: <owner>
           system: <system>
           schedule: # optional; same options as in TaskScheduleDefinition
             # supports cron, ISO duration, "human duration" as used in code
             frequency: { minutes: 1 }
             # supports ISO duration, "human duration" as used in code
             timeout: { minutes: 1 }

Log lines for AAP Backend plugin troubleshoot

When you start your Developer Hub application, you can see the following log lines:

[1] 2023-02-13T15:26:09.356Z catalog info Discovered ResourceEntity API type=plugin target=AapResourceEntityProvider:dev
[1] 2023-02-13T15:26:09.423Z catalog info Discovered ResourceEntity Red Hat Event (DEV, v1.2.0) type=plugin target=AapResourceEntityProvider:dev
[1] 2023-02-13T15:26:09.620Z catalog info Discovered ResourceEntity Red Hat Event (TEST, v1.1.0) type=plugin target=AapResourceEntityProvider:dev
[1] 2023-02-13T15:26:09.819Z catalog info Discovered ResourceEntity Red Hat Event (PROD, v1.1.0) type=plugin target=AapResourceEntityProvider:dev
[1] 2023-02-13T15:26:09.819Z catalog info Applying the mutation with 3 entities type=plugin target=AapResourceEntityProvider:dev

5.6.2. For users

Accessing templates from AAP in Developer Hub

When you have configured the AAP backend plugin successfully, it synchronizes the templates including job templates and workflow job templates from AAP and displays them on the Developer Hub Catalog page as Resources.

Prerequisites

Your Developer Hub application is installed and running.
You have installed the AAP backend plugin. For installation and configuration instructions, see Installing and configuring the AAP Backend plugin.

Procedure

Open your Developer Hub application and Go to the Catalog page.
Select Resource from the Kind drop-down and job template or workflow job template from the Type drop-down on the left side of the page.

A list of all the available templates from AAP appears on the page.
Select a template from the list.
The OVERVIEW tab appears containing different cards, such as:
- About: Provides detailed information about the template.
- Relations: Displays the visual representation of the template and associated aspects.
- Links: Contains links to the AAP dashboard and the details page of the template.
- Has subcomponents: Displays a list of associated subcomponents.

5.7. Installation and configuration of Keycloak

The Keycloak backend plugin, which integrates Keycloak into Developer Hub, has the following capabilities:

Synchronization of Keycloak users in a realm.
Synchronization of Keycloak groups and their users in a realm.

5.7.1. For administrators

Installation

The Keycloak plugin is pre-loaded in Developer Hub with basic configuration properties. To enable it, set the disabled property to false as follows:

global:
  dynamic:
    includes:
      - dynamic-plugins.default.yaml
    plugins:
      - package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-keycloak-backend-dynamic
        disabled: false

Basic configuration

To enable the Keycloak plugin, you must set the following environment variables:

KEYCLOAK_BASE_URL
KEYCLOAK_LOGIN_REALM
KEYCLOAK_REALM
KEYCLOAK_CLIENT_ID
KEYCLOAK_CLIENT_SECRET

Advanced configuration

Schedule configuration

You can configure a schedule in the app-config.yaml file, as follows:

     catalog:
       providers:
         keycloakOrg:
           default:
             # ...
             # highlight-add-start
             schedule: # optional; same options as in TaskScheduleDefinition
               # supports cron, ISO duration, "human duration" as used in code
               frequency: { minutes: 1 }
               # supports ISO duration, "human duration" as used in code
               timeout: { minutes: 1 }
               initialDelay: { seconds: 15 }
               # highlight-add-end

Note	If you have made any changes to the schedule in the `app-config.yaml` file, then restart to apply the changes.

Keycloak query parameters

You can override the default Keycloak query parameters in the app-config.yaml file, as follows:

   catalog:
     providers:
       keycloakOrg:
         default:
           # ...
           # highlight-add-start
           userQuerySize: 500 # Optional
           groupQuerySize: 250 # Optional
           # highlight-add-end

Communication between Developer Hub and Keycloak is enabled by using the Keycloak API. Username and password, or client credentials are supported authentication methods.

The following table describes the parameters that you can configure to enable the plugin under catalog.providers.keycloakOrg.<ENVIRONMENT_NAME> object in the app-config.yaml file:

Name Description Default Value Required

Name	Description	Default Value	Required
`baseUrl`	Location of the Keycloak server, such as `https://localhost:8443/auth`. Note that the newer versions of Keycloak omit the `/auth` context path.	""	Yes
`realm`	Realm to synchronize	`master`	No
`loginRealm`	Realm used to authenticate	`master`	No
`username`	Username to authenticate	""	Yes if using password based authentication
`password`	Password to authenticate	""	Yes if using password based authentication
`clientId`	Client ID to authenticate	""	Yes if using client credentials based authentication
`clientSecret`	Client Secret to authenticate	""	Yes if using client credentials based authentication
`userQuerySize`	Number of users to query at a time	`100`	No
`groupQuerySize`	Number of groups to query at a time	`100`	No

baseUrl

Location of the Keycloak server, such as https://localhost:8443/auth. Note that the newer versions of Keycloak omit the /auth context path.

Yes

realm

Realm to synchronize

master

loginRealm

Realm used to authenticate

master

username

Username to authenticate

Yes if using password based authentication

password

Password to authenticate

Yes if using password based authentication

clientId

Client ID to authenticate

Yes if using client credentials based authentication

clientSecret

Client Secret to authenticate

Yes if using client credentials based authentication

userQuerySize

Number of users to query at a time

100

groupQuerySize

Number of groups to query at a time

100

When using client credentials, the access type must be set to confidential and service accounts must be enabled. You must also add the following roles from the realm-management client role:

query-groups
query-users
view-users

Limitations

If you have self-signed or corporate certificate issues, you can set the following environment variable before starting Developer Hub:

NODE_TLS_REJECT_UNAUTHORIZED=0

Note	The solution of setting the environment variable is not recommended.

5.7.2. For users

Import of users and groups in Developer Hub using the Keycloak plugin

After configuring the plugin successfully, the plugin imports the users and groups each time when started.

Note	If you set up a schedule, users and groups will also be imported.

After the first import is complete, you can select User to list the users from the catalog page:

You can see the list of users on the page:

When you select a user, you can see the information imported from Keycloak:

You can also select a group, view the list, and select or view the information imported from Keycloak for a group:

Administration guide for Red Hat Developer Hub

Red Hat Developer Hub support

1. Overview of Red Hat Developer Hub

2. Installing Red Hat Developer Hub using Helm Chart

3. Air-gapped environment

3.1. Installing Red Hat Developer Hub in an air-gapped environment

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

4.1. Permission policies configuration

4.1.1. Configuration of permission policies administrators

4.1.2. Configuration of permission policies defined in an external file

Mounting policy.csv file to the Developer Hub Helm Chart

4.1.3. Permission policies in Red Hat Developer Hub

4.2. Role-based Access Control (RBAC) REST API

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

4.2.2. Supported RBAC REST API endpoints

Permission policies

Roles

5. Installing dynamic plugins

5.1. Helm deployment

5.2. Dynamic plugin installation using the Helm Chart

5.2.1. Examples

5.3. Dynamic plugins pre-loaded in Red Hat Developer Hub

5.4. Basic configuration of dynamic plugins

5.5. Dynamic plugins included in Red Hat Developer Hub

5.6. Installation and configuration of Ansible Automation Platform

5.6.1. For administrators

Installing and configuring the AAP Backend plugin

Log lines for AAP Backend plugin troubleshoot

5.6.2. For users

Accessing templates from AAP in Developer Hub

5.7. Installation and configuration of Keycloak

5.7.1. For administrators

Installation

Basic configuration

Advanced configuration

Limitations

5.7.2. For users

Import of users and groups in Developer Hub using the Keycloak plugin

Mounting `policy.csv` file to the Developer Hub Helm Chart