Ответ
В GitLab CI/CD есть несколько способов безопасно использовать переменные из другого проекта. Я чаще всего использую подход с include и наследованием переменных.
Способ 1: Включение конфигурации из другого проекта (наиболее гибкий)
В .gitlab-ci.yml текущего проекта можно включить файл из другого проекта, который определяет job'ы или, что важно, экспортирует переменные.
# .gitlab-ci.yml в проекте А
include:
- project: 'group/secret-provider-project'
ref: main
file: '/.gitlab-ci-secrets.yml'
my_job:
script:
- echo "Доступ к секрету: $SHARED_DB_PASSWORD"
# .gitlab-ci-secrets.yml в проекте 'secret-provider-project'
# Этот файл не определяет job, а только переменные.
variables:
SHARED_DB_PASSWORD: "$PROVIDER_PROJECT_DB_PASSWORD" # Ссылается на переменную, заданную в настройках этого проекта
Ключевые условия:
- Токен пользователя или CI_JOB_TOKEN, под которым запущен пайплайн проекта А, должен иметь права на чтение репозитория проекта
secret-provider-project. - Переменная
PROVIDER_PROJECT_DB_PASSWORDдолжна быть определена в настройках CI/CD проектаsecret-provider-project.
Способ 2: Использование API GitLab (для нестандартных сценариев) Можно получить переменные напрямую через API внутри job'а.
# В script секции job'а
SHARED_VAR=$(curl --header "PRIVATE-TOKEN: $MY_ACCESS_TOKEN"
"https://gitlab.example.com/api/v4/projects/<SOURCE_PROJECT_ID>/variables/<VARIABLE_KEY>" | jq -r '.value')
Важные принципы безопасности, которые я соблюдаю:
- Принцип наименьших привилегий: Токен доступа должен иметь минимально необходимые права (только
read_repositoryдля Способа 1). - Защищенные переменные: В проекте-источнике переменные должны быть помечены как Protected и Masked, чтобы они не попадали в логи.
- Никогда не хардкодить токены: Токен
MY_ACCESS_TOKENдля API должен быть задан как Protected/Masked переменная в целевом проекте, а не в коде.