This documentation is for a release that is no longer maintained
See documentation for the latest supported version.Configuring GitLab CI
Learn how to configure GitLab CI for secure CI/CD workflows.
Abstract
Preface Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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
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.envfile, which you created during RHTAP installation.
1.1. Option 1: Using GitLab UI Copy linkLink copied to clipboard!
Procedure
- Log in to GitLab and open your source repository.
- Expand the Setting menu and select CI/CD.
- In the Variables section, select Expand, and then select Add variable.
Enter the following details:
- Under Flags, select Mask variable to hide sensitive values.
- In the Key field, enter MY_GITLAB_TOKEN.
- In the Value field, enter the token associated with your GitLab account.
Repeat steps 3-4 to add the required variables:
Expand Variable Description Provide image registry credentials for only one image registry.
QUAY_IO_CREDS_USRUsername for accessing Quay.io repository.
QUAY_IO_CREDS_PSWPassword for accessing Quay.io repository.
ARTIFACTORY_IO_CREDS_USRUsername for accessing JFrog Artifactory repository.
ARTIFACTORY_IO_CREDS_PSWPassword for accessing JFrog Artifactory repository.
NEXUS_IO_CREDS_USRUsername for accessing Sonatype Nexus repository.
NEXUS_IO_CREDS_PSWPassword for accessing Sonatype Nexus repository.
Set these variables if Gitlab CI runners do not run on the same cluster as the RHTAP instance.
REKOR_HOSTURL of your Rekor server.
TUF_MIRRORURL of your TUF service.
GitOps configuration for GitLab
GITOPS_AUTH_PASSWORDThe 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_ENDPOINTEndpoint for the ROX Central server.
ROX_API_TOKENAPI token for accessing the ROX server.
Variables required for SBOM tasks.
COSIGN_SECRET_PASSWORDPassword for Cosign signing key.
COSIGN_SECRET_KEYPrivate key for Cosign.
COSIGN_PUBLIC_KEYPublic key for Cosign.
TRUSTIFICATION_BOMBASTIC_API_URLURL for Trustification Bombastic API used in SBOM generation.
TRUSTIFICATION_OIDC_ISSUER_URLOIDC issuer URL used for authentication when interacting with the Trustification Bombastic API.
TRUSTIFICATION_OIDC_CLIENT_IDClient ID for authenticating to the Trustification Bombastic API using OIDC.
TRUSTIFICATION_OIDC_CLIENT_SECRETClient secret used alongside the client ID to authenticate to the Trustification Bombastic API.
TRUSTIFICATION_SUPPORTED_CYCLONEDX_VERSIONSpecifies the CycloneDX SBOM version that is supported and generated by the system.
- Select Add variable.
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: Using CLI Copy linkLink copied to clipboard!
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.shfile with the following environment variables:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Update the
glab-set-varsfile with the following information:Copy to Clipboard Copied! Toggle word wrap Toggle overflow (Optional) Modify the
glab-set-varsfile to disable variables that are not required. For example, to disablesetVars ROX_API_TOKEN $ROX_API_TOKEN, addfalsenext to it.ROX_API_TOKEN $ROX_API_TOKEN false
ROX_API_TOKEN $ROX_API_TOKEN falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow Load the environment variables into your current shell session:
source env_vars.sh
source env_vars.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow Make the
glab-set-varsscript 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
chmod +x glab-set-vars ./glab-set-vars your_repository_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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-02-12 15:08:44 UTC