Using Variables

In GitLab CI/CD, variables are used to store and manage environment-specific settings, credentials, and other configuration values that are required during the execution of CI/CD pipelines. These variables can be defined at different levels, including project-level and group-level, and they play a crucial role in customizing and securing your CI/CD workflows.

Group and Project Variables

Scope

Group-level variables: Apply to all projects within a specific group. They are shared among all projects in that group.
Project-level variables: Apply to a specific project only. They are not shared with other projects, even within the same group.

Inheritance

Group-level variables: Are inherited by all projects within the group. If a variable is defined at the group level, it is automatically available to all projects in that group, unless overridden at the project level.
Project-level variables: Do not inherit from group-level variables. Each project must define its own project-level variables, and they do not affect other projects in the group.

Use Cases

Group-level variables: Useful for storing settings or credentials that are common across multiple projects within a group, such as shared API keys or deployment configurations.
Project-level variables: Ideal for project-specific settings or credentials that should not be shared with other projects in the same group.

Predefined Variables

GitLab also provides a set of predefined CI/CD variables. Those variables are listed below:

https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

ONES-AI Group Variables

In the GitLab ONES-AI group, common variables for CI are defined and used as follows. Group variables can be managed by users with Maintainer permissions.

Docker

DOCKER_REGISTRY
DOCKER_USERNAME
DOCKER_PASSWORD

MinIO

MINIO_SERVER_URL
MINIO_ALIAS
MINIO_ACCESS_KEY
MINIO_SECRET_KEY

Security

When using GitLab CI/CD variables, it’s crucial to follow security best practices to protect sensitive information and ensure the integrity of your CI/CD pipeline. Here are some security guidelines for using GitLab CI/CD variables:

Use Protected Variables

Mark sensitive variables as “protected” in GitLab CI/CD settings. Protected variables are only available to pipelines running on protected branches, ensuring that sensitive information is not exposed in less secure branches.

Limit Scope

Restrict the scope of variables to specific branches or environments to minimize exposure. Only provide access to variables where they are absolutely necessary.

Secrets Management

Treat CI/CD variables like secrets. Avoid hardcoding sensitive information directly into the CI/CD configuration. Instead, use CI/CD variables to store secrets, such as API keys, passwords, and tokens.

Mask Sensitive Information

GitLab provides a way to mask sensitive information in job logs using the CI_JOB_TOKEN. Use the CI_JOB_TOKEN variable in conjunction with the mask keyword to hide sensitive data in the job output.

Use Environment-specific Variables

If possible, use environment-specific variables to store sensitive information. This allows you to customize variable values based on the target environment (e.g., development, staging, production).

Regularly Rotate Credentials

Rotate credentials and tokens stored in CI/CD variables regularly. This practice helps minimize the risk in case sensitive information is exposed accidentally or if someone gains unauthorized access.

Access Control

Control access to CI/CD variables based on roles and permissions. Only grant access to users or roles that absolutely need it. Use GitLab’s Access Control features to manage permissions effectively.