Учетные данные часто появляются сначала в локальных средах разработки инженеров, а затем копируются в не ограниченные областями видимости переменные CI/CD, чтобы конвейеры продолжали работу. Сохраненный там в виде исходного значения, а не ссылки на секрет с ограниченной областью видимости, ключ подписи попадает в каждую задачу в конвейере — независимо от того, скомпрометирована она или нет.
Развертывание автономного хранилища сокращает такие риски, но требует дублирования каждого изменения членства в проекте, защищенных веток и производственных сред. Когда хранилище рассинхронизируется, конвейер ломается или сервисная учетная запись агента сохраняет доступ, который ей больше не нужен.
GitLab Secrets Manager повышает безопасность учетных данных без использования второй модели разрешений. Теперь он доступен в GitLab 19.5 для тарифов Premium и Ultimate на GitLab.com и GitLab Self-Managed, а поддержка GitLab Dedicated появится в ближайшее время. Созданный на базе OpenBao, он хранит учетные данные для этапов сборки и выполнения под теми же разрешениями и с тем же аудитом, что и ваш код. Платформенные команды могут предоставлять разработчикам секреты по модели самообслуживания, а специалисты по безопасности получают учетные данные, ограниченные теми задачами, которые их используют, а также идентификаторы конвейера и задачи при каждом чтении через CI/CD.
"GitLab Secrets Manager позволяет нам централизовать секреты для CI/CD, Kubernetes и инфраструктуры как кода без развертывания нескольких хранилищ или поддержки отдельных точек интеграции. Он также усиливает безопасность нашей цепочки поставок за счет ограничения круга пользователей и конвейеров, имеющих доступ к конкретным учетным данным". — Джереми Наута (Jeremy Nauta), архитектор программного обеспечения, OneTrust
"GitLab Secrets Manager позволяет нам централизовать секреты для CI/CD, Kubernetes и инфраструктуры как кода без развертывания нескольких хранилищ или поддержки отдельных точек интеграции. Он также усиливает безопасность нашей цепочки поставок за счет ограничения круга пользователей и конвейеров, имеющих доступ к конкретным учетным данным". — Джереми Наута (Jeremy Nauta), архитектор программного обеспечения, OneTrust
Как Secrets Manager ограничивает область видимости секретов сборки для каждой задачи
Агенты могут выполнять непредвиденные действия, поэтому команды безопасности должны рассматривать каждую задачу так, будто ее агенты используют любые доступные им учетные данные. Secrets Manager сокращает список того, к чему агенты могут получить доступ, используя контекст, который GitLab уже имеет о каждой задаче: ее проект, ветку, в которой она выполняется, информацию о том, защищена ли эта ветка, и целевую среду.
Разработчик объявляет секрет, необходимый для задачи, с помощью ключевого слова secrets: в файле .gitlab-ci.yml, и GitLab внедряет значение только в те задачи, которые объявляют его и подпадают под соответствующую область видимости. Условия области видимости поддерживают подстановочные знаки (wildcards) для веток и сред и могут комбинироваться, поэтому одно правило может требовать наличия защищенной ветки и среды production/* перед тем, как задача получит учетные данные.
Внутри задачи GitLab записывает значение во временный файл и предоставляет доступ только к его пути, что ограничивает риски в подпроцессах, дампах сбоя и телеметрии. GitLab маскирует значение в логах задач и удаляет его по завершении задачи. В отличие от переменной CI/CD, секрет никогда не читается в конфигурации вашего проекта. OpenBao шифрует секреты в состоянии покоя с помощью алгоритма AES-256-GCM, поэтому копия базы данных секретов содержит только шифротекст. Задачи получают значения напрямую из OpenBao с помощью короткоживущих токенов, привязанных к идентификатору каждой задачи, что исключает попадание секретов в открытом виде в приложение GitLab.
Узнайте, как начать работу с Secrets Manager:
Отзыв и отслеживание скомпрометированных учетных данных
Когда пакет axios для npm был скомпрометирован, в рекомендации SANS командам советовали «предположить, что все переменные среды в затронутых системах были эксфильтрованы», и распространить расследования на сборщики CI/CD и инфраструктуру сборки. Специастам по реагированию приходилось выяснять, какие учетные данные могла прочитать каждая затронутая задача, как заблокировать доступ и какие именно запуски их читали.
При использовании Secrets Manager, когда задача выполняет зараженную зависимость, воздействие ограничивается только теми секретами, которые эта задача объявила и имела право читать. Для устранения последствий отзовите и замените утеченные учетные данные, обновите значение в Secrets Manager и проведите аудит этой конкретной задачи, пока остальные конвейеры продолжают работать. Secrets Manager предлагает установить напоминание о ротации при создании секрета. Динамические учетные данные появятся в ближайшем времени и обеспечат эфемерный доступ без ручной ротации.
GitLab передает каждое событие создания, чтения, обновления и удаления секретов в пункты назначения аудиторских событий и записывает изменения в журнал аудита. Каждая операция чтения из конвейера содержит идентификаторы конвейера и задачи, которые привязаны к коммиту, пользователю, вызвавшему действие, и мерж-реквесту, если таковой имеется. Специалисты по реагированию на инциденты и аудиторы могут отследить чтение до вызвавшего его изменения без сопоставления логов из системы CI, хранилища и поставщика личных данных. События аудита никогда не содержат самих значений секретов.
Управляйте секретами с помощью тех же разрешений, которые регулируют ваш код
Поскольку агенты берут на себя все больше работы, платформенные команды получают все больше запросов на конвейеры и сервисные учетные записи, которым требуются учетные данные. Когда эти запросы выстраиваются в очередь, команды прибегают к использованию широких прав и общих секретов.
Secrets Manager использует пространство имен GitLab в качестве границы изоляции. Проекты наследуют секреты, определенные в группах над ними, поэтому вы определяете общие учетные данные один раз. Владельцы предоставляют права на чтение, запись и удаление конкретным пользователям или ролям по умолчанию, используя ту же модель членства, которая регулирует код. Удалите человека или сервисную учетную запись агента из проекта, и доступ этой сущности к секретам проекта прекратится.
Разработчики ссылаются на секреты через права доступа к проекту, которыми они уже обладают. Если ссылка на секрет нарушается, они исправляют ее в том же мерж-реквесте, что и код, без необходимости привлекать второй репозиторий, согласующего или оформлять билет на доступ. Когда управляемые учетные данные находятся на расстоянии одной строчки кода, в переменных CI/CD с избыточными правами, локальных файлах или репозитории остается гораздо меньше секретов.
Единое хранилище для конвейеров и рабочих сред выполнения
Kubernetes, Terraform и сценарии часто используют отдельные хранилища секретов, каждое со своей моделью доступа и логами. Secrets Manager обслуживает инструменты среды выполнения из того же хранилища, что и конвейеры, используя те же разрешения и аудит:
- Kubernetes — через External Secrets Operator. ESO повторно запрашивает секрет с заданным интервалом и обновляет секрет Kubernetes на месте, поэтому измененное значение попадает в кластер без запуск конвейера.
- Terraform и OpenTofu. Они читают секрет в качестве источника данных во время планирования (plan) или применения (apply) и не допускают попадания учетных данных в файлы .tfvars и переменные CI/CD.
- Интерфейсы командной строки (CLI) OpenBao и Vault — через API, совместимый с Vault. Команды сохраняют свои существующие сценарии и перенаправляют их на Secrets Manager.
- Другие инструменты среды выполнения — через API Secrets Manager.
Каждый инструмент среды выполнения проходит аутентификацию с помощью сервисной учетной записи или токена доступа, и эта сущность требует членства в проекте и явного разрешения на чтение секрета. Затем GitLab выдает отдельный токен со сроком действия пять минут, который инструмент использует для его получения.
Как Secrets Manager вписывается в средства контроля цепочки поставок GitLab
Управляемая фабрика ПО от GitLab объединяет код, конвейеры, пакеты и секреты на одной платформе, используя единую модель идентификации и единую запись о том, как изменение попало в производство. Dependency Firewall определяет, какие пакеты попадают в конвейер, Secrets Manager ограничивает доступ конвейера к учетным данным, а Artifact Central управляет тем, что вы выпускаете.
Secrets Manager поддерживает два из пяти этапов стандарта GitLab Security Standard — фреймворка GitLab, позволяющего агентам получать автономность: на этапе авторизации (Authorize) он привязывает каждую задачу к секретам, которые разрешены ее идентификатором и областью видимости, а на этапе реагирования (Respond) он передает каждое событие CRUD в режиме потока.
Защита от пуша секретов блокирует коммиты с учетными данными до того, как они попадут в репозиторий, а обнаружение секретов находит те, которые уже находятся в вашем коде и истории. GitLab Duo Agent Platform выполняет триаж результатов этих сканирований и помечает вероятные ложные срабатывания, поэтому ваша команда отменяет, ротирует и проверяет только реальные утечки.
Существующие интеграции GitLab для HashiCorp Vault, AWS Secrets Manager, Azure Key Vault и Google Cloud Secret Manager продолжают работать вместе с Secrets Manager, поэтому вы можете выполнить миграцию в удобном для вас темпе.
Начало работы
GitLab Secrets Manager — это платное дополнение для тарифов Premium и Ultimate, оплата которого осуществляется через GitLab Credits: 1 кредит за один сохраненный секрет в месяц и 1 кредит за 2500 операций чтения. Для изолированных сред (air-gapped) доступен корпоративный лицензионный договор.
- На GitLab.com владельцы групп верхнего уровня могут бесплатно опробовать GitLab Secrets Manager в течение 30 дней или до исчерпания 500 ознакомительных кредитов (в зависимости от того, что наступит раньше). Перейдите в группу верхнего уровня, выберите Secure > Secrets Manager, а затем Start 30-day trial.
- В GitLab Self-Managed ваш администратор должен установить и включить Secrets Manager, следуя задокументированным рекомендациям по оценке ресурсов и обеспечению высокой доступности.
- Поддержка GitLab Dedicated появится в ближайшее время.
Чтобы найти первые учетные данные для переноса, запустите secret audit tool for CI/CD variables, которая помечает переменные, способные содержать учетные данные. Рабочий процесс миграции переменных CI/CD находится в разработке. Есть предложения или отзывы? Поделитесь ими в обсуждении отзывов по Secrets Manager.
Чтобы найти первые учетные данные для переноса, запустите , которая помечает переменные, способные содержать учетные данные. Рабочий процесс миграции переменных CI/CD находится в разработке.
Есть предложения или отзывы? Поделитесь ими в обсуждении отзывов по Secrets Manager.
