이 콘텐츠는 선택한 언어로 제공되지 않습니다.
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.envfile, 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:
Expand Table 1.1. Image registry and GitOps secrets Variable Description QUAY_IO_CREDS_PSWPassword for accessing your Quay repository.
ARTIFACTORY_IO_CREDS_PSWPassword for accessing your JFrog Artifactory repository.
NEXUS_IO_CREDS_PSWPassword for accessing your Sonatype Nexus repository.
GITOPS_AUTH_PASSWORDThe token the system uses to update the GitOps repository for newly built images.
Expand Table 1.2. Secrets required for ACS and SBOM tasks Variable Description ROX_API_TOKENAPI token for accessing the ROX server.
COSIGN_SECRET_PASSWORDPassword for Cosign signing key.
COSIGN_SECRET_KEYPrivate key for Cosign.
TRUSTIFICATION_OIDC_CLIENT_SECRETClient 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:
Expand Table 1.3. Image registry and GitOps variables Variable Description QUAY_IO_CREDS_USRUsername for accessing your Quay repository.
ARTIFACTORY_IO_CREDS_USRUsername for accessing your JFrog Artifactory repository.
NEXUS_IO_CREDS_USRUsername for accessing your Nexus repository.
GITOPS_AUTH_USERNAMEYour OpenShift GitOps username.
Expand Table 1.4. Variables required for ACS and SBOM tasks Variable Description ROX_CENTRAL_ENDPOINTEndpoint for the ROX Central server.
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_SUPPORTED_CYCLONEDX_VERSIONSpecifies 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.
Expand Table 1.5. Rekor and TUF variables Variable Description REKOR_HOSTURL of your Rekor server.
TUF_MIRRORURL 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.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 NoteBy default, the
setVarsfunction 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, addfalseat the end of a line where you set it. For example:setVars COSIGN_PUBLIC_KEY $COSIGN_PUBLIC_KEY false
setVars COSIGN_PUBLIC_KEY $COSIGN_PUBLIC_KEY 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-04-30 03:55:47 UTC