Setting up and configuring your first Red Hat Developer Hub instance
Prepare your IT infrastructure including Red Hat OpenShift Container Platform and required external components, and run your first Red Hat Developer Hub (RHDH) instance in production.
Abstract
- 1. Checklist to run your first Red Hat Developer Hub (RHDH) instance in production
- 2. Install the Red Hat Developer Hub Operator
- 3. Prepare your external services
- 4. Provision your custom Red Hat Developer Hub configuration
- 5. Enable authentication in Red Hat Developer Hub (with mandatory steps only)
- 5.1. Understand authentication and user provisioning
- 5.2. Enable or disable authentication with the Guest user
- 5.3. Share a secret with Red Hat Build of Keycloak (RHBK)
- 5.4. Import users and groups from Red Hat Build of Keycloak (RHBK)
- 5.5. Enable authentication with Red Hat Build of Keycloak (RHBK)
- 5.6. Share a secret with GitHub
- 5.7. Import users and groups from GitHub
- 5.8. Enable authentication with GitHub
- 5.9. Share a secret with Microsoft Azure
- 5.10. Import users and groups from Microsoft Azure
- 5.11. Enable authentication with Microsoft Azure
- 6. Use the Red Hat Developer Hub Operator to run Developer Hub with your custom configuration
- 7. Switch the theme mode for your Developer Hub instance
- 8. Manage role-based access controls (RBAC) using the Red Hat Developer Hub Web UI
Prepare your IT infrastructure including Red Hat OpenShift Container Platform and required external components, and run your first Red Hat Developer Hub (RHDH) instance in production.
1. Checklist to run your first Red Hat Developer Hub (RHDH) instance in production
With the default configuration, Developer Hub runs with a minimal feature set that does not require secure connection to external services such as an identity provider, a Git provider, and external PostgreSQL and Redis databases.
Using critical features requires the following additional configuration:
- For resiliency
- Use an external PostgreSQL database.
- Enable high-availability.
- For performance
- Enable assets caching to an external Redis database.
- For security
- Use secure connections to your external services.
- Provision users and enable authentication.
- Enable role-based access control, and configure the permission policy by using the Web UI.
- For adapting to your environment
- Enable GitHub repository discovery.
- Customize Developer Hub appearance with your logo.
2. Install the Red Hat Developer Hub Operator
As an administrator, you can install the Red Hat Developer Hub Operator. Authorized users can use the Operator to install Red Hat Developer Hub on Red Hat OpenShift Container Platform (OpenShift Container Platform) and supported Kubernetes platforms.
For more information about supported platforms and versions, see the Red Hat Developer Hub Life Cycle page.
Containers are available for the following CPU architectures:
-
AMD64 and Intel 64 (
x86_64)
Prerequisites
- You have logged in as an administrator on the OpenShift Container Platform web console.
- You have configured the appropriate roles and permissions within your project to create or access an application. For more information, see the Red Hat OpenShift Container Platform documentation on Building applications.
- You have installed Red Hat OpenShift Container Platform 4.16 to 4.20.
- Make sure that your system meets the minimum sizing requirements. See Sizing requirements for Red Hat Developer Hub.
You can upgrade Red Hat Developer Hub directly from any earlier version to the latest release without installing intermediate versions. However, you must review the release notes for every skipped version to identify breaking changes or required migration steps. For example, if upgrading from version 1.5 to 1.7, check the release notes for both 1.6 and 1.7.
Procedure
- In the navigation menu of the OpenShift Container Platform console, click Operators > OperatorHub.
- In the Filter by keyword box, enter Developer Hub and click the Red Hat Developer Hub Operator card.
- On the Red Hat Developer Hub Operator page, read the information about the Operator and click Install to open the Install Operator page.
After the Operator is successfully installed, provision your custom configuration:
Before you create a Developer Hub instance, you must create the required config map and Secret resources in your project. These include the
baseUrland service-to-service authentication secrets.For detailed steps, see Provisioning your custom Red Hat Developer Hub configuration.
From the Update channel drop-down menu, select the update channel that you want to use, for example, fast or fast-1.9.
ImportantThe `fast channel includes all of the updates available for a particular version. Any update might introduce unexpected changes in your Red Hat Developer Hub deployment. Check the release notes for details about any potentially breaking changes.
The fast-1.9 channel only provides z-stream updates, for example, updating from version 1.9.1 to 1.9.2. If you want to update the Red Hat Developer Hub y-version in the future, for example, updating from 1.9 to 1.10, you must switch to the fast-1.10 channel manually.
- From the Version drop-down menu, select the version of the Red Hat Developer Hub Operator that you want to install. The default version is the latest version available in the selected channel.
Select the Operator Installation mode.
NoteThe All namespaces on the cluster (default) option is selected by default. The Specific namespace on the cluster option is not currently supported.
In the Installed Namespace field, do one of the following actions:
- Select Operator recommended Namespace to create and use the rhdh-operator namespace. This option is selected by default.
Select Select a Namespace to use an alternative namespace.
From the Select Project drop-down menu, do one of the following actions:
- Select an existing project.
Select Create Project to create a new project for the Operator.
On the Create Project dialog, enter text into the required fields and click Create.
ImportantFor enhanced security, better control over the Operator lifecycle, and preventing potential privilege escalation, install the Red Hat Developer Hub Operator in a dedicated default
rhdh-operatornamespace. You can restrict other users' access to the Operator resources through role bindings or cluster role bindings.You can also install the Operator in another namespace by creating the necessary resources, such as an Operator group. For more information, see Installing global Operators in custom namespaces.
However, if the Red Hat Developer Hub Operator shares a namespace with other Operators, then it shares the same update policy as well, preventing the customization of the update policy. For example, if one Operator is set to manual updates, the Red Hat Developer Hub Operator update policy is also set to manual. For more information, see Colocation of Operators in a namespace.
Select the Update approval method for the Operator.
- If you select the Automatic option, the Operator is updated without requiring manual confirmation.
- If you select the Manual option, a notification opens when a new update is released in the update channel. The update must be manually approved by an administrator before installation can begin.
Click Install.
NoteIf you selected a Manual approval strategy, the upgrade status of the subscription remains Upgrading until you review and approve the install plan. After you click Approve on the Install Plan page, the subscription upgrade status changes to Up to date.
If you selected an Automatic approval strategy, the upgrade status should resolve to Up to date without intervention.
Verification
- Immediately after the Operator is installed, the dialog box on the OperatorHub page displays the Installed operator: ready for use message.
From the dialog box, do one of the following actions:
- Click View Operator to open the Operator details page for the Red Hat Developer Hub Operator.
Click View all installed operators to open the Installed Operators page.
- From the list of installed Operators, locate the Red Hat Developer Hub Operator name and details.
- Click Red Hat Developer Hub Operator to open the Operator details page for the Red Hat Developer Hub Operator.
3. Prepare your external services
Red Hat Developer Hub relies on external services for production use, including a PostgreSQL database, Redis cache, GitHub API access, and an identity provider.
- PostgreSQL database
- Developer Hub stores data in a PostgreSQL database. Use an external database for resiliency and include it in your disaster recovery plan.
- Redis cache
- For efficiency, Developer Hub caches plugin and TechDocs assets when you provide a Redis cache server.
- GitHub API access
- Provide credentials to a GitHub app to enable access to the GitHub API for repository discovery.
- Connection to your identity provider
- Provide credentials to your identity provider to enable user provisioning and authentication.
Procedure
Get your external PostgreSQL database connection strings and certificates.
- postgres-host
- Your PostgreSQL instance Domain Name System (DNS) or IP address.
- postgres-port
- Your PostgreSQL instance port number, such as 5432.
- postres-username
- The user name to connect to your PostgreSQL instance.
- postgres-password
- The password to connect to your PostgreSQL instance.
- postgres-ca.pem, postgres-key.key, postgres-crt.pem
- For security, use TLS certificates to secure the connection to the database.
-
Get your Redis cache server connection string, such as
rediss://user:pass@cache.example.com:6379. For security, consider using aredisssecure server connection. Create a GitHub App to allow Developer Hub to access the GitHub API for repository. Opt for a GitHub App instead of an OAuth app to use fine-grained permissions, gain more control over which repositories the application can access, and use short-lived tokens.
Register a GitHub App with the following configuration:
- GitHub App name
-
Enter a unique name identifying your GitHub App, such as
integrating-with-rhdh-<GUID>. - Homepage URL
-
Enter your Developer Hub URL:
https://<my_developer_hub_domain>. - Authorization callback URL
-
Enter your Developer Hub authentication backend URL:
https://<my_developer_hub_domain>/api/auth/github/handler/frame. - Webhook
- Clear "Active", as this is not needed for authentication and catalog providers.
- App permissions
Select permissions to define the level of access for the app. Adapt permissions to your needs:
- Reading software components
- Contents
-
Read-only - Commit statuses
-
Read-only
- Reading organization data
- Members
-
Read-only
- Publishing software templates
Set permissions if you intend to use the same GitHub App for software templates.
- Administration
-
Read & write(for creating repositories) - Contents
-
Read & write - Metadata
-
Read-only - Pull requests
-
Read & write - Issues
-
Read & write - Workflows
-
Read & write(if templates include GitHub workflows) - Variables
-
Read & write(if templates include GitHub Action Repository Variables) - Secrets
-
Read & write(if templates include GitHub Action Repository Secrets) - Environments
-
Read & write(if templates include GitHub Environments)
- Organization permissions
- Members
-
Read-only
- Where can this GitHub App be installed?
-
Select
Only on this account.
- In the General → Clients secrets section, click Generate a new client secret.
- In the General → Private keys section, click Generate a private key.
- In the Install App tab, choose an account to install your GitHub App on.
- Save the following values for the next step:
- App ID
- Client ID
- Client secret
- Private key
4. Provision your custom Red Hat Developer Hub configuration
Provision custom config maps and secrets on {platform-long} to configure Red Hat Developer Hub before running the application.
On Red Hat OpenShift Container Platform, you can skip this step to run Developer Hub with the default config map and secret. Your changes on this configuration might get reverted on Developer Hub restart.
Prerequisites
- By using the {platform-cli-link}, you have access, with developer permissions, to the OpenShift cluster aimed at containing your Developer Hub instance.
Procedure
For security, store your secrets as environment variables values in an OpenShift Container Platform secret, rather than in plain text in your configuration files. Collect all your secrets in the
secrets.txtfile, with one secret per line inKEY=valueform.Enter your authentication secrets. :_mod-docs-content-type: SNIPPET
Author your custom
app-config.yamlfile. This is the main Developer Hub configuration file. You need a customapp-config.yamlfile to avoid the Developer Hub installer to revert user edits during upgrades. When your customapp-config.yamlfile is empty, Developer Hub is using default values.- To prepare a deployment with the Red Hat Developer Hub Operator on OpenShift Container Platform, you can start with an empty file.
To prepare a deployment with the Red Hat Developer Hub Helm chart, or on Kubernetes, enter the Developer Hub base URL in the relevant fields in your
app-config.yamlfile to ensure proper functionality of Developer Hub. The base URL is what a Developer Hub user sees in their browser when accessing Developer Hub. The relevant fields arebaseUrlin theappandbackendsections, andoriginin thebackend.corssubsection:Configuring the
baseUrlinapp-config.yaml:app: title: Red Hat Developer Hub baseUrl: https://<my_developer_hub_domain> backend: auth: externalAccess: - type: legacy options: subject: legacy-default-config secret: "${BACKEND_SECRET}" baseUrl: https://<my_developer_hub_domain> cors: origin: https://<my_developer_hub_domain>
Optionally, enter your configuration such as:
Author your custom
dynamic-plugins.yamlfile to enable plugins. By default, Developer Hub enables a minimal plugin set, and disables plugins that require configuration or secrets, such as the GitHub repository discovery plugin and the Role-based access control (RBAC) plugin.Enable the GitHub repository discovery and the RBAC features:
dynamic.plugins.yamlincludes: - dynamic-plugins.default.yaml plugins: - package: ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github disabled: false - package: ./dynamic-plugins/dist/backstage-community-plugin-rbac disabled: falseProvision your custom configuration files to your {platform} cluster.
Create the <my-rhdh-project> {namespace} aimed at containing your Developer Hub instance.
$ oc create namespace my-rhdh-project
Create config maps for your
app-config.yamlanddynamic-plugins.yamlfiles in the <my-rhdh-project> project.$ oc create configmap my-rhdh-app-config --from-file=app-config.yaml --namespace=my-rhdh-project $ oc create configmap dynamic-plugins-rhdh --from-file=dynamic-plugins.yaml --namespace=my-rhdh-project
You can also create the config maps by using the web console.
Provision your
secrets.txtfile to themy-rhdh-secretssecret in the <my-rhdh-project> project.$ oc create secret generic my-rhdh-secrets --from-file=secrets.txt --namespace=my-rhdh-project
You can also create the secret by using the web console.
5. Enable authentication in Red Hat Developer Hub (with mandatory steps only)
You can enable authentication in Red Hat Developer Hub to allow users to sign in using credentials from an external identity provider, such as RHBK, GitHub, or Microsoft Azure, and provision user and group data to the software catalog.
5.1. Understand authentication and user provisioning
User provisioning and authentication are two independent mechanisms in Red Hat Developer Hub. You can configure them separately depending on your requirements.
5.1.1. User provisioning
To fully enable catalog features, provision user and group data from an Identity Provider (IdP) to the Developer Hub software catalog. Catalog provider plugins handle this task asynchronously. These plugins query the IdP for relevant user and group information, and create or update corresponding entities in the Developer Hub catalog. Scheduled provisioning ensures that the catalog accurately reflects the users and groups in your organization.
You can provision users and groups from any supported source, including Red Hat Build of Keycloak (RHBK), GitHub, GitLab, Microsoft Azure, or LDAP. LDAP provisioning works independently of your authentication provider. Following associations are supported:
| User provisioning | Authentication |
|---|---|
|
RHBK |
RHBK |
|
LDAP |
RHBK |
|
GitHub |
GitHub |
|
Microsoft Azure |
Microsoft Azure |
For example, you can authenticate users with RHBK while provisioning user and group data from your LDAP directory.
Configuring user provisioning is critical for several reasons.
- Enabling authorization by allowing you to define access controls based on user and group memberships synchronized from your IdP.
Provisioning user and group data to the catalog is necessary for various catalog features that rely on understanding entity ownership and relationships between users, groups, and software components.
ImportantWithout this provisioning step, features such as displaying who owns a catalog entity might not function correctly.
To explore Developer Hub features in a non-production environment, you can:
- To use Developer Hub without external IdP, enable the guest user to skip configuring authentication and authorization, log in as the guest user, and access all Developer Hub features.
-
To use Developer Hub without authorization policies and features relying on the software catalog, you can enable the
dangerouslyAllowSignInWithoutUserInCatalogresolver option. This setting bypasses the check requiring a user to be in the catalog but still enforces authentication.
Developer Hub uses a one-way synchronization model, where user and group data flow from your Identity Provider to the Developer Hub software catalog. As a result, deleting users or groups manually through the Developer Hub Web UI or REST API might be ineffective or cause inconsistencies, since Developer Hub will create those entities again during the next import.
5.1.2. Authentication
When a user attempts to access Developer Hub, Developer Hub redirects them to a configured authentication provider, such as Red Hat Build of Keycloak (RHBK), GitHub, GitLab, or Microsoft Azure. This external IdP is responsible for authenticating the user.
On successful authentication, the Developer Hub authentication plugin, configured in your app-config.yaml file, processes the response from the IdP, resolves the identity in the Developer Hub software catalog, and establishes a user session within Developer Hub.
Authentication works independently of user provisioning. By default you cannot authenticate users without provisioning them to the software catalog. You can override this behavior to authenticate users without provisioning them to the software catalog, by using the dangerouslyAllowSignInWithoutUserInCatalog parameter. However, provisioning is a prerequisite for full catalog functionality, such as entity ownership and group-based access controls.
5.2. Enable or disable authentication with the Guest user
For trial or non-production environments, you can enable guest access to explore Developer Hub features without configuring authentication. For production environments, disable guest access to ensure security.
5.2.1. Enable the Guest login
To allow users to log in as a guest on the login page, enable the guest login option.
Procedure
In the
app-config.yamlfile, set the authentication environment todevelopment:auth: environment: development
- Restart the Developer Hub application to apply the changes.
Verification
- Go to the login page of your Developer Hub instance.
- Verify that the option to log in as a guest is available.
5.2.2. Disable the Guest login
To prevent users from logging in as a guest on the login page, disable the guest login option.
Procedure
In the
app-config.yamlfile, set the authentication environment toproduction:auth: environment: production
- Restart the Developer Hub application to apply the changes.
Verification
- Go to the login page of your Developer Hub instance.
- Verify that the option to log in as a guest is no longer available.
5.4. Import users and groups from Red Hat Build of Keycloak (RHBK)
Import Red Hat Build of Keycloak (RHBK) users and groups to the Red Hat Developer Hub software catalog.
Prerequisites
- You have shared a secret with RHBK.
Procedure
Enable the Keycloak catalog provider plugin in your
dynamic-plugins.yamlfile.The plugin is named after RHBK upstream project.
This plugin imports RHBK users and groups to the Developer Hub software catalog.
plugins: - package: './dynamic-plugins/dist/backstage-community-plugin-catalog-backend-module-keycloak-dynamic' disabled: falseEnable provisioning RHBK users and groups to the Developer Hub software catalog, by adding the
catalog.providers.keycloakOrgsection to yourapp-config.yamlfile:catalog: providers: keycloakOrg: default: baseUrl: ${KEYCLOAK_BASE_URL} clientId: ${KEYCLOAK_CLIENT_ID} clientSecret: ${KEYCLOAK_CLIENT_SECRET} realm: ${KEYCLOAK_REALM} loginRealm: ${KEYCLOAK_LOGIN_REALM}baseUrl- Enter your RHBK server URL, defined earlier.
clientId- Enter your Developer Hub application client ID in RHBK, defined earlier.
clientSecret- Enter your Developer Hub application client secret in RHBK, defined earlier.
realm- Enter the realm name to provision users.
loginRealm- Enter the realm name to authenticate users.
Optional: Add optional fields to the
keycloackOrgcatalog provider section in yourapp-config.yamlfile:catalog: providers: keycloakOrg: default: baseUrl: ${KEYCLOAK_BASE_URL} clientId: ${KEYCLOAK_CLIENT_ID} clientSecret: ${KEYCLOAK_CLIENT_SECRET} realm: ${KEYCLOAK_REALM} loginRealm: ${KEYCLOAK_LOGIN_REALM} userQuerySize: 100 groupQuerySize: 100 schedule: frequency: { hours: 1 } timeout: { minutes: 50 } initialDelay: { seconds: 15}userQuerySize-
Enter the user count to query simultaneously. Default value:
100. groupQuerySize-
Enter the group count to query simultaneously. Default value:
100. schedulefrequency- Enter the schedule frequency. Supports cron, ISO duration, and "human duration" as used in code.
timeout- Enter the timeout for the user provisioning job. Supports ISO duration and "human duration" as used in code.
initialDelay- Enter the initial delay to wait for before starting the user provisioning job. Supports ISO duration and "human duration" as used in code.
Verification
To verify user and group provisioning, check the console logs.
Successful synchronization example:
2025-06-27T16:02:34.647Z catalog info Read 5 Keycloak users and 3 Keycloak groups in 0.4 seconds. Committing... class="KeycloakOrgEntityProvider" taskId="KeycloakOrgEntityProvider:default:refresh" taskInstanceId="db55c34b-46b3-402b-b12f-2fbc48498e82" trace_id="606f80a9ce00d1c86800718c4522f7c6" span_id="7ebc2a254a546e90" trace_flags="01" 2025-06-27T16:02:34.650Z catalog info Committed 5 Keycloak users and 3 Keycloak groups in 0.0 seconds. class="KeycloakOrgEntityProvider" taskId="KeycloakOrgEntityProvider:default:refresh" taskInstanceId="db55c34b-46b3-402b-b12f-2fbc48498e82" trace_id="606f80a9ce00d1c86800718c4522f7c6" span_id="7ebc2a254a546e90" trace_flags="01"
5.5. Enable authentication with Red Hat Build of Keycloak (RHBK)
Configure Red Hat Build of Keycloak (RHBK) as your Red Hat Developer Hub sign-in provider by enabling the OIDC authentication provider.
Prerequisites
- You have shared a secret with RHBK.
Procedure
The OIDC provider authentication backend plugin requires Developer Hub to support sessions. Enable session support by adding the session secret to your
app-config.yamlfile:auth: session: secret: ${SESSION_SECRET}Enable the RHBK authentication provider, by adding the OIDC provider section in your
app-config.yamlfile:auth: environment: production providers: oidc: production: metadataUrl: ${KEYCLOAK_BASE_URL} clientId: ${KEYCLOAK_CLIENT_ID} clientSecret: ${KEYCLOAK_CLIENT_SECRET} prompt: auto signInPage: oidcenvironment: production-
Mark the environment as
productionto hide the Guest login in the Developer Hub home page. metadataUrl,clientId,clientSecret- Configure the OIDC provider with your secrets.
promptEnter
autoto allow the identity provider to automatically determine whether to prompt for credentials or bypass the login redirect if an active RHBK session exists.The identity provider defaults to
none, which assumes that you are already logged in. Sign-in requests without an active session are rejected.signInPage-
Enter
oidcto enable the OIDC provider as default sign-in provider.
Optional: Add optional fields to the OIDC authentication provider section in your
app-config.yamlfile:auth: providers: oidc: production: metadataUrl: ${KEYCLOAK_BASE_URL} clientId: ${KEYCLOAK_CLIENT_ID} clientSecret: ${KEYCLOAK_CLIENT_SECRET} callbackUrl: ${KEYCLOAK_CALLBACK_URL} tokenEndpointAuthMethod: ${KEYCLOAK_TOKEN_ENDPOINT_METHOD} tokenSignedResponseAlg: ${KEYCLOAK_SIGNED_RESPONSE_ALG} additionalScopes: ${KEYCLOAK_SCOPE} signIn: resolvers: - resolver: oidcSubClaimMatchingKeycloakUserId - resolver: preferredUsernameMatchingUserEntityName - resolver: emailMatchingUserEntityProfileEmail - resolver: emailLocalPartMatchingUserEntityName dangerouslyAllowSignInWithoutUserInCatalog: true sessionDuration: { hours: 24 } backstageTokenExpiration: { minutes: _<user_defined_value>_ } signInPage: oidccallbackUrl- RHBK callback URL.
tokenEndpointAuthMethod- Enter your token endpoint authentication method.
tokenSignedResponseAlg- Token signed response algorithm.
additionalScopes- Enter additional RHBK scopes to request for during the authentication flow.
signInresolversAfter successful authentication, the user signing in must be resolved to an existing user in the Developer Hub catalog. To best match users securely for your use case, consider configuring a specific resolver.
Enter the resolver list to override the default resolver:
oidcSubClaimMatchingKeycloakUserId.Available values:
oidcSubClaimMatchingKeycloakUserId-
Matches the user with the immutable
subparameter from OIDC to the RHBK user ID. Consider using this resolver for enhanced security. emailLocalPartMatchingUserEntityName- Matches the email local part with the user entity name.
emailMatchingUserEntityProfileEmail- Matches the email with the user entity profile email.
preferredUsernameMatchingUserEntityNameMatches the preferred username with the user entity name.
The authentication provider tries each sign-in resolver in order until it succeeds, and fails if none succeed.
WarningIn production mode, configure only one resolver to make sure users are securely matched.
dangerouslyAllowSignInWithoutUserInCatalog: trueConfigure the sign-in resolver to bypass the user provisioning requirement in the Developer Hub software catalog.
WarningIn production mode, do not enable the
dangerouslyAllowSignInWithoutUserInCatalogoption.
sessionDuration-
Lifespan of the user session. Enter a duration in
mslibrary format (such as '24h', '2 days'), ISO duration, or "human duration" as used in code. backstageTokenExpirationEnter a value to modify the Developer Hub token expiration from its default value of one hour. It refers to the validity of short-term cryptographic tokens, not to the session duration. The expiration value must be set between 10 minutes and 24 hours.
WarningIf multiple valid refresh tokens are issued due to frequent refresh token requests, older tokens will remain valid until they expire. Enhance security and prevent potential misuse of older tokens by enabling a refresh token rotation strategy in your RHBK realm.
- From the Configure section of the navigation menu, click Realm Settings.
- From the Realm Settings page, click the Tokens tab.
- From the Refresh tokens section of the Tokens tab, toggle the Revoke Refresh Token to the Enabled position.
To disable the guest login option, in the
app-config.yamlfile, set the authentication environment toproduction:auth: environment: production
Verification
To verify RHBK user authentication:
- Go to the Developer Hub login page.
- Your Developer Hub sign-in page displays Sign in using OIDC and the Guest user sign-in is disabled.
- Log in with OIDC by using the saved Username and Password values.
5.7. Import users and groups from GitHub
Import GitHub users and groups to the Red Hat Developer Hub software catalog.
Prerequisites
- You have shared a secret with GitHub.
Procedure
Enable the GitHub catalog provider plugin in your
dynamic-plugins.yamlfile to import GitHub users and groups to the Developer Hub software catalog.plugins: - package: './dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic' disabled: falseEnable provisioning GitHub users and groups to the Developer Hub software catalog by adding the GitHub catalog provider section to your
app-config.yamlfile:catalog: providers: githubOrg: id: githuborg githubUrl: "${GITHUB_URL}" orgs: [ "${GITHUB_ORG}" ] schedule: frequency: minutes: 30 initialDelay: seconds: 15 timeout: minutes: 15idEnter a stable identifier for this provider, such as
githuborg.WarningEntities from this provider are associated with this identifier. Therefore, do not to change the identifier over time since that might lead to orphaned entities or conflicts.
githubUrl-
Enter the configured secret variable name:
${GITHUB_URL}. orgs-
Enter the configured secret variable name:
${GITHUB_ORG}. schedule.frequency- Enter your schedule frequency, in the cron, ISO duration, or "human duration" format.
schedule.timeout- Enter your schedule timeout, in the ISO duration or "human duration" format.
schedule.initialDelay- Enter your schedule initial delay, in the ISO duration or "human duration" format.
Verification
To verify user and group provisioning, check the console logs.
Successful synchronization example:
{"class":"GithubMultiOrgEntityProvider","level":"info","message":"Reading GitHub users and teams for org: rhdh-dast","plugin":"catalog","service":"backstage","target":"https://github.com","taskId":"GithubMultiOrgEntityProvider:githuborg:refresh","taskInstanceId":"801b3c6c-167f-473b-b43e-e0b4b780c384","timestamp":"2024-09-09 23:55:58"} {"class":"GithubMultiOrgEntityProvider","level":"info","message":"Read 7 GitHub users and 2 GitHub groups in 0.4 seconds. Committing...","plugin":"catalog","service":"backstage","target":"https://github.com","taskId":"GithubMultiOrgEntityProvider:githuborg:refresh","taskInstanceId":"801b3c6c-167f-473b-b43e-e0b4b780c384","timestamp":"2024-09-09 23:55:59"}
5.8. Enable authentication with GitHub
Configure GitHub as your Red Hat Developer Hub sign-in provider.
Prerequisites
- You have shared a secret with GitHub.
Procedure
Enable the GitHub authentication provider, by adding the GitHub authentication provider section to your
app-config.yamlfile:auth: environment: production providers: github: production: clientId: ${GITHUB_CLIENT_ID} clientSecret: ${GITHUB_CLIENT_SECRET} signInPage: githubenvironment-
Enter
productionto disable the Guest login option in the Developer Hub login page. clientId-
Enter the configured secret variable name:
${GITHUB_CLIENT_ID}. clientSecret-
Enter the configured secret variable name:
${GITHUB_CLIENT_SECRET}. signInPage-
Enter
githubto enable the GitHub provider as your Developer Hub sign-in provider.
Optional: Add optional fields to the GitHub authentication provider section in your
app-config.yamlfile:auth: environment: production providers: github: production: clientId: ${GITHUB_CLIENT_ID} clientSecret: ${GITHUB_CLIENT_SECRET} callbackUrl: <your_intermediate_service_url/handler> sessionDuration: { hours: 24 } signIn: resolvers: - resolver: usernameMatchingUserEntityName dangerouslyAllowSignInWithoutUserInCatalog: true signInPage: githubcallbackUrl- Enter the callback URL that GitHub uses when initiating an OAuth flow, such as: <your_intermediate_service_url/handler>. Define it when Developer Hub is not the immediate receiver, such as in cases when you use one OAuth app for many Developer Hub instances.
sessionDuration-
Enter the user session lifespan, in
mslibrary format (such as '24h', '2 days'), ISO duration, or "human duration". signInresolvers- After successful authentication, Developer Hub resolves the user signing in to an existing user in the Developer Hub catalog. Configure a specific resolver to best match users securely for your use case..
Enter the resolver list to override the default resolver:
usernameMatchingUserEntityName.The authentication provider tries each sign-in resolver in order until it succeeds. If none of the attempts succeed, the sign-in fails.
WarningIn production mode, configure only one resolver to make sure users are securely matched.
resolver- Enter the sign-in resolver name. Available resolvers:
-
usernameMatchingUserEntityName -
preferredUsernameMatchingUserEntityName emailMatchingUserEntityProfileEmaildangerouslyAllowSignInWithoutUserInCatalogEnter
trueto configure the sign-in resolver to bypass the user provisioning requirement in the Developer Hub software catalog.WarningIn production more, do not enable
dangerouslyAllowSignInWithoutUserInCatalog.
To disable the guest login option, in the
app-config.yamlfile, set the authentication environment toproduction:auth: environment: production
Verification
To verify GitHub authentication:
- Go to the Developer Hub login page.
- Your Developer Hub sign-in page displays Sign in using GitHub and the Guest user sign-in is disabled.
- Log in with a GitHub account.
5.10. Import users and groups from Microsoft Azure
Import Microsoft Azure users and groups to the Red Hat Developer Hub software catalog.
Prerequisites
- You have shared a secret with Microsoft Azure.
Procedure
Enable the Microsoft Graph catalog provider plugin in your
dynamic-plugins.yamlfile. This plugin imports Azure users and groups to the Developer Hub software catalog.plugins: - package: './dynamic-plugins/dist/backstage-plugin-catalog-backend-module-msgraph-dynamic' disabled: falseEnable provisioning Azure users and groups to the Developer Hub software catalog, by adding the Microsoft Graph catalog provider section in your
app-config.yamlfile:catalog: providers: microsoftGraphOrg: providerId: target: https://graph.microsoft.com/v1.0 tenantId: ${MICROSOFT_TENANT_ID} clientId: ${MICROSOFT_CLIENT_ID} clientSecret: ${MICROSOFT_CLIENT_SECRET} schedule: frequency: hours: 1 timeout: minutes: 50 initialDelay: minutes: 50target-
Enter
https://graph.microsoft.com/v1.0to define the MSGraph API endpoint the provider is connecting to. You might change this parameter to use a different version, such as the beta endpoint. tenandId-
Enter the configured secret variable name:
${MICROSOFT_TENANT_ID}. clientId-
Enter the configured secret variable name:
${MICROSOFT_CLIENT_ID}. clientSecret-
Enter the configured secret variable name:
${MICROSOFT_CLIENT_SECRET}. schedulefrequency- Enter the schedule frequency in the cron, ISO duration, or human duration format. In a large organization, user provisioning might take a long time, therefore avoid using a low value.
timeout- Enter the schedule timeout in the ISO duration or human duration format. In a large organization, user provisioning might take a long time, therefore avoid using a low value.
initialDelay- Enter the schedule initial delay in the ISO duration or human duration format.
Optional: Add optional fields to the Microsoft authentication provider section in your
app-config.yamlfile:catalog: providers: microsoftGraphOrg: providerId: authority: https://login.microsoftonline.com/ queryMode: advanced user: expand: manager filter: accountEnabled eq true and userType eq 'member' loadPhotos: true select: ['id', 'displayName', 'description'] userGroupMember: filter: "displayName eq 'Backstage Users'" search: '"description:One" AND ("displayName:Video" OR "displayName:Drive")' group: expand: member filter: securityEnabled eq false and mailEnabled eq true and groupTypes/any(c:c+eq+'Unified') search: '"description:One" AND ("displayName:Video" OR "displayName:Drive")' select: ['id', 'displayName', 'description']authority-
Enter your Azure authority URL if it is different from the default:
https://login.microsoftonline.com. queryMode-
Enter
advancedwhen the defaultbasicquery mode is insufficient for your queries to the Microsoft Graph API. See Microsoft Azure advanced queries. userAdd this section to configure optional user query parameters.
expandEnter your expansion parameter to include the expanded resource or collection referenced by a single relationship (navigation property) in your results. A single request can expand only one relationship. See Microsoft Graph query expand parameter.
You can combine this parameter with
userGroupMember.filteroruser.filter.filterEnter your user filter. See Microsoft Graph API and Microsoft Graph API query filter parameters syntax.
This parameter and
userGroupMember.filterare mutually exclusive, specify only one.loadPhotos-
Developer Hub loads photos by default. Enter
falseto avoid loading user photos. select- Enter the Microsoft Graph resource type list to retrieve.
userGroupMemberAdd this section to use group membership to get users.
filterEnter your filter to filter groups and fetch their members.
This parameter and
user.filterare mutually exclusive, specify only one.searchEnter your search query to search for groups and fetch their members.
This parameter and
user.filterare mutually exclusive, specify only one.
groupEnter your configuration to get groups.
expandEnter your expansion parameter to include the expanded resource or collection referenced by a single relationship (navigation property) in your results. A single request can expand only one relationship. See Customize Microsoft Graph responses with query parameters.
You can combine this parameter with
user.filteroruserGroupMember.filter.filter- Enter your group filter parameter. See Microsoft Graph API query group syntax.
search- Enter your group search parameter. See Microsoft Graph API query search parameter.
select- Enter the Microsoft Graph resource type list to retrieve.
Verification
To verify user and group provisioning, check the console logs for
MicrosoftGraphOrgEntityProviderevents.Successful synchronization example:
2025-06-23T13:37:55.804Z catalog info Read 9 msgraph users and 3 msgraph groups in 1.5 seconds. Committing... class="MicrosoftGraphOrgEntityProvider" taskId="MicrosoftGraphOrgEntityProvider:providerId:refresh" taskInstanceId="e104a116-6481-4ceb-9bc4-0f8f9581f959" trace_id="e4c633659cffd6b1529afa55a5bfbad7" span_id="76affd0420e8baa6" trace_flags="01" 2025-06-23T13:37:55.811Z catalog info Committed 9 msgraph users and 3 msgraph groups in 0.0 seconds. class="MicrosoftGraphOrgEntityProvider" taskId="MicrosoftGraphOrgEntityProvider:providerId:refresh" taskInstanceId="e104a116-6481-4ceb-9bc4-0f8f9581f959" trace_id="e4c633659cffd6b1529afa55a5bfbad7" span_id="76affd0420e8baa6" trace_flags="01"
5.11. Enable authentication with Microsoft Azure
Configure Microsoft Azure as your Red Hat Developer Hub sign-in provider.
Prerequisites
- You have shared a secret with Microsoft Azure.
Procedure
Enable Azure authentication, by adding the Microsoft authentication provider to your
app-config.yamlfile content:auth: environment: production providers: microsoft: production: clientId: ${MICROSOFT_CLIENT_ID} clientSecret: ${MICROSOFT_CLIENT_SECRET} tenantId: ${MICROSOFT_TENANT_ID} signInPage: microsoftenvironment-
Enter
productionto disable the Guest login option in the Developer Hub login page. clientId-
Enter the configured secret variable name:
${MICROSOFT_CLIENT_ID}. clientSecret-
Enter the configured secret variable name:
${MICROSOFT_CLIENT_SECRET}. tenantId-
Enter the configured secret variable name:
${MICROSOFT_TENANT_ID}. signInPage-
Enter
microsoftto set the Azure provider as your Developer Hub sign-in provider.
Optional: Add optional fields to the Microsoft authentication provider section in your
app-config.yamlfile:auth: environment: production providers: microsoft: production: clientId: ${MICROSOFT_CLIENT_ID} clientSecret: ${MICROSOFT_CLIENT_SECRET} tenantId: ${MICROSOFT_TENANT_ID} domainHint: ${MICROSOFT_TENANT_ID} additionalScopes: - Mail.Send sessionDuration: hours: 24 signIn: resolvers: - resolver: usernameMatchingUserEntityName dangerouslyAllowSignInWithoutUserInCatalog: true signInPage: microsoftdomainHint
- Leave this parameter empty, or enter the tenant ID when your application registration is single-tenant.
- Leave this parameter empty when your application registration is multitenant.
Enter the tenant ID to reduce login friction for users with accounts in multiple tenants, by automatically filtering out accounts from other tenants.
For more information, see Home Realm Discovery.
additionalScopes- Enter the list of additional scopes to add scopes for the application registration. The default and mandatory value lists following scopes:
-
openid -
offline_access -
profile -
email User.ReadsessionDuration-
Lifespan of the user session. Enter a duration in
mslibrary (such as '24h', '2 days'), ISO duration, or "human duration" format. signIn.resolversAfter successful authentication, Developer Hub resolves the user signing in to an existing user in the Developer Hub catalog. To best match users securely for your use case, consider configuring a specific resolver.
Enter the resolver list to override the default resolver:
userIdMatchingUserEntityAnnotation.The authentication provider tries each sign-in resolver in order until it succeeds, and fails if none succeed.
WarningIn production mode, configure only one resolver to make sure users are securely matched.
resolverEnter the sign-in resolver name. Available resolvers:
emailMatchingUserEntityAnnotation- Use this resolver to look up the user by matching their Microsoft email to the email entity annotation.
emailLocalPartMatchingUserEntityName- Use this resolver to look up the user by matching their Microsoft email user name to the user entity name.
emailMatchingUserEntityProfileEmail- Use this resolver to look up the user by matching their Microsoft email to the user entity profile email.
dangerouslyAllowSignInWithoutUserInCatalogEnter
trueto configure the sign-in resolver to bypass the user provisioning requirement in the Developer Hub software catalog.WarningIn production mode, do not enable
dangerouslyAllowSignInWithoutUserInCatalog.
To disable the guest login option, in the
app-config.yamlfile, set the authentication environment toproduction:auth: environment: production
Verification
To verify Azure user authentication:
- Go to the Developer Hub login page.
- Your Developer Hub sign-in page displays Sign in using Microsoft and the Guest user sign-in is disabled.
- Log in with an Azure account.
6. Use the Red Hat Developer Hub Operator to run Developer Hub with your custom configuration
Use the Developer Hub Operator to run Red Hat Developer Hub with your custom configuration by creating a Backstage custom resource (CR).
The custom resource can mount files from your custom config maps and inject environment variables from your custom secrets.
Prerequisites
-
By using the OpenShift CLI (
oc), you have access, with developer permissions, to the OpenShift Container Platform cluster aimed at containing your Developer Hub instance. - Section 2, “Install the Red Hat Developer Hub Operator”
- Section 4, “Provision your custom Red Hat Developer Hub configuration”
Procedure
Author your Backstage CR in a
my-rhdh-custom-resource.yamlfile to use your custom config maps and secrets.my-rhdh-custom-resource.yamlcustom resource example with dynamic plugins and RBAC policies config maps, and external PostgreSQL database secrets.apiVersion: rhdh.redhat.com/v1alpha5 kind: Backstage metadata: name: <my-rhdh-custom-resource> spec: application: appConfig: mountPath: /opt/app-root/src configMaps: - name: my-rhdh-app-config - name: rbac-policies dynamicPluginsConfigMapName: dynamic-plugins-rhdh extraEnvs: envs: - name: HTTP_PROXY value: 'http://10.10.10.105:3128' - name: HTTPS_PROXY value: 'http://10.10.10.106:3128' - name: NO_PROXY value: 'localhost,example.org' secrets: - name: my-rhdh-secrets extraFiles: mountPath: /opt/app-root/src secrets: - name: my-rhdh-database-certificates-secrets key: postgres-crt.pem, postgres-ca.pem, postgres-key.key replicas: 2 database: enableLocalDb: falseapplicationappConfig-
Register your
my-rhdh-app-configandrbac-policiesconfig maps. dynamicPluginsConfigMapName-
Register your
dynamic-plugins-rhdhconfig map. extraEnvsenv- Enter your proxy environment variables.
secrets-
Register your
<my_product_secrets>andmy-rhdh-database-secretssecrets.
extraFilessecrets-
Register the
postgres-crt.pem,postgres-ca.pem, andpostgres-key.keyfiles contained in themy-rhdh-database-certificates-secretssecret.
replicas- Enable high availability (HA) by increasing the replicas count to a value higher or equal to 2.
databaseenableLocalDb- Use your external PostgreSQL database rather than the internal PostgreSQL database.
Apply your Backstage CR to start or update your Developer Hub instance.
$ oc apply --filename=my-rhdh-custom-resource.yaml --namespace=my-rhdh-project
7. Switch the theme mode for your Developer Hub instance
You can switch the RHDH interface between light, dark, or auto mode (which matches your system preference).
In RHDH, theme configurations are used to change the look and feel of different UI components. So, you might notice changes in different UI components, such as buttons, tabs, sidebars, cards, and tables along with some changes in background color and font used on the RHDH pages.
Prerequisites
- You are logged in to the RHDH web console.
Procedure
- From the Developer Hub web console, click Settings.
From the Appearance panel, select Light, Dark, or Auto to change the theme mode.

Verification
- The interface immediately updates to reflect the selected theme.
8. Manage role-based access controls (RBAC) using the Red Hat Developer Hub Web UI
Use the Developer Hub Web UI to create, modify, and delete roles and assign permissions to users and groups.
Policy administrators can use the Developer Hub web interface (Web UI) to assign specific roles and permissions to individual users or groups. Assigning roles ensures that access to resources and functionalities is regulated across the Developer Hub.
With the policy administrator role in Developer Hub, you can assign permissions to users and groups. This role allows you to view, create, change, and delete the roles by using the Developer Hub Web UI.
8.1. Create a role in the Red Hat Developer Hub Web UI
Create a role in Developer Hub by using the Web UI to define permissions, users, and groups.
You can create a role in the Red Hat Developer Hub using the Web UI.
Prerequisites
Procedure
Go to Administration at the bottom of the sidebar in the Developer Hub.
The RBAC tab is displayed, showing 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 is displayed in the list available in the RBAC tab.
8.2. Edit a role in the Red Hat Developer Hub Web UI
Edit a role in Developer Hub by using the Web UI to change role details, users, groups, and permission policies.
You can edit a role in the Red Hat Developer Hub using the Web UI.
The policies generated from a policy.csv or ConfigMap file cannot be edited or deleted using the Developer Hub Web UI.
Prerequisites
- You have enabled RBAC, have a policy administrator role in Developer Hub, and have added plugins with permission.
- The role that you want to edit is created in the Developer Hub.
Procedure
Go to Administration at the bottom of the sidebar in the Developer Hub.
The RBAC tab is displayed, showing 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.
Verification
- After saving the changes, you can view the edited details of the role on the OVERVIEW page of the role.
- You can also edit a role’s users and groups or permissions by using the edit icon on the Users and Groups or Permissions cards on the OVERVIEW page.
8.3. Delete a role in the Red Hat Developer Hub Web UI
Delete a role in Developer Hub by using the Web UI to remove roles that are no longer needed.
You can delete a role in the Red Hat Developer Hub using the Web UI.
The policies generated from a policy.csv or ConfigMap file cannot be edited or deleted using the Developer Hub Web UI.
Prerequisites
- You have enabled RBAC and have a policy administrator role in Developer Hub.
- The role that you want to delete is created in the Developer Hub.
Procedure
Go to Administration at the bottom of the sidebar in the Developer Hub.
The RBAC tab is displayed, showing 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.
The Delete this role? pop-up is displayed on the screen.
- Click DELETE.