GitLab 19.5: кому Secrets Manager отдаёт секрет в конвейере
Secrets Manager в GitLab 19.5 стал generally available, но сам новый способ хранения не определяет, какому заданию выпуска можно выдавать рабочий секрет. Нужно согласовать область проекта, окружение, ветку и право запускать соответствующий job. Хранилище и полномочия конвейера остаются разными частями защиты.
Что объявлено доступным в октябре
GitLab 19.5 выпущен 15 октября 2026 года. Документация Secrets Manager фиксирует GA в этой версии, использование OpenBao и доступность для Premium/Ultimate на GitLab.com и Self-Managed. Это переход статуса функции, а не её первое появление вообще.
Документация описывает GitLab Credits и отдельно условия offline-лицензии, которая должна включать функцию. Нельзя объявлять менеджер бесплатным для любой установки GitLab. До включения выясните применимый способ доступа, требования своей поставки и условия продолжения работы после оценки.
Секрет нужен операции, а не всему проекту по привычке
Возьмём вымышленный конвейер: сборка, проверка на тестовом окружении и выпуск на рабочее. Не каждое из этих заданий должно получать одинаковые полномочия. Сначала запишите, какое действие выполняет job, затем определите минимально необходимый доступ и допустимые условия запуска.
| Учебное задание | Окружение | Нужное по проекту полномочие | Кто согласует доступ | Ожидаемый итог без доступа |
|---|---|---|---|---|
| Собрать артефакт | Сборочное | Только необходимое для сборки, без автоматического рабочего ключа | Ответственный за сборочный процесс | Понятная ошибка нужной зависимости |
| Проверить развёртывание | Тестовое | Отдельный доступ к тестовому назначению | Владелец тестового окружения | Проверка не подменяется рабочим выпуском |
| Выпустить принятую версию | Рабочее | Доступ к согласованному рабочему назначению | Владелец выпуска и правил запуска | Остановка без ложного сообщения об успехе |
| Посмотреть результат проверки | Без изменения среды | Необходимые отчёты, а не значение секрета | Владелец доступа к отчётам | Видно ограничение прав, секрет не раскрыт |
Матрица — наша рекомендация проектирования, не автоматические defaults GitLab. Для каждого доступа нужно сопоставить замысел с реальными настройками и разрешёнными исполнителями. Название job «production» не делает его защищённым само по себе.
Области веток и окружений требуют точной проверки
Текущая документация задаёт окружения для секретов, ветки для проектных настроек и отдельную опцию protected branches в групповых. Она также предупреждает: значение доступно заданиям подходящих окружений или веток, поэтому только уполномоченные пользователи должны иметь возможность запускать такие задания.
Не ограничивайтесь вопросом, кто может редактировать секрет. Отдельно выясните, кто запускает job, использующий значение, и какой код при этом исполняется. Политика хранения без согласованного пути использования оставляет главный вопрос выпуска открытым.
Форма передачи и журнал — тоже часть приёмки
По умолчанию секрет передаётся заданию через временный файл, а соответствующая переменная содержит путь; предусмотрен и вариант переменной со значением. Выбранный способ нужно согласовать с вызываемым инструментом. Не считайте путь строковым паролем и не печатайте содержимое ради диагностики.
Маскирование журналов не является основанием выводить секрет в сообщение. Для проверки достаточно тестового доступа и наблюдения результата разрешённой операции. Отдельно согласуйте, какие события должен видеть ответственный и какие данные ему для этого действительно нужны.
Оценочный доступ не заменяет план сопровождения
Если функция проверяется в trial, заранее определите условие перехода к штатному использованию. Кто отвечает за подписку или лицензию, настройку OpenBao в Self-Managed и доступность при следующем выпуске? Эти обязанности не выполняются автоматически после зелёного тестового job.
- Назовите секрет по назначению, не раскрывая значение.
- Перечислите задания и необходимые им операции.
- Сопоставьте проект, окружение, ветку и право запуска с нужной областью доступа.
- Выберите поддерживаемую форму передачи значения инструменту.
- Проверьте разрешённый сценарий и отказ на тестовом доступе.
- Уточните постоянные условия использования и ответственных за сопровождение.
В поддержке сервера закрепляйте состав и условия выбранной поставки. Для защиты приложения рассматривайте весь путь полномочий, а в автоматизации выпуска отдельно принимайте результат job. Менеджер секретов полезен, когда его настройка соответствует тому, кто и какую работу действительно выполняет.
Вопросы и ответы
Что изменилось у GitLab Secrets Manager в 19.5?
Документация фиксирует переход к generally available. Это не означает бесплатную доступность любой установке: нужно сверить tier, offering и применимые условия.
Что нужно проверить для GitLab Secrets Manager self hosted?
Сверьте требования Self-Managed, настройку OpenBao и условия лицензии или Credits для своей поставки. Отдельно определите, какие jobs могут получать значения и кто вправе их запускать.
GitLab Secrets Manager pricing одинаков для всех?
Документация описывает использование GitLab Credits и отдельные условия offline-лицензии. Конкретные коммерческие условия проверяют для своей подписки; наличие GA не делает функцию бесплатной.