GitLab 19.0 Secrets Manager: як звузити доступ до секретів у CI без великого vault-переїзду

Зачіпка

Секрети рідко ламають систему голосно. Частіше вони тихо накопичуються в CI/CD variables, .env файлах, старих deploy jobs і group-level налаштуваннях, які вже ніхто не хоче чіпати.

GitLab 19.0 виніс GitLab Secrets Manager у public beta. Цінність не в тому, що GitLab раптом замінює всі vault-системи світу. Цінність у простішому першому кроці: забрати найризикованіші CI секрети з широких variables і видавати їх тільки тим jobs, які справді мають право їх бачити.

Проблема / контекст

Типовий GitLab pipeline починається невинно: додали DATABASE_PASSWORD, DEPLOY_TOKEN, AWS_SECRET_ACCESS_KEY або NPM_TOKEN у project variables, замаскували значення, pipeline запрацював. Через пів року цей самий secret уже доступний занадто багатьом jobs, environments або branches.

Проблема не в тому, що CI/CD variables “погані”. Вони зручні й досі потрібні для багатьох простих сценаріїв. Проблема починається, коли секрет стоїть на рівні group або project, а реальний доступ має бути набагато вужчим: тільки deploy job, тільки protected branch, тільки production environment.

GitLab у своєму release angle прямо б’є по цій ситуації: замість того щоб тримати секрет як глобальну змінну pipeline, job має явно попросити потрібний secret через secrets: у .gitlab-ci.yml. Secrets backend перевіряє identity job, branch, environment і protected status, а потім видає значення тільки в межах цього запуску.

Чому це важливо

Широкий secret збільшує blast radius. Якщо dependency у pipeline скомпрометована, runner поводиться не так, як очікували, або хтось отримав доступ до job logs чи shell, команда мусить думати не про одну job, а про все, куди цей secret міг дістатися.

Job-scoped model зменшує цю паніку. Якщо production deploy token доступний тільки deploy job на protected branch і production environment, інцидент у тестовій job не автоматично означає повну ротацію production-доступів.

Є ще один практичний плюс: GitLab Secrets Manager живе в тій самій project/group моделі, де вже описані команди, ролі та permissions. Для невеликої команди це може бути менш боляче, ніж одразу будувати окремий Vault, нову auth-модель, нові audit streams і окремий процес onboarding.

Але beta-статус важливий. Це не привід переносити всі критичні production secrets за один вечір. Це привід зробити обережний pilot там, де current CI/CD variables уже явно занадто широкі.

Як це зробити

1. Знайдіть over-scoped variables

Почніть без зміни pipeline. Вивантажте список GitLab variables без значень і позначте три речі:

• де secret заданий: group чи project;
• які jobs реально його читають;
• для яких branches і environments він має бути доступний.

Найкращі кандидати на pilot:

• deploy tokens;
• registry credentials;
• cloud credentials;
• database migration passwords;
• signing keys;
• tokens для security або release tooling.

Поганий кандидат для першого pilot: найкритичніший production secret, який блокує весь реліз, якщо щось піде не так.

2. Перевірте обмеження перед pilot

Перед .gitlab-ci.yml diff перевірте нудні умови:

• GitLab Secrets Manager зараз у public beta;
• потрібен GitLab Premium або Ultimate;
• GitLab.com і self-managed мають різні opt-in кроки;
• для self-managed потрібен OpenBao;
• jobs мають бігти на GitLab Runner 19.0+;
• pricing після beta може змінитися через GitLab Credits, тому це треба врахувати в rollout plan.

Це саме той список, який краще знайти до демо, а не під час production incident.

3. Зробіть один секрет job-scoped

У мінімальному варіанті job явно запитує secret:

deploy:
  stage: deploy
  environment: production
  secrets:
    DATABASE_PASSWORD:
      gitlab_secrets_manager:
        name: db-password
  script:
    - deploy --password "$DATABASE_PASSWORD"

GitLab за замовчуванням може передавати secret як тимчасовий файл і покласти шлях до нього в environment variable. Це часто краще, ніж передавати саме значення в процеси, crash dumps або telemetry.

Для real rollout не зупиняйтесь на YAML. Опишіть scope: environment, branch, protected branch condition. Інакше ви просто перенесли секрет із одного місця в інше, але не звузили доступ.

4. Залиште rollback поруч

Beta означає: rollback має бути нудним і швидким.

План rollback:

1. зберегти стару CI/CD variable disabled або тимчасово перейменовану;
2. тримати MR із .gitlab-ci.yml diff маленьким;
3. перевірити deploy на non-production environment;
4. мати окремий manual job для повернення старого variable path;
5. записати, які credentials треба ротувати, якщо pilot піде криво.

Rollback не означає, що pilot провалився. Це нормальна частина rollout для security feature, яка торкається релізів.

5. Не змішуйте pilot із великим secrets refactor

Спокуса очевидна: раз уже зайшли в секрети, давайте одночасно приберемо старі variables, перейменуємо environments, перепишемо deploy jobs і наведемо порядок у runners.

Не треба.

Перший pilot має відповісти на одне питання: чи може конкретна job отримати конкретний secret через GitLab Secrets Manager із правильним scope і зрозумілим audit trail. Якщо відповідь так, тоді можна планувати другу хвилю.

Антипатерни

• Перенести всі secrets одразу, бо feature виглядає правильно.
• Замінити CI/CD variables на Secrets Manager без звуження branch/environment scope.
• Не перевірити GitLab Runner 19.0+.
• Забути про OpenBao requirements для self-managed.
• Дати secret group-level там, де потрібен project-level доступ.
• Вважати beta feature заміною зрілого external Vault для всіх regulated workloads.
• Не підготувати rollback перед зміною deploy job.

Висновок / план дій

GitLab Secrets Manager у 19.0 варто сприймати як практичний інструмент для зменшення секрет-хаосу в CI, а не як магічну заміну всіх secret-management процесів.

Мінімальний здоровий rollout:

1. знайти over-scoped CI/CD variables;
2. вибрати один не критичний, але реальний secret;
3. перевірити tier, beta opt-in, runner і self-managed prerequisites;
4. описати branch/environment scope;
5. додати secrets: у одну job;
6. перевірити audit trail і runtime behavior;
7. задокументувати rollback;
8. тільки після цього масштабувати на production secrets.

Офіційні джерела:

• https://about.gitlab.com/blog/secrets-manager-in-public-beta/
• https://about.gitlab.com/whats-new/
• https://docs.gitlab.com/ci/secrets/secrets_manager/