Release notes for Red Hat Developer Hub 1.2

Red Hat Developer Hub (Developer Hub) 1.2 is now generally available. Developer Hub is a fully supported, enterprise-grade productized version of upstream Backstage v1.26.5. You can access and download the Red Hat Developer Hub application from the Red Hat Customer Portal or from the Ecosystem Catalog.

Red Hat Developer Hub support

If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal. You can use the Red Hat Customer Portal for the following purposes:

To search or browse through the Red Hat Knowledgebase of technical support articles about Red Hat products.
To create a support case for Red Hat Global Support Services (GSS). For support case creation, select Red Hat Developer Hub as the product and select the appropriate product version.

1. About this release

The release notes provide high-level coverage of the features that have been implemented in Red Hat Developer Hub 1.2 and document known issues in this release.

Some features within this release may be available as a Technology Preview, providing access to upcoming product features, enabling customers to test functionality and to provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, read Technology Preview Support Scope.

Benefits of Red Hat Developer Hub include:

Increased developer productivity: Increases productivity by eliminating common organizational challenges, enabling seamless collaboration, and providing clear guidelines for creating, developing, and deploying applications.
Unified self-service dashboard: Provides development teams with a unified dashboard covering various aspects such as Git, CI/CD, SAST/DAST, Supply Chain, OpenShift/Kubernetes cluster, JIRA, monitoring, API, documentation, and more, facilitated by over 150 plugins. All curated by a platform engineering team, aligning with the company’s best practices.
Best practices through software templates: Automates organizational best practices by encoding common tasks such as creating new applications, running Ansible jobs, and establishing CI/CD pipelines for production deployment in Git.
Scalable technical documentation: Code and documentation resides in the same repository, eliminating dependencies on proprietary document systems.
Efficient onboarding for new developers: New developers quickly adapt and become productive within a short timeframe.
Robust enterprise Role-Based Access Control (RBAC): Empowers administrators to create roles, assign users or groups to roles, and implement robust security policies for enhanced access control.

2. New features

This section highlights new features in Red Hat Developer Hub 1.2.

2.1. Backstage version update

Red Hat Developer Hub is now based on the upstream Backstage project v1.26.5.

2.2. Telemetry

With this update, you can use the telemetry data collection feature, which is enabled by default. Analyzing the collected data helps in improving your experience with Red Hat Developer Hub. You can disable this feature based on your needs. For more information, see the Disabling telemetry data collection in RHDH section.

2.3. Audit logging

Administrators can view details about application changes, including the name and role of the user who made the change and the time that the change was made. Audit log data is captured by the RBAC plugin and scaffolder actions by default.

Administrators can now use the audit logs to view changes to the catalog database. Tracking changes that add, remove, or update data in the catalog database helps ensure the accountability and transparency of actions.

2.4. RBAC conditional policies

You can now use RBAC conditional policies in Red Hat Developer Hub, enabling access control based on dynamic conditions. These conditions act as content filters for Developer Hub resources that are managed by the RBAC plugin.

You can specify the conditional policies for the Keycloak and Quay Actions plugins. Also, you must consider reviewing your security needs for components that do not have RBAC controls.

For more information, see Role-Based Access Control (RBAC) in Red Hat Developer Hub.

2.5. RBAC permissions for OCM and Topology plugins

Basic permissions for OCM and Topology plugins are now added to the Red Hat Developer Hub. You must consider reviewing your security needs for components that do not have RBAC controls.

2.6. Support for corporate proxy

With this update, you can run the RHDH application behind a corporate proxy by setting the HTTP_PROXY or HTTPS_PROXY environment variable. Also, you can set the NO_PROXY environment variable to exclude certain domains from proxying. For more information, see the Running the RHDH application behind a corporate proxy section.

2.7. Support for external PostgreSQL databases

With this update, you can configure and use external PostgreSQL databases in Red Hat Developer Hub. Based on your needs, you can use a PostgreSQL certificate file to configure an external PostgreSQL instance using the Operator or Helm Chart. For more information, see the Configuring external PostgreSQL databases section.

