Configuring GitLab CI


Red Hat Trusted Application Pipeline 1.5

Learn how to configure GitLab CI for secure CI/CD workflows.

Red Hat Trusted Application Pipeline Documentation Team

Abstract

This document provides instructions on setting up GitLab CI to perform essential security tasks, such as vulnerability scanning, image signing, and attestation generation.

Preface

If you’re using GitLab CI for your application, pipeline runs may fail due to missing secrets. Without them, integrations with Quay, JFrog, and Red Hat Advanced Cluster Security (ACS) won’t work, breaking security tasks like vulnerability scanning, image signing, and SBOM generation for compliance.

To prevent this, you need to securely store secrets in GitLab CI. This guide walks you through the process, ensuring your pipelines run smoothly and securely.

Chapter 1. Adding secrets and variables to GitLab CI for integration with external tools

Prerequisites

Before you configure GitLab CI, ensure you have the following:

  • Admin access to your GitLab repository and CI/CD settings.
  • Container registry credentials for pulling container images from Quay.io, JFrog Artifactory, or Sonatype Nexus.
  • Authentication details for specific GitLab CI tasks:

    • For ACS security tasks:

      • ROX Central server endpoint
      • ROX API token
    • For SBOM and artifact signing tasks:

      • Cosign signing key password, private key and public key
      • Trustification API and issuer URL, client ID, client secret, and supported CycloneDX version
    Note

    The credentials and other details are already Base64-encoded, so you do not need to encode them again. You can find these credentials in your private.env file, which you created during RHTAP installation.

1.1. Option 1: Adding secrets and variables to GitLab CI using UI

Procedure

This procedure add both required secrets and environment variables. Note that you need to mask values of secrets.

  1. Log in to GitLab and open your source repository.
  2. Expand the Setting menu and select CI/CD.
  3. In the Variables section, select Expand.
  4. Select Add variable and in a pop-up window add the first secret:

    1. In the Key field, enter MY_GITLAB_TOKEN.
    2. In the Value field, enter the token associated with your GitLab account.
    3. Under Flags, select Mask variable to hide sensitive values.
    4. Select Add variable.
  5. Repeat step 4 to add the required secrets and check the Mask variable flag for each of them:

    Table 1.1. Image registry and GitOps secrets
    VariableDescription

    QUAY_IO_CREDS_PSW

    Password for accessing your Quay repository.

    ARTIFACTORY_IO_CREDS_PSW

    Password for accessing your JFrog Artifactory repository.

    NEXUS_IO_CREDS_PSW

    Password for accessing your Sonatype Nexus repository.

    GITOPS_AUTH_PASSWORD

    The token the system uses to update the GitOps repository for newly built images.

    Table 1.2. Secrets required for ACS and SBOM tasks
    VariableDescription

    ROX_API_TOKEN

    API token for accessing the ROX server.

    COSIGN_SECRET_PASSWORD

    Password for Cosign signing key.

    COSIGN_SECRET_KEY

    Private key for Cosign.

    TRUSTIFICATION_OIDC_CLIENT_SECRET

    Client secret used alongside the client ID to authenticate to the Trustification Bombastic API.

  1. Add regular environment variables:

    1. Select Add variable.
    2. In the Key field, enter the key, for example, QUAY_IO_CREDS_USR.
    3. In the Value field, enter the username for accessing your Quay repository.
    4. Under Flags, do not select Mask variable.
    5. Select Add variable.
  2. Repeat step 6 to add the following variables:

    Table 1.3. Image registry and GitOps variables
    VariableDescription

    QUAY_IO_CREDS_USR

    Username for accessing your Quay repository.

    ARTIFACTORY_IO_CREDS_USR

    Username for accessing your JFrog Artifactory repository.

    NEXUS_IO_CREDS_USR

    Username for accessing your Nexus repository.

    GITOPS_AUTH_USERNAME

    Your OpenShift GitOps username.

    Table 1.4. Variables required for ACS and SBOM tasks
    VariableDescription

    ROX_CENTRAL_ENDPOINT

    Endpoint for the ROX Central server.

    COSIGN_PUBLIC_KEY

    Public key for Cosign.

    TRUSTIFICATION_BOMBASTIC_API_URL

    URL for Trustification Bombastic API used in SBOM generation.

    TRUSTIFICATION_OIDC_ISSUER_URL

    OIDC issuer URL used for authentication when interacting with the Trustification Bombastic API.

    TRUSTIFICATION_OIDC_CLIENT_ID

    Client ID for authenticating to the Trustification Bombastic API using OIDC.

    TRUSTIFICATION_SUPPORTED_CYCLONEDX_VERSION

    Specifies the CycloneDX SBOM version that is supported and generated by the system.

    Optional: Set the Rekor and TUF variables if your CI provider runners do not run on the same cluster as the RHTAP instance.

    Table 1.5. Rekor and TUF variables
    VariableDescription

    REKOR_HOST

    URL of your Rekor server.

    TUF_MIRROR

    URL of your TUF service.

  1. Rerun the last pipeline run to verify the secrets are applied correctly.

    1. Alternatively, switch to you application’s source repository in GitLab, make a minor change, and commit it to trigger a new pipeline run.

