# 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.