Configuring GitLab CI
Learn how to configure GitLab CI for secure CI/CD workflows.
Abstract
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
NoteThe 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.
- Log in to GitLab and open your source repository.
- Expand the Setting menu and select CI/CD.
- In the Variables section, select Expand.
Select Add variable and in a pop-up window add the first secret:
- In the Key field, enter MY_GITLAB_TOKEN.
- In the Value field, enter the token associated with your GitLab account.
- Under Flags, select Mask variable to hide sensitive values.
- Select Add variable.
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 Variable Description 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 Variable Description 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.
Add regular environment variables:
- Select Add variable.
- In the Key field, enter the key, for example, QUAY_IO_CREDS_USR.
- In the Value field, enter the username for accessing your Quay repository.
- Under Flags, do not select Mask variable.
- Select Add variable.
Repeat step 6 to add the following variables:
Table 1.3. Image registry and GitOps variables Variable Description 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 Variable Description 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 Variable Description REKOR_HOST
URL of your Rekor server.
TUF_MIRROR
URL of your TUF service.
Rerun the last pipeline run to verify the secrets are applied correctly.
- 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
Create a project with two files in your preferred text editor, such as Visual Studio Code:
- env_vars.sh
- glab-set-vars
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"
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
NoteBy 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, addfalse
at the end of a line where you set it. For example:setVars COSIGN_PUBLIC_KEY $COSIGN_PUBLIC_KEY false
Load the environment variables into your current shell session:
source env_vars.sh
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
Rerun the last pipeline run to verify the secrets are applied correctly.
- 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