Configuring GitLab CI


Red Hat Trusted Application Pipeline 1.4

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 to GitLab CI for secure 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 URL
      • Client ID and secret
      • 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: Using GitLab UI

Procedure

  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, and then select Add variable.
  4. Enter the following details:

    1. Under Flags, select Mask variable to hide sensitive values.
    2. In the Key field, enter MY_GITLAB_TOKEN.
    3. In the Value field, enter the token associated with your GitLab account.
  5. Repeat steps 3-4 to add the required variables:

    VariableDescription

    Provide image registry credentials for only one image registry.

    QUAY_IO_CREDS_USR

    Username for accessing Quay.io repository.

    QUAY_IO_CREDS_PSW

    Password for accessing Quay.io repository.

    ARTIFACTORY_IO_CREDS_USR

    Username for accessing JFrog Artifactory repository.

    ARTIFACTORY_IO_CREDS_PSW

    Password for accessing JFrog Artifactory repository.

    NEXUS_IO_CREDS_USR

    Username for accessing Sonatype Nexus repository.

    NEXUS_IO_CREDS_PSW

    Password for accessing Sonatype Nexus repository.

    Set these variables if Gitlab CI runners do not run on the same cluster as the RHTAP instance.

    REKOR_HOST

    URL of your Rekor server.

    TUF_MIRROR

    URL of your TUF service.

    GitOps configuration for GitLab

    GITOPS_AUTH_PASSWORD

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

    GITOPS_AUTH_USERNAME (optional)

    The parameter required for GitLab to work with Jenkins. You also need to uncomment a line with this parameter in a Jenkinsfile: GITOPS_AUTH_USERNAME = credentials('GITOPS_AUTH_USERNAME'). By default, this line is commented out.

    Variable required for ACS tasks.

    ROX_CENTRAL_ENDPOINT

    Endpoint for the ROX Central server.

    ROX_API_TOKEN

    API token for accessing the ROX server.

    Variables required for SBOM tasks.

    COSIGN_SECRET_PASSWORD

    Password for Cosign signing key.

    COSIGN_SECRET_KEY

    Private key for Cosign.

    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_OIDC_CLIENT_SECRET

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

    TRUSTIFICATION_SUPPORTED_CYCLONEDX_VERSION

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

  6. Select Add variable.
  7. 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: 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"
    
    
    
    // Provide the credentials for the image registry you use.
    # Quay.io credentials
    export QUAY_IO_CREDS_USR="your_quay_username_here"
    export QUAY_IO_CREDS_PSW="your_quay_password_here"
    
    # JFrog Artifactory credenditals
    export ARTIFACTORY_IO_CREDS_USR="your_artifactory_username_here"
    export ARTIFACTORY_IO_CREDS_PSW="your_artifactory_password_here"
    
    # Sonatype Nexus credentials
    export NEXUS_IO_CREDS_USR="your_nexus_username_here"
    export NEXUS_IO_CREDS_PSW="your_nexus_password_here"
    
    # Rekor and TUF routes
    export REKOR_HOST="your rekor server url here"
    export TUF_MIRROR="your tuf service url 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"
    
    
    // Set these variables if Gitlab CI runners do not run on the same cluster as the {ProductShortName} instance.
    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"
  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
    
    # Look up the project ID so we can use it below
    PID=$(curl -s -L --header "$HEADER" "$URL/$MY_GITLAB_USER%2F$REPO" | 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
    setVars ROX_API_TOKEN $ROX_API_TOKEN
    
    setVars GITOPS_AUTH_PASSWORD $MY_GITLAB_TOKEN
    setVars GITOPS_AUTH_USERNAME $MY_GITLAB_USER
    
    setVars QUAY_IO_CREDS_USR $QUAY_IO_CREDS_USR
    setVars QUAY_IO_CREDS_PSW $QUAY_IO_CREDS_PSW
    
    setVars COSIGN_SECRET_PASSWORD $COSIGN_SECRET_PASSWORD
    setVars COSIGN_SECRET_KEY $COSIGN_SECRET_KEY
    setVars COSIGN_PUBLIC_KEY $COSIGN_PUBLIC_KEY
    
    setVars TRUSTIFICATION_BOMBASTIC_API_URL "$TRUSTIFICATION_BOMBASTIC_API_URL"
    setVars TRUSTIFICATION_OIDC_ISSUER_URL "$TRUSTIFICATION_OIDC_ISSUER_URL"
    setVars TRUSTIFICATION_OIDC_CLIENT_ID "$TRUSTIFICATION_OIDC_CLIENT_ID"
    setVars TRUSTIFICATION_OIDC_CLIENT_SECRET "$TRUSTIFICATION_OIDC_CLIENT_SECRET"
    setVars TRUSTIFICATION_SUPPORTED_CYCLONEDX_VERSION "$TRUSTIFICATION_SUPPORTED_CYCLONEDX_VERSION"
    
    setVars ARTIFACTORY_IO_CREDS_USR $ARTIFACTORY_IO_CREDS_USR
    setVars ARTIFACTORY_IO_CREDS_PSW $ARTIFACTORY_IO_CREDS_PSW
    
    setVars NEXUS_IO_CREDS_USR $NEXUS_IO_CREDS_USR
    setVars NEXUS_IO_CREDS_PSW $NEXUS_IO_CREDS_PSW
    
    setVars REKOR_HOST $REKOR_HOST
    setVars TUF_MIRROR $TUF_MIRROR
  4. (Optional) Modify the glab-set-vars file to disable variables that are not required. For example, to disable setVars ROX_API_TOKEN $ROX_API_TOKEN, add false next to it.

    ROX_API_TOKEN $ROX_API_TOKEN false
  5. Load the environment variables into your current shell session:

    source env_vars.sh
  6. 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
  7. 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-02-12 15:08:44 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.
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.

© 2024 Red Hat, Inc.