You can configure an RHDH instance with a Transport Layer Security (TLS) connection in a Kubernetes cluster, such as an Azure Red Hat OpenShift (ARO) cluster, any cluster from a supported cloud provider, or your own cluster with proper configuration. For more information, see the Configuring an RHDH instance with a TLS connection in Kubernetes.

2.8. New plugins included in Red Hat Developer Hub 1.2

The following additional plugins are included in Red Hat Developer Hub 1.2:

HTTP Request action - @roadiehq/scaffolder-backend-module-http-request
Microsoft Azure repository actions for the scaffolder-backend - @parfuemerie-douglas/scaffolder-backend-module-azure-repositories
Catalog backend module for GitLab organizational data - @backstage/plugin-catalog-backend-module-gitlab-org
Catalog backend module for scaffolder relation catalog processor - @janus-idp/backstage-plugin-catalog-backend-module-scaffolder-relation-processor
A second ArgoCD frontend plugin - @janus-idp/backstage-plugin-argocd

For a comprehensive list of supported dynamic plugins, see the Preinstalled dynamic plugins.

2.9. Theme updates in Red Hat Developer Hub

With this update, theme configurations are enhanced to change the look and feel of different UI components so that they almost resemble the theme that is usually used in designing Red Hat applications. You might notice changes in UI components, such as buttons, tabs, sidebars, cards, and tables along with some changes in background color and font used on the RHDH pages.

You can update the app-config.yaml file to change the look of multiple Developer Hub theme components for enhanced customization.

2.10. `scaffolderFieldExtensions` configuration option

You can now use the scaffolderFieldExtensions configuration option in a dynamic plugin’s front-end configuration. The scaffolderFieldExtensions option allows a dynamic plugin to specify one or more exported components to be provided to the scaffolder plugin as field extensions. These scaffolder field extensions provide custom form field components for the software template wizard.

2.11. Enhancement to ConfigMap or Secret configuration

In previous versions, updating ConfigMaps or Secrets specified in Backstage.spec.Application required recreating the Pod to apply changes. Beginning with version 1.2, this process is automated.

2.12. Ability to configure learning paths

You can now configure Learning Paths in Developer Hub to create a dynamic experience tailored to your specific learning needs.

2.13. Plugin version upgrades in Red Hat Developer Hub 1.2.2

In Red Hat Developer Hub 1.2.2, the following plugin versions are upgraded as follows:

Plugin	Version in 1.2.0	Version in 1.2.2
`@janus-idp/backstage-plugin-3scale-backend`	1.5.13	1.5.15
`@janus-idp/backstage-plugin-aap-backend`	1.6.13	1.6.15
`@janus-idp/backstage-plugin-acr`	1.4.11	1.4.13
`@janus-idp/backstage-plugin-analytics-provider-segment`	1.4.7	1.4.9
`@janus-idp/backstage-plugin-argocd`	1.1.6	1.2.3
`@janus-idp/backstage-plugin-jfrog-artifactory`	1.4.9	1.4.11
`@janus-idp/backstage-plugin-keycloak-backend`	1.9.10	1.9.12
`@janus-idp/backstage-plugin-nexus-repository-manager`	1.6.8	1.6.10
`@janus-idp/backstage-plugin-ocm`	4.1.6	4.1.8
`@janus-idp/backstage-plugin-ocm-backend`	4.0.6	4.0.8
`@janus-idp/backstage-plugin-quay`	1.7.6	1.7.8
`@janus-idp/backstage-scaffolder-backend-module-quay`	1.4.10	1.4.12
`@janus-idp/backstage-plugin-rbac`	1.20.11	1.23.2
`@janus-idp/backstage-scaffolder-backend-module-regex`	1.4.10	1.4.12
`@janus-idp/backstage-plugin-catalog-backend-module-scaffolder-relation-processor`	1.0.1	1.0.3
`@janus-idp/backstage-scaffolder-backend-module-servicenow`	1.4.12	1.4.14
`@janus-idp/backstage-scaffolder-backend-module-sonarqube`	1.4.10	1.4.12
`@janus-idp/backstage-plugin-tekton`	3.7.5	3.7.7
`@janus-idp/backstage-plugin-topology`	1.21.7	1.21.10
`@janus-idp/backstage-plugin-rbac`	1.23.2	1.24.1

3. Breaking changes

This section lists breaking changes with Red Hat Developer Hub 1.2:

3.1. Guest authentication must now be explicitly enabled

In previous versions of Red Hat Developer Hub, guest authentication was enabled by default. As of Developer Hub 1.2, guest authentication is disabled by default and needs to be explicitly enabled for use.

The guest login is provided by a special authentication provider that must be explicitly enabled. This authentication provider should be used for development purposes only and is not intended for production, as it creates a default user that has user-level access to the Developer Hub instance.

You can enable the guest authentication provider in your app-config-rhdh ConfigMap as follows:
```
auth:
  providers:
    guest:
      dangerouslyAllowOutsideDevelopment: true
```

3.2. Improved validation permission policies from different sources

In this release, Developer Hub provides more strict validation on the source of permission policies and roles based on how you define the first role.

This update improves the validation of the different sources of permission policies and roles and provides more consistent policy definition. If a permission policy or role with a new member does not match the originating role’s source, Developer Hub prevents any update to permissions. Sources include 'REST, 'CSV', 'Configuration', and 'legacy'.

Before updating your Red Hat Developer Hub application, you should migrate all permission policies and roles to a single source based on their respective roles. This can be done by using the GET roles endpoint to review the source information and by querying the role-metadata table of the permission database. You can make updates to permission policies by using one of the following: REST API, CSV file, and the database.

4. Technology preview

This section lists features that are in Technology Preview in Red Hat Developer Hub 1.2.

Important

These features are for Technology Preview only. 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.

4.1. Plugins available in Red Hat Developer Hub

Red Hat Developer Hub incorporates various dynamic plugins. Red Hat fully supports certain plugins, while others are community-supported projects. Some plugins are enabled by default, while others require configuration and are consequently disabled by default.

To get a comprehensive list of supported dynamic plugins, see the Preinstalled dynamic plugins section in the Configuring plugins in Red Hat Developer Hub guide.

5. Known issues

This section lists known issues with Red Hat Developer Hub 1.2:

Deprecation warning: The backend.auth.keys config has been replaced by backend.auth.externalAccess

Due to changes to the backend service-to-service authentication, you will see a deprecation warning if you have set up your deployment to use the backend.auth.keys field configured in upstream.backstage.appConfig This warning is harmless for now and no action is needed.

IP addresses may appear in application logs

If you deploy Developer Hub without a proxy, there is the potential for IP addresses to appear in the audit logs. If your organization’s security policies restrict you from retaining IP addresses, you can take one or both of the following actions:

Delete the IP addresses after they are collected.
Prevent collection of IP addresses by configuring a reverse proxy in front of Developer Hub.

Missing items in catalog or software templates after upgrade to Developer Hub 1.2

After upgrading to Developer Hub 1.2, user policies are not automatically migrated or updated, resulting in items not appearing in the catalog or software templates.

To resolve this issue, after upgrading to version 1.2, users need to add the necessary policies in the Developer Hub RBAC system page.

Rollbacks are not supported

If you deploy Developer Hub using either Helm or the Operator, rollbacks to earlier versions are not supported. Performing regular backups of your Developer Hub PostgreSQL database helps you to restore the application to a recent state in case of issues. In future versions of Developer Hub, we plan to provide guidance on how to perform rollbacks from existing backups.

6. Fixed issues in Red Hat Developer Hub 1.2 and 1.2.2

6.1. Fixed issues in Red Hat Developer Hub 1.2.2

This section lists fixed issues with Red Hat Developer Hub 1.2.2:

Dynamic plugins fail to load if the file name in ConfigMap is invalid: Previously, an invalid dynamic plugin file name in ConfigMap prevented the creation of a Backstage CR. With this release, the Backstage CR can be created even with an invalid plugin file name, and a corresponding log message will be displayed if the Developer Hub build fails.
Plugin ID is missing in the permission table in RBAC Administration UI: Previously, plugin IDs were missing from the permission table in UI accessed from Administration → RBAC. With this release, updates to both the RBAC backend and frontend plugins now ensure that plugin IDs are displayed in the table.
Git information for Helm chart-based workflows is no longer shown in the ArgoCD plugin UI: Previously, the ArgoCD plugin UI displayed Git information for all workflows, including those that were not based on Git. With this release, the ArgoCD plugin UI now only displays Git information for workflows where it is relevant, ensuring that only pertinent information is shown.

6.2. Fixed issues in Red Hat Developer Hub 1.2

This section lists fixed issues with Red Hat Developer Hub 1.2:

Dynamic plugins fail to load after update to Backstage 1.25: An upstream security fix introduced in Backstage 1.25 required authentication tokens for all backend endpoints, including static assets used by dynamic plugins.

As a result of this fix, users could not access dynamic plugin UI elements, leading to a degraded user experience and decreased functionality within the application.

In this release, the security requirement for dynamic plugin static assets has been removed, which restores access to dynamic plugin UI elements.

With this fix, users can view and interact with dynamic plugin UI elements, resulting in improved usability and functionality within the application.
API throwing error upon adding conditions for scaffolder-action resource-type: In earlier versions of Red Hat Developer Hub, defining conditional policies with a policy action of use would result in an error.

This issue led to difficulties in defining conditional policies, hindering the configuration of permissions within the application.

With this fix, you can now define conditional policies in Developer Hub with permission policy actions of use.
Setting a custom route not working when using the Developer Hub Operator on OpenShift: In earlier versions of the Red Hat Developer Hub Operator, setting a custom Route host on OpenShift Container Platform by using the spec.application.route.host field in the Custom Resource was not possible.

This limitation prevented users from configuring custom route hosts, limiting their ability to customize the deployment environment.

With this release, you can now set a custom route host on OpenShift Container Platform by using the specified field in the Custom Resource.
Mounting a secret/configmap with a '.' in its name: In earlier versions of the Red Hat Developer Hub Operator, it was not possible to reference a ConfigMap or Secret object in the Custom Resource if that object contained a dot (.) character in its name.

This issue prevented the Red Hat Developer Hub instance from starting correctly.

With this update, this issue is fixed.
Upgrading Developer Hub Operator from 1.1 to 1.2 causes an existing instance to use a new empty database: When upgrading the Red Hat Developer Hub Operator from version 1.1 to 1.2 with an already-running operator-backed instance of Developer Hub, the instance was configured to use a new empty local database pod and volume.

The existing database data was retained but this misconfiguration caused the existing Developer Hub instance to use a new empty local database pod and volume, resulting in data redundancy and potential data inconsistency issues.

This update ensures that an existing Developer Hub instance continues to use the existing local database when the Operator is upgraded to a newer version.
UI pod stays 'Pending' when using the operator: In earlier versions of Red Hat Developer Hub, the Developer Hub pod created by the (product-short) Operator may not be scheduled on some clusters due to missing resource requests.

This issue resulted in the Developer Hub application being unavailable as the pods could not be scheduled properly.

This update adds CPU and memory requests to the default configuration of the Operator, ensuring that Developer Hub pods have the necessary resource requests specified.

With this fix, Developer Hub pods can now be scheduled and started properly on all clusters, ensuring the availability of the Red Hat Developer Hub application.
Allow specifying image pull secrets in custom resource for the database: In earlier versions of the Red Hat Developer Hub operator, specifying image pull secrets to pull container images from repositories such as registry.redhat.io did not affect the database image. This limitation prevented the use of a database image from registry.redhat.io` when deploying Developer Hub in Kubernetes clusters like Amazon EKS or Azure AKS.

As a result, users were unable to deploy the database image from registry.redhat.io in Kubernetes clusters, limiting deployment flexibility and compatibility.

This update fixes the issue by propagating the image pull secrets specified in the spec.application.imagePullSecrets Custom Resource field. You can now use these secrets can for both the Developer Hub and database images.

With this fix, users can successfully use image pull secrets for both the Developer Hub and database images, allowing deployments from repositories such as registry.redhat.io in Kubernetes clusters like Amazon EKS or Azure AKS. This ensures greater deployment flexibility and compatibility across different environments.
RBAC tab is visible when RBAC plugin is disabled: In earlier versions of Red Hat Developer Hub When the Role-Based Access Control (RBAC) plugin is disabled, the RBAC tab remained visible bwhen the RBAC plugin was disabled.

This update ensures that the RBAC tab is hidden when the RBAC plugin is disabled.

With this fix, the RBAC tab is no longer visible when the RBAC plugin is disabled, resulting in a cleaner and more intuitive user interface.
Show configure access button for previously created simple permission policies in edit form: In previous versions, when a user creates simple permission policies and later returns to edit the role, the Configure Access button does not appear.

As a result, the user cannot add conditional permission policies to roles that were created with simple permission policies, limiting the ability to update and refine access controls.

In this release, the role form has been updated to display the Configure Access button for previously created simple permission policies for plugins and resource types that support conditions. This fix allows users to add and save new conditional policies.
Conflicting Condition Action Sets: In previous versions, the Condition API allowed storing multiple conditions with conflicting action sets.

This issue could lead to inconsistencies and conflicts in permission handling, potentially causing unexpected behavior in the application.

In this release, the Condition API has been updated to prevent storing multiple conditions with conflicting action sets.
RBAC backend admin metadata and policies removal: Previously, when admins were removed from the configuration, their associated admin metadata and policies were not automatically removed.

This issue caused outdated admin metadata and policies to persist in the application.

In this release, admin metadata and policies are removed when admins are removed from the application configuration.
Existing Backstage operand not upgraded after upgrading operator from 1.1.x to 1.2.x: In previous versions, there was an issue with the Developer Hub Operator upgrade process that prevented operator-backed Developer Hub instances from upgrading seamlessly when the Developer Hub Operator itself was upgraded. This occurred because the Operator, when trying to reconcile existing Developer Hub custom resources, was denied patching certain fields that are restricted or read-only by Kubernetes or OpenShift Container Platform.

This issue led to a failure in reaching the desired state during the upgrade.

In this update, the Operator has been refactored to overcome these issues by replacing objects forcibly when it is unable to patch them. However, as a known issue, users might need to re-create any custom labels or annotations on the underlying resources managed by the Developer Hub Operator after the upgrade.
Failed to List Cluster Resources in Janus IDP Backstage Plugin OCM Backend Dynamic: In previous versions, the OpenShift Cluster Manager (OCM) Plugin Readme file had no information on how to configure OCM on a Kubernetes cluster.

Due to this missing information, users were unable to configure the OCM plugin to fetch clusters, resulting in the plugin’s inability to display clusters.

In this release, the Readme file has been updated to include a link for configuring OCM on a Kubernetes cluster and also provides instructions to enable access to the OCM backend plugin when the RBAC permission framework is enabled.

With these updates, users can now properly configure the OCM plugin to fetch and display clusters in the OCM front-end, ensuring the plugin operates as intended.
RBAC: Could not fetch catalog entities. Request failed with 403 Forbidden.: Recent updates to Backstage required plugins that use service-to-service authentication to be updated to use the new httpAuth and auth services.

Without these updates, the RBAC Backend plugin was unable to query information from other plugins. This update modifies the RBAC Backend plugin to use the new httpAuth and auth services for service-to-service authentication.

With this fix, the RBAC Backend plugin can now successfully query information from other plugins without breaking.
RBAC role data out-of-sync when scaling horizontally: When scaling a Developer Hub instance, role data would become out of sync due to the in-memory cache not being shared between instances.

This issue resulted in inconsistencies in role data across different instances.

With this fix, scaling a Developer Hub instance will no longer lead to role data being out of sync.
Gitlab organization synchronization not working: Recent updates to the Gitlab plugin resulted in the failure to synchronize organization provider data.

In this release, the issue is fixed by including a wrapper for the Gitlab plugin that exposes the Gitlab organization provider.
Helm deployment shows empty white screen and 404 errors loading static content: A recent change to the upstream Helm chart accidentally prevented deployment of static resources.

With the release of the Developer Hub 1.2.1 Helm chart, this is fixed.

6.3. Fixed security issues

6.3.1. Fixed security issues in Red Hat Developer Hub 1.2.3

This section lists fixed security issues with Red Hat Developer Hub 1.2.3:

CVE-2024-41818: A regular expression denial of service (ReDoS) flaw was found in fast-xml-parser in the currency.js script. By sending a specially crafted regex input, a remote attacker could cause a denial of service condition. This vulnerability is fixed in 4.4.1.
CVE-2024-37891: A flaw was found in urllib3, an HTTP client library for Python. In certain configurations, urllib3 does not treat the Proxy-Authorization HTTP header as one carrying authentication material. This issue results in not stripping the header on cross-origin redirects. This vulnerability is fixed in 2.2.2.
CVE-2024-39338: Axios 1.7.2 allows SSRF via unexpected behavior where requests for path relative URLs get processed as protocol relative URLs. This vulnerability is fixed in 1.7.4.

6.3.2. Fixed security issues in Red Hat Developer Hub 1.2.2

This section lists fixed security issues with Red Hat Developer Hub 1.2.2:

CVE-2024-28863: A flaw was found in ISAACS’s node-tar, where it is vulnerable to a denial of service, caused by the lack of folder count validation. The vulnerability exists due to the application not properly controlling the consumption of internal resources while parsing a .tar file. By sending a specially crafted request, a remote attacker can trigger resource exhaustion and perform a denial of service (DoS) attack.

6.3.3. Fixed security issues in Red Hat Developer Hub 1.2

This section lists fixed security issues with Red Hat Developer Hub 1.2:

CVE-2023-6597: A flaw was found in the tempfile.TemporaryDirectory class in python3/cpython3. The class may dereference symbolic links during permission-related errors, resulting in users that run privileged programs being able to modify permissions of files referenced by the symbolic link.
CVE-2024-0450: A flaw was found in the Python/CPython 'zipfile' that can allow a zip-bomb type of attack. An attacker may craft a zip file format, leading to a Denial of Service when processed.
CVE-2024-35195: An incorrect control flow implementation vulnerability was found in Requests. If the first request in a session is made with verify=False, all subsequent requests to the same host ignore cert verification.
CVE-2024-27307: A vulnerability was found that could exploit the JSONata transform operator to override properties on the Object constructor and prototype. This could result in denial of service, remote code execution, or other unforeseen behavior in applications that assess user-provided JSONata expressions.
CVE-2024-34064: A flaw was found in jinja2. The xmlattr filter accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, /, >, or =, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could inject other attributes and perform cross-site scripting (XSS).
CVE-2023-45288: A vulnerability was discovered with the implementation of the HTTP/2 protocol in the Go programming language. There were insufficient limitations on the amount of CONTINUATION frames sent within a single stream. An attacker could potentially exploit this to cause a Denial of Service (DoS) attack.
CVE-2024-27316: A vulnerability was found in how Apache httpd implements the HTTP/2 protocol. There are insufficient limitations placed on the amount of CONTINUATION frames that can be sent within a single stream. This issue could allow an unauthenticated remote attacker to send packets to vulnerable servers, which could use up memory resources to cause a DoS.