1.2. Option 2: Adding secrets and variables to GitLab CI using CLI

Procedure

  1. Create a project with two files in your preferred text editor, such as Visual Studio Code:

    • env_vars.sh
    • glab-set-vars
  2. Update the env_vars.sh file with the following environment variables:

    # env_vars.sh
    # GitLab credentials
    export MY_GITLAB_TOKEN="your_gitlab_token_here"
    export MY_GITLAB_USER="your_gitlab_username_here"
    
    export GITOPS_AUTH_PASSWORD="your_OpenShift_GitOps_password_here"
    export GITOPS_AUTH_USERNAME="your_OpenShift_GitOps_username_here"
    
    
    
    // Add credentials for an image repository that you use
    # Quay.io credentials
    export QUAY_IO_CREDS_USR="your_quay_username_here"
    export QUAY_IO_CREDS_PSW="your_quay_password_here"
    
    # or JFrog Artifactory credenditals
    export ARTIFACTORY_IO_CREDS_USR="your_artifactory_username_here"
    export ARTIFACTORY_IO_CREDS_PSW="your_artifactory_password_here"
    
    # or Sonatype Nexus credentials
    export NEXUS_IO_CREDS_USR="your_nexus_username_here"
    export NEXUS_IO_CREDS_PSW="your_nexus_password_here"
    
    // Variables required for ACS tasks
    # ROX variables
    export ROX_CENTRAL_ENDPOINT="your_rox_central_endpoint_here"
    export ROX_API_TOKEN="your_rox_api_token_here"
    
    // Variables required for SBOM tasks.
    # Cosign secrets
    export COSIGN_SECRET_PASSWORD="your_cosign_secret_password_here"
    export COSIGN_SECRET_KEY="your_cosign_secret_key_here"
    export COSIGN_PUBLIC_KEY="your_cosign_public_key_here"
    
    # Trustification credentials
    export TRUSTIFICATION_BOMBASTIC_API_URL="your__BOMBASTIC_API_URL_here"
    export TRUSTIFICATION_OIDC_ISSUER_URL="your_OIDC_ISSUER_URL_here"
    export TRUSTIFICATION_OIDC_CLIENT_ID="your_OIDC_CLIENT_ID_here"
    export TRUSTIFICATION_OIDC_CLIENT_SECRET="your_OIDC_CLIENT_SECRET_here"
    export TRUSTIFICATION_SUPPORTED_CYCLONEDX_VERSION="your_SUPPORTED_CYCLONEDX_VERSION_here"
    
    // Set these variables if your CI provider runners do not run
    on the same cluster as the {ProductShortName} instance.
    # Rekor and TUF routes
    export REKOR_HOST="your rekor server url here"
    export TUF_MIRROR="your tuf service url here"
  3. Update the glab-set-vars file with the following information:

    #!/bin/bash
    SCRIPTDIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" > /dev/null 2>&1 && pwd)"
    
    if [ $# -ne 1 ]; then
        echo "Missing param, provide gitlab repo name"
        echo "Note: This script uses MY_GITLAB_TOKEN and MY_GITLAB_USER env vars"
        exit
    fi
    
    REPO=$1
    HEADER="PRIVATE-TOKEN: $MY_GITLAB_TOKEN"
    URL=https://gitlab.com/api/v4/projects
    
    # Lookup the project id so we can use it below
    PID=$(curl -s -L --header "$HEADER" "$URL/$MY_GITLAB_USER%2F${REPO//.git/}" | jq ".id")
    
    function setVars() {
        NAME=$1
        VALUE=$2
        MASKED=${3:-true}
        echo "setting $NAME in https://gitlab.com/$MY_GITLAB_USER/$REPO"
    
        # Delete first because if the secret already exists then its value
        # won't be changed by the POST below
        curl -s --request DELETE --header "$HEADER" "$URL/$PID/variables/$NAME"
    
        # Set the new key/value
        curl -s --request POST --header "$HEADER" "$URL/$PID/variables" \
            --form "key=$NAME" --form "value=$VALUE" --form "masked=$MASKED" | jq
    }
    
    setVars ROX_CENTRAL_ENDPOINT $ROX_CENTRAL_ENDPOINT false
    setVars ROX_API_TOKEN $ROX_API_TOKEN
    
    setVars GITOPS_AUTH_PASSWORD $MY_GITLAB_TOKEN
    setVars GITOPS_AUTH_USERNAME $MY_GITLAB_USER false
    
    # Depending on which image repository you use, set:
    setVars QUAY_IO_CREDS_USR $QUAY_IO_CREDS_USR false
    setVars QUAY_IO_CREDS_PSW $QUAY_IO_CREDS_PSW
    # or
    setVars ARTIFACTORY_IO_CREDS_USR "$ARTIFACTORY_IO_CREDS_USR" false
    setVars ARTIFACTORY_IO_CREDS_PSW "$ARTIFACTORY_IO_CREDS_PSW"
    # or
    setVars NEXUS_IO_CREDS_USR "$NEXUS_IO_CREDS_USR" false
    setVars NEXUS_IO_CREDS_PSW "$NEXUS_IO_CREDS_PSW"
    
    setVars COSIGN_SECRET_PASSWORD $COSIGN_SECRET_PASSWORD
    setVars COSIGN_SECRET_KEY $COSIGN_SECRET_KEY
    setVars COSIGN_PUBLIC_KEY $COSIGN_PUBLIC_KEY false
    
    setVars TRUSTIFICATION_BOMBASTIC_API_URL "$TRUSTIFICATION_BOMBASTIC_API_URL" false
    setVars TRUSTIFICATION_OIDC_ISSUER_URL "$TRUSTIFICATION_OIDC_ISSUER_URL" false
    setVars TRUSTIFICATION_OIDC_CLIENT_ID "$TRUSTIFICATION_OIDC_CLIENT_ID" false
    setVars TRUSTIFICATION_OIDC_CLIENT_SECRET "$TRUSTIFICATION_OIDC_CLIENT_SECRET"
    setVars TRUSTIFICATION_SUPPORTED_CYCLONEDX_VERSION "$TRUSTIFICATION_SUPPORTED_CYCLONEDX_VERSION" false
    
    # If you need to use the Rekor and TUF variables and you've added them
    # to env_vars.sh, set them here too:
    
    setVars REKOR_HOST "$REKOR_HOST" false
    setVars TUF_MIRROR "$TUF_MIRROR" false
    
    bash $SCRIPTDIR/glab-get-vars $1
    Note

    By default, the setVars function creates a variable as a secret, and this variable’s value won’t be displayed in the UI and logs. To create an unmasked variable, add false at the end of a line where you set it. For example:

    setVars COSIGN_PUBLIC_KEY $COSIGN_PUBLIC_KEY false
  4. Load the environment variables into your current shell session:

    source env_vars.sh
  5. Make the glab-set-vars script executable, and run it with your repository name to set the variables in your GitLab repository.

    chmod +x glab-set-vars
    
    ./glab-set-vars your_repository_name
  6. Rerun the last pipeline run to verify the secrets are applied correctly.

    1. Alternatively, switch to you application’s source repository in GitLab, make a minor change, and commit it to trigger a new pipeline run.





Revised on 2025-04-30 03:55:47 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.