Installing Red Hat Trusted Application Pipeline


Red Hat Trusted Application Pipeline 1.5

Learn how to install Red Hat Trusted Application Pipeline in your cluster.

Red Hat Customer Content Services

Abstract

This document provides information about how to install Red Hat Trusted Application Pipeline in your cluster.

Preface

Red Hat Trusted Application Pipeline (RHTAP) is not really a single product. Instead, it is a set of products that combine to form a highly automated, customizable, and secure platform for building applications.

By default, RHTAP includes the following products:

You can see exactly which versions of these products RHTAP supports in the compatibility and support matrix of our Release notes.

Note

Red Hat Trusted Application Pipeline supports many alternatives to this default combination of products. Later in the installation process, this documentation explains how to customize your deployment to meet your needs.

Because a fully-operational instance of RHTAP involves all of the products listed above, installing RHTAP takes some effort. However, we have automated the vast majority of this process with an installer tool packaged as a container image.

Be aware that the RHTAP installer is not a manager: it does not support upgrades. The installer generates your first deployment of RHTAP. But after installation, you must manage each product within RHTAP separately. And while the installer can be run multiple times, doing so after manually changing the configuration of a product may have unpredictable results.

Additionally, the products that the installer deploys are production ready, but they are sized for a proof of concept or a very small team. For larger teams, manual reconfiguration of the products is most likely necessary and should be done by following procedures documented for each individual product.

Lastly, please be aware that the RHTAP subscription only includes Red Hat Developer Hub, Red Hat Trusted Artifact Signer, Red Hat Trusted Profile Analyzer, and Red Hat Enterprise Contract. The RHTAP installer deploys all the other products listed above, too. But to use them, you must purchase a subscription for OpenShift Plus.

Important

To integrate products and external service with RHTAP, you must run integration commands. These commands support both of the following methods:

  • Manually enter the variable values in your terminal. This guide uses this method in all examples.
  • Create a private.env file and source it to make variables available in your shell session before running integration commands.

Installation steps

To install RHTAP using the installer, you must complete the following steps:

  1. Download the RHTAP installer image.
  2. Create a ConfigMap that controls the components and features to install. This configuration is stored in the cluster and used by the installer during deployment.
  3. (Optional) Customize the ConfigMap to disable products you plan to integrate later.
  4. Integrate products and external services.
  5. Deploy RHTAP.

The following pages of this document explain each of those installation steps in detail.

Chapter 1. Log in to Podman and download the installer image

Use this procedure to authenticate to registry.redhat.io, download the Red Hat Trusted Application Pipeline (RHTAP) installer image, and start the installer container. The installer CLI (rhtap-cli) runs inside this container and automates the deployment and integration of RHTAP components.

This step ensures that your environment is securely configured before you begin the installation.

Prerequisites

  • A container management tool on your workstation, such as Podman or Docker
  • Valid credentials for accessing registry.redhat.io

Procedure

  1. Log in to the Red Hat registry:

    podman login registry.redhat.io
  2. Download the RHTAP installer image:

    podman pull registry.redhat.io/rhtap-cli/rhtap-cli-rhel9:1.5.0
  3. Start the installer container:

    podman run \
      -it \
      --entrypoint bash \ 1
      --publish 8228:8228 \ 2
      --rm \
      rhtap-cli:1.5.0 3
    1
    Opens the container with an interactive Bash shell.
    2
    Exposes port 8228, which is required for GitHub App creation during the integration process.
    3
    Specifies the RHTAP installer image you pulled in the previous step.

Chapter 2. Creating the config.yaml file

Use this procedure to create the config.yaml file. This file defines how Red Hat Trusted Application Pipeline (RHTAP) is deployed in your OpenShift cluster. It also enables RHTAP to detect and use any external integrations that you configure during installation.

Prerequisites

  • cluster-admin access to your OpenShift Container Platform (OCP) cluster
  • An active rhtap-cli container session

Procedure

  1. In the rhtap-cli container, log in to your OpenShift cluster as a cluster administrator:

    bash-5.1$ oc login https://api.<cluster-domain>:6443 \
      --username=cluster-admin \
      --password=<your-password>
  2. Create the default configuration file:

    bash-5.1$ rhtap-cli config --create
Note

This command creates a config.yaml file that defines which components RHTAP installs and supports integration with pre-existing services. You can customize this file later to match your environment and deployment requirements.

Chapter 3. Customizing the config.yaml file

Use this procedure to customize the config.yaml file before integrating products and external services. Customizing this file ensures that your integrations and preferences are preserved during installation.

Prerequisites

  • You have access to the OpenShift Web Console.
  • You plan to integrate at least one external product or service (For example, RHACS or Quay).
  • (Optional) Forked software catalog repository URL. RHTAP provides a catalog of software templates that help developers scaffold applications. To customize these templates, fork the repository before installation.

    1. In your browser, go to the RHTAP software catalog repository.
    2. Click Fork to fork the repository.

      1. Uncheck the box labeled Copy the main branch only.
    3. When the fork is created, copy its URL and save it in the private.env file.
    4. In the forked repository, click main to open the branch/tag dropdown.
    5. Under Tags, select the release that matches your RHTAP version.

      Note

      Update your fork periodically to include changes from the upstream repository.

Procedure

  1. In the OpenShift console, switch to the Administrator perspective.
  2. Go to Workloads > ConfigMaps.
  3. From the Project drop down list, select RHTAP.
  4. Open the rhtap-cli-config ConfigMap.
  5. Select the YAML view and navigate to where config.yaml parameters are defined.

    Note
    • If your cluster already includes the required subscriptions or operators, you can prevent the installer from creating new ones by setting the manageSubscription property to false.

      • manageSubscription: true (default): The installer manages and installs all required operator subscriptions.
    • manageSubscription: false: The installer skips installing required operator subscriptions because it assumes they already exist on the cluster.

      • Ensure that the pre-installed operators are compatible with RHTAP. Incompatible versions or configurations may cause the installation to fail.
  6. Update the following fields as needed:

    1. To use a custom software catalog, set the catalogURL:

      redhatDeveloperHub:
        properties:
          catalogURL: https://github.com/<your-org>/tssc-sample-templates/blob/releases/all.yaml
    2. To disable installation of components you’ve integrated externally (for example, ACS and Quay):

      redhatAdvancedClusterSecurity:
        enabled: &rhacsEnabled false
        namespace: &rhacsNamespace rhtap-rhacs
      
      redHatQuay:
        enabled: &quayEnabled false
        namespace: &quayNamespace rhtap-quay
      Note

      If you try to integrate outside products or pre-existing instances, but do not customize config.yaml, Red Hat Trusted Application Pipeline still installs and uses its default products. You must customize config.yaml for your rhtap-cli integration commands to take effect. However, if you do not customize config.yaml for your rhtap-cli integration, the installer deploys the product and overrides the existing integrations.

  1. To enable the RBAC plugin in Developer Hub, configure the RBAC property in the redhatDeveloperHub section.

      RBAC:
        enabled: true # Enables the RBAC feature.
        adminUsers: # GitHub usernames that should have administrator access.
          - yourGitHubUsername
          - anotherGitHubAdmin
        orgs: # GitHub organizations whose members are imported into the Developer Hub catalog with access roles.
          - your-github-org
    Note

    If you omit adminUsers or orgs, the installer defaults to the GitHub user and organization that were configured when integrating the GitHub application.

  1. To use a custom namespace instead of the default one, configure the namespacePrefixes property in the redhatDeveloperHub section of the config.yaml file. By default, RHTAP creates four namespaces during installation:

    • rhtap-app-ci: For CI pipeline workloads
    • rhtap-app-development, rhtap-app-stage, and rhtap-app-prod: For development, staging, and prod deployments

      You can customize the prefixes for these namespaces and define additional namespace sets by using the namespacePrefixes property. For example, you can configure custom prefixes to generate namespaces such as my_prefix1-app-ci, my_prefix1-app-development, my_prefix1-app-stage, and my_prefix1-app-prod.

      redhatDeveloperHub:
        namespacePrefixes:
          - my_prefix1
          - my_prefix2
      1. After you complete all necessary changes, select Save.

Chapter 4. Integrating products and external services

Use this procedure to integrate existing products or replace default components before installing RHTAP. Integrating pre-existing services helps avoid data duplication and unnecessary deployments.

The RHTAP installer deploys a network of products that work together to form a secure, automated CI/CD platform. However, two of these products—Advanced Cluster Security (ACS) and Quay—might already be installed in your environment. If you have existing instances of either product, you can integrate them into your RHTAP deployment.

Integration prevents data loss and avoids deploying duplicate services. If you do not integrate an existing instance, the installer automatically creates a new instance in a new namespace.

Additionally, you can replace the default Git, CI, and registry components with supported alternatives. You can enable more than one alternative for some categories, such as source code repositories or CI tools. The following table lists the default components, their purpose, and the alternatives you can use:

ProductPurposeSupported alternatives

GitHub

Source code repository

  • GitLab
  • Bitbucket

Tekton

CI pipeline engine

  • Jenkins
  • GitHub Actions
  • GitLab CI
  • Azure Pipelines

Quay

Artifact registry

Artifactory

Note

CI pipeline alternatives conform to SLSA Build Level 2. Only Tekton conforms to SLSA Build Level 3.

Important

When you replace the default Git, CI, or registry providers, RHTAP installs corresponding plugins in Red Hat Developer Hub. Most of these plugins are in Technology Preview or are community-maintained.

Replacing default components is not recommended for production environments due to potential security risks and limited support.

For details, see the plugin support matrix in the Red Hat Trusted Application Pipeline release notes and the RHDH plugin documentation.

Note

To integrate products or customize your installation, you must run all relevant rhtap-cli commands inside a container that is logged in to your OpenShift cluster with cluster-admin privileges.

The following procedures explain how to customize your installation of RHTAP by integrating pre-existing services and supported alternatives.

4.1. Integrating GitHub

RHTAP uses GitHub to authenticate users and to create and manage application repositories. Before you install RHTAP, you must configure GitHub to support these capabilities.

To enable GitHub integration, complete the following procedures:

  1. Create a GitHub personal access token.
  2. Create a GitHub application.
Create a GitHub personal access token

You must own a GitHub organization to create a personal access token (PAT). You can use an existing GitHub organization, create a new one, or request ownership from an administrator.

After installation, the GitHub organization provides a location where users generate repositories for their applications.

Prerequisites

  • Ownership of a GitHub organization
  • A GitHub user account with permission to create personal access tokens
  • Access to GitHub Developer settings

Procedure

  1. Go to your Developer settings page on GitHub.
  2. In the left navigation panel, under Personal access tokens, click Tokens (classic).
  3. From the Generate new token dropdown menu, select Generate new token (classic). Authenticate if prompted.
  4. Enter a name, select an expiration date, and under Select scopes, select repo. This automatically includes all scopes from repo:status to security_events.
  5. Click Generate token. GitHub redirects you to a new page where your token is displayed.
  6. (Optional) Save the token to a file, such as values.txt, for reuse in later steps.
Create a GitHub application

Creating a GitHub application for RHTAP allows developers to authenticate to Red Hat Developer Hub, the web-based interface for interacting with RHTAP. It also allows RHTAP to access your GitHub organization and create repositories.

You must create and install this application in the same GitHub organization that you plan to use with RHTAP. The installer automates most of the configuration.

Prerequisites

  • A GitHub personal access token with repo scope
  • The name of your GitHub organization
  • A name to assign to your GitHub application
  • Valid credentials for registry.redhat.io
  • cluster-admin access to an OpenShift cluster
  • Access to the terminal or container where the rhtap-cli is installed

Procedure

  1. Run the following command to create the GitHub application:

    bash-5.1$ rhtap-cli integration github-app \
      --create \
      --token="$GH_TOKEN" \
      --org="$GH_ORG_NAME" \
      $GH_APP_NAME

    Replace the following variables:

    • $GH_TOKEN: The GitHub personal access token
    • $GH_ORG_NAME: The GitHub organization name
    • $GH_APP_NAME: The name of the GitHub application
  2. Copy the URL from the command output and open it in a browser.
  3. Click Create your GitHub App.
  4. If prompted, authenticate to GitHub.
  5. Click Create GitHub App for <your organization>.
  6. When the application is created, click the link in the success message to install the application in your GitHub organization.
  7. On the redirected GitHub page, click Install.
  8. Select the GitHub organization that you are using for RHTAP.
  9. When prompted, select All repositories, and click Install.

    Note

    You may want to keep this GitHub page open. The banner includes a link (beginning with https://backstage-developer-hub-rhtap…​) to access RHTAP after installation.

4.2. (Optional) Integrating RHACS

Use this procedure to integrate an existing instance of Advanced Cluster Security (RHACS) into your RHTAP installation.

Integrating RHACS ensures that your deployment uses your existing configuration and data instead of creating a new RHACS instance.

Prerequisites

  • Administrator access to an existing RHACS instance

Procedure

  1. Before you integrate RHACS, obtain an API token and the Central endpoint URL. The URL must include the protocol, hostname, and port. For example, https://central-rhacs.example.com:443.

    1. Follow the instructions at Create an RHACS API token to generate the token.
    2. Save the token to a file, such as values.txt, for reuse in later steps.
    3. Follow the instructions at Configure the Central endpoint URL to locate your ACS Central endpoint.
    4. Save the endpoint URL to a file, such as values.txt, for reuse in later steps.
  2. In your rhtap-cli container, run the following integration command:

    bash-5.1$ rhtap-cli integration acs \
      --endpoint="$ACS_ENDPOINT" \
      --token="$ACS_TOKEN"

    Replace the following variables:

    • $ACS_ENDPOINT: The URL of your RHACS Central endpoint
    • $ACS_TOKEN: The RHACS API token

4.3. (Optional) Integrating Quay

Use this procedure to integrate an existing Quay organization or a self-hosted Quay instance with RHTAP as your container image registry.

Note

If you don’t integrate an existing Quay instance, the RHTAP installer deploys a new instance of Quay. To use it, you must integrate this instance after RHTAP is installed.

You must obtain two values from your Quay instance and use them when running the CLI command: a Docker configuration string and an access token.

Prerequisites

  • A Quay account
  • Ownership of a Quay organization (any plan is supported, including free)
Note

Red Hat recommends using a robot account for this integration instead of a user account. A robot account allows automated systems and multiple users to authenticate to the Quay namespace after RHTAP is installed.

To learn how to create and configure a robot account, see: Create and use a robot account in Red Hat Quay.

Procedure

  1. In a web browser, log in to your Quay account.
  2. On the top right of the page, click your username, and then select Account Settings.
  3. On the Account Settings page, under Docker CLI Password, click Generate Encrypted Password. When prompted, enter your password to authenticate.
  4. In the same popup, click Docker Configuration > View [username]-auth.json. Copy the string value (without quotation marks) that follows "auth":.
  5. Save the auth value and your Quay username to a file, such as values.txt, so that you can use them when constructing the Docker configuration.
  6. In a separate browser tab, go to the Repositories page.
  7. Under Users and Organizations, click the name of the organization you want to use with RHTAP.
  8. In the left-hand navigation, click Applications.
  9. Click Create New Application and enter a name.
  10. Click the name of the application that you created.
  11. In the left-hand navigation, click Generate Token.
  12. In the permissions list, select View all visible repositories.
  13. Click Generate Access Token.
  14. Click Authorize Application. Quay displays the access token. Copy this token.
Note

You can use an OAuth application instead of a user or robot account. For more information, see: Creating an OAuth 2 access token.

Additionally, only the View all visible repositories permission is required.

  1. In your rhtap-cli container, run the following command to integrate Quay with RHTAP, passing all required values inline:

    bash-5.1$ rhtap-cli integration quay \
      --dockerconfigjson='{"auths":{"quay.io":{"auth":"<auth_token>","email":""}}}' \
      --token="<quay_access_token>" \
      --url="https://quay.io"

    Replace the following values:

    • <auth_token>: The value from the auth.json file under "auth":
    • <quay_access_token>: The access token you generated via the OAuth application
    • https://quay.io: The Quay instance URL (use your custom URL if self-hosted)
Note

Make sure to enclose the entire --dockerconfigjson value in single quotes to preserve JSON formatting.

4.4. (Optional) Integrating Bitbucket

Use this procedure if you want to use Bitbucket Cloud to host your source code for use with RHTAP.

Prerequisites

  • A Bitbucket username. To find your Bitbucket username:

    1. In Bitbucket, click your profile picture in the sidebar and select View profile.
    2. In the sidebar, click Settings. Your username is displayed in the account settings.
  • An app password

Procedure

  1. In the rhtap-cli container, run the following integration command:

    bash-5.1$ rhtap-cli integration bitbucket \
      --username="$BB_USERNAME" \
      --app-password="$BB_TOKEN" \
      --host="$BB_URL"

    Replace the following variables:

    • $BB_USERNAME: Your Bitbucket username
    • $BB_TOKEN: Your Bitbucket app password
    • $BB_URL: Your Bitbucket host URL (optional)

      Note

      If you are using the default Bitbucket Cloud host (bitbucket.org), you can omit the --host option.

4.5. (Optional) Integrating GitHub Actions

If you want to use GitHub Actions as an alternative continuous integration (CI) provider, no additional configuration is required before installation.

The GitHub application that you created earlier enables GitHub Actions integration for RHTAP.

4.6. (Optional) Integrating GitLab

Use this procedure if you want to use GitLab to host your source code or as a continuous integration (CI) provider with RHTAP.

Prerequisites

  • You must have the required permissions to create and manage GitLab jobs.
  • You must have a personal access token. For instructions, see the GitLab API token documentation.
  • You must have a GitLab host URL if you plan to integrate with a custom GitLab host. If you do not specify a host, the system defaults to gitlab.com.
  • You must have the GitLab group name that contains your repositories.

Procedure

  1. In the rhtap-cli container, run the following integration command:

    bash-5.1$ rhtap-cli integration gitlab \
      --token="$GL_API_TOKEN" \
      --host="$GL_URL" \
      --group="$GL_GROUP"

    Replace the following variables:

    • $GL_API_TOKEN: Your GitLab personal access token
    • $GL_URL: Your GitLab host URL (omit this option if using gitlab.com)
    • $GL_GROUP: The GitLab group name that contains your repositories

4.7. (Optional) Integrating Jenkins

Use this procedure to integrate Jenkins as a continuous integration (CI) provider for RHTAP.

Prerequisites

  • You must have the required permissions to create and manage Jenkins jobs.
  • You must have the following Jenkins credentials:

Procedure

  1. In the rhtap-cli container, run the following integration command:

    bash-5.1$ rhtap-cli integration jenkins \
      --token="$JK_API_TOKEN" \
      --url="$JK_URL" \
      --username="$JK_USERNAME"

    Replace the following variables:

    • $JK_API_TOKEN: Your Jenkins API token
    • $JK_URL: The URL of your Jenkins instance
    • $JK_USERNAME: Your Jenkins user ID

4.8. (Optional) Integrating Azure Pipelines

Use this procedure to integrate Azure Pipelines with RHTAP.

Prerequisites

  • You must have the required permissions in your Azure subscription to register applications and manage API permissions.
  • You must register a personal access token (PAT). For detailed steps, see the Microsoft documentation: How to generate personal access tokens in Azure DevOps
  • You must collect the following values:

    • AZURE_ORGANIZATION: The name of your Azure DevOps organization (for example, my-org-name)
    • AZURE_HOST_URL: The base URL of your Azure DevOps environment. The default value is dev.azure.com.
  • (Optional) If you use a registered Azure Active Directory (AAD) application to authenticate, also collect:

    Note

    If you do not use a registered AAD application, you must also collect AZURE_API_TOKEN, a personal access token used to authenticate with Azure DevOps.

Procedure

  1. In the rhtap-cli container, run the following integration command:

    bash-5.1$ rhtap-cli integration azure \
      --organization="$AZURE_ORGANIZATION" \
      --host="$AZURE_HOST_URL" \
      --token="$AZURE_API_TOKEN" \
      --tenantID="$AZURE_TENANT_ID" \
      --client-id="$AZURE_CLIENT_ID" \
      --client-secret="$AZURE_CLIENT_SECRET"

    Replace the following variables:

    • $AZURE_ORGANIZATION: Your Azure DevOps organization name
    • $AZURE_HOST_URL: Your DevOps base URL (omit this option if using the default dev.azure.com)
    • $AZURE_API_TOKEN: Your personal access token
    • $AZURE_TENANT_ID: (Optional) The AAD tenant ID
    • $AZURE_CLIENT_ID: (Optional) The AAD application client ID
    • $AZURE_CLIENT_SECRET: (Optional) The AAD application client secret

4.9. (Optional) Integrating JFrog Artifactory

Use this procedure to integrate an existing instance of JFrog Artifactory with RHTAP. This integration allows you to use your Artifactory repository as the artifact registry during CI/CD operations.

This module helps you configure authentication between RHTAP and your Artifactory instance, enabling seamless storage and retrieval of container images. Keywords: artifact registry, JFrog, CI/CD integration, DevSecOps, container images, Docker credentials.

Prerequisites

  • Administrator access to an instance of JFrog Artifactory
  • A repository in Artifactory that you want to use with RHTAP

Procedure

  1. In the Artifactory web UI, go to the Administration view.
  2. Click the green Set Up Client/CI Tool button next to the repository that you want to use.
  3. Select Docker Client.
  4. Follow the instructions in the UI to authenticate from your CLI:

    1. The UI generates a token that is used as your Docker password. Save the token to a file, such as values.txt, for reuse in later steps
    2. After logging in to JFrog via the CLI, you should see a message that your password was saved in a file such as ~/.docker/config.json.

      Note

      If you do not see this message, you can manually generate the config.json content in a later step.

  5. In your rhtap-cli container, run the following integration command:

    bash-5.1$ rhtap-cli integration artifactory \
      --url="$AF_URL" \
      --dockerconfigjson='$AF_DOCKERCONFIGJSON' \
      --token="$AF_API_TOKEN"

    Replace the following variables:

    • $AF_URL: The URL of your JFrog instance (for example, https://myusername.jfrog.io)
    • $AF_DOCKERCONFIGJSON: The contents of the config.json file where the password was stored
    • $AF_API_TOKEN: The token generated by JFrog

      Note

      Make sure to wrap the $AF_DOCKERCONFIGJSON value in single quotes to preserve the JSON structure.

      If the CLI did not generate the config.json file, you can manually create its contents using the following format:

      {
        "auths": {
          "<URL for your JFrog instance>": {
            "auth": "<base64 format of username:password>",
            "email": ""
          }
        }
      }

Chapter 5. Deploying RHTAP

Use this procedure to install Red Hat Trusted Application Pipeline (RHTAP) after completing all required configurations.

Prerequisites

  • The rhtap-cli container is running.
  • You are logged into your OpenShift cluster with cluster-admin access.
  • You have customized the config.yaml file.

Procedure

  1. In the container terminal, run the deployment command:

    bash-5.1$ rhtap-cli deploy
    Note

    The installation process typically takes around an hour to complete if all the components are deployed.

  2. Monitor the command output. As the deployment progresses, the CLI prints useful information, including URLs and access instructions for the deployed components. You can save the output to a file, such as values.txt, for future reference. The output may include:

    1. The Developer Hub (Backstage) URL
    2. ACS, Quay, and other dashboards (if deployed)
    3. Component-specific guidance or status messages
  3. To access the Developer Hub UI, use the link provided on your GitHub App page or the one shown in the installation output. It begins with:

    https://backstage-developer-hub-rhtap.apps.<cluster-domain>

Chapter 6. Post-installation integrations

6.1. (Optional) Integrating Quay deployed by RHTAP

If you’re using a new instance of Quay that the RHTAP installer has deployed during the installation, you need to regenerate the Quay OAuth access token and update the Quay integration secret on an OpenShift cluster where RHTAP is running.

This is necessary because the initial token, generated during the RHTAP installation, expires within 2 hours. After its expiration, RHTAP can’t access Quay and view the repositories under the rhtap organization. As a result, the Image Registry tab in the RHDH UI doesn’t display artifacts stored in your Quay repositories.

The following procedure ensures that RHTAP has access to Quay.

Procedure

  1. Log in to the Quay instance that runs on the same cluster with RHTAP.
  2. Navigate to the rhtap organization.
  3. Select Applications > OAuth Applications > Create New Application > Generate Token.
  4. Check the box for the View all visible repositories option.
  5. Click Generate Access Token.
  6. Copy and save the access token.
  7. Update the rhtap-quay-integration secret by running the following commands in the terminal:

    export ACCESS_TOKEN=<generated-Quay-token>
    oc patch secret rhtap-quay-integration \
      -n rhtap \
      --type='merge' \
      -p="{\"data\":{\"token\":\"$(echo -n $ACCESS_TOKEN | base64)\"}}"
    rhtap-cli deploy chart/rhtap-dh

    This step should automatically update the developer-hub-rhtap-env secret as well.

The changes take effect when the new backstage-developer-hub pod in the rhtap-dh project is up and running.

Verification

  • Go to the Red Hat Developer Hub UI and reload the Image Registry tab. The tab should now list all the artifacts stored in your Quay repositories.
  • Additionally, to verify that the required secrets have been successfully updated, you can display the values of the rhtap-quay-integration and developer-hub-rhtap-env secrets:

    oc get secret rhtap-quay-integration -o json -n rhtap | jq -r .data.token | base64 -d
    oc get secrets developer-hub-rhtap-env -o json -n rhtap-dh | jq -r .data.QUAY__API_TOKEN | base64 -d

    The output should show your newly generated Quay access token.

Additional resources

  • For more information on Quay OAuth tokens, refer to OAuth 2 access tokens in the Red Hat Quay documentation.





Revised on 2025-04-30 07:51:35 UTC

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat, Inc.