Лучшие практики управления секретами с хранилищем Хасикорп в Ci/cd

Лучшие практики управления секретами с хранилищем HashiCorp в CI/CD

Безопасное управление секретами является критическим аспектом современных трубопроводов CI/CD. Любая утечка ключей API, учетных данных баз данных или токенов может привести к катастрофическим нарушениям данных, нарушениям соответствия и репутационному ущербу. HashiCorp Vault обеспечивает надежное решение корпоративного уровня для тайного управления, позволяя организациям защищать конфиденциальные данные на протяжении всего жизненного цикла разработки и развертывания. Применяя лучшие практики для интеграции Vault, команды могут минимизировать воздействие, автоматизировать ротацию и обеспечивать строгий контроль доступа, не замедляя доставку.

В этом руководстве излагаются проверенные стратегии использования HashiCorp Vault в средах CI/CD. Вы узнаете, как использовать динамические секреты, внедрять мелкозернистые политики, шифровать данные в пути и в покое, непрерывно вращать учетные данные и контролировать весь секретный доступ. Мы также охватываем интеграционные шаблоны для основных инструментов CI/CD, таких как Jenkins, GitLab CI и GitHub Actions, а также общие подводные камни, которых следует избегать.

Придерживаясь этих методов, вы не только укрепите свою безопасность, но и упростите рабочие процессы, уменьшите накладные расходы и поможете удовлетворить нормативные требования, такие как SOC 2, PCI DSS и HIPAA.

ХашиКорп хранилище в CI/CD

HashiCorp Vault — это инструмент, предназначенный для безопасного хранения и жесткого контроля доступа к токенам, паролям, сертификатам и другим секретам.В рабочих процессах CI/CD Vault может динамически генерировать секреты, управлять секретным жизненным циклом и обеспечивать соблюдение политик доступа.В отличие от статических секретов, жестко закодированных в конфигурационных файлах или переменных среды, Vault рассматривает секреты как эфемерные ресурсы, которые создаются по требованию и автоматически отменяются после использования.

Vault интегрируется с системами CI/CD через свои плагины REST API, CLI и нативную аутентификацию.

Такой подход устраняет необходимость хранить секреты в репозиториях Git, файлах конфигурации CI/CD или реестрах артефактов, резко сокращая поверхность атаки.

Основные принципы тайного управления с помощью хранилища

1.Использовать динамические секреты

Статические секреты — такие как один пароль базы данных, используемый в течение многих лет — являются обязательством по обеспечению безопасности. При компрометации они предоставляют постоянный доступ до ручного вращения. Динамические секретные движки Vault создают учетные данные на лету с короткими значениями времени до жизни (TTL). Например, Vault может генерировать уникальный, ограниченный по времени пароль для пользователя PostgreSQL или ключ доступа IAM для роли AWS.

Динамические секреты предлагают несколько преимуществ:

Для реализации динамических секретов настройте секретный движок (например, базу данных, AWS, Azure) с определенной ролью и TTL по умолчанию. Затем ваш конвейер запрашивает аренду для этой роли и использует возвращенные учетные данные только на время работы.

2. Внедрение тонкого контроля доступа

Политики хранилища написаны на языке конфигурации HCL (HashiCorp Configuration Language) и следуют модели разрешений на основе пути. Каждая политика предоставляет или отказывает в доступе к определенным секретным путям и возможностям (читать, создавать, обновлять, удалять, перечислять, sudo). Принцип наименьших привилегий должен определять каждое определение политики.

Рассмотрим эти руководящие принципы:

Пример минимальной политики для трубопровода CI:

path "database/creds/ci-app" {
 capabilities = ["read", "list"]
}

path "secret/data/ci/*" {
 capabilities = ["read", "list"]
}

path "auth/token/lookup-self" {
 capabilities = ["read"]
}

3. Шифровать секреты в покое и в пути

Vault автоматически шифрует все данные, хранящиеся в его бэкэнде, используя главный ключ. Этот ключ сам зашифрован и может управляться с помощью службы управления внешними ключами (KMS) или аппаратного модуля безопасности (HSM). Однако шифрование в пути одинаково важно. Вся связь между агентами CI/CD и Vault должна использовать TLS 1.2 или выше.

Лучшие практики:

4 Автоматическая секретная ротация

Регулярное вращение уменьшает ущерб от утечки секрета. Динамические секреты хранилища автоматически вращаются с каждым запросом на аренду, но статические секреты в магазинах KV также нуждаются в ротации. HashiCorp рекомендует использовать механизмы вращения хранилища и , а также периодические политики для обеспечения ротации на уровне приложения.

Для автоматизации вращения статических секретов:

  • Храните статические секреты в движке Vault KV v2, который поддерживает работу с версиями и контрольно-настройкой.
  • Напишите запланированную работу (крон, периодическая партия Nomad или трубопровод CI), которая генерирует новые значения и записывает их в хранилище.
  • Обновление любых зависимых систем (баз данных, шлюзов API) с помощью новой секретной системы через плагины Vault или внешние скрипты.
  • Используйте конечную точку Vault для вращения ключа шифрования корня через регулярные промежутки времени.

5.Аудит и мониторинг доступа

Vault регистрирует каждый аутентифицированный запрос на свои устройства аудита. Вы можете отправлять журналы аудита в файлы, сислог или внешние службы, такие как Elasticsearch, Splunk или Datadog. Журналы аудита содержат IP-адрес клиента, метод аутентификации, путь запроса, данные ответа (если это разрешено) и любые ошибки.

Основные методы мониторинга:

  • Запустить журналирование аудита: Настроить по меньшей мере одно устройство аудита. Используйте безопасный пункт назначения только с приложением, чтобы предотвратить подделку.
  • Установите оповещения: Создайте оповещения о неудачных попытках аутентификации, доступе к чувствительным путям (например, учетным данным производственной базы данных) или отзывах аренды.
  • Регулярно просматривайте: Периодически проверяйте использование политик и шаблоны доступа.
  • Использовать конечную точку Vault: Для потоковой передачи записей журнала в режиме реального времени, полезно для отладки во время CI/CD-запусков.

Интеграция Vault в трубопроводы CI/CD

Методы аутентификации для CI/CD

Выбор правильного метода аутентификации имеет решающее значение для безопасности и простоты использования. Общие методы включают:

  • AppRole: Рекомендован для аутентификации машины-машины. Сервис CI/CD создает роль хранилища с и . Трубопровод аутентифицируется, представляя оба, получая недолговечный клиентский токен.
  • Kubernetes Auth: Идеально подходит для трубопроводов, работающих в Kubernetes. Vault проверяет токен учетной записи Kubernetes через сервер API Kubernetes и выдает токен Vault на основе связанных политик учетной записи службы.
  • AWS/GCP/Azure Auth: Для трубопроводов, работающих на облачных провайдерах, Vault может проверять метаданные экземпляра или роль IAM для выдачи токенов без жестких ключей.
  • Token-Based: Для простых настроек инструмент CI/CD, такой как Jenkins, может вводить токен Vault в качестве секретной переменной. Этот подход менее безопасен и должен использоваться только с очень недолговечными токенами.

Всегда предпочитайте динамическую, связанную аутентификацию статическим токенам. Настройте токены TTL, чтобы соответствовать максимальной продолжительности работы трубопровода (например, 30 минут) и установите разумное количество применений (если применимо).

Интеграция с конкретными инструментами CI/CD

Дженкинс: Используйте плагин HashiCorp Vault. Настройте адрес сервера Vault, метод аутентификации (AppRole или токен) и определите трубопроводы, которые получают секреты через шаги. Плагин поддерживает кодирование base64, впрыск файлов и назначение переменных среды.

GitLab CI: GitLab CI изначально поддерживает Vault через токен. Настройте Vault на принятие JWT-аутентификации от JWT-эмитента GitLab., используйте блок , чтобы запросить токен Vault, а затем извлекать секреты с помощью Vault CLI или API.

GitHub Actions: Используйте GitHub action. Он поддерживает аутентификацию OIDC (рекомендуется), токен или AppRole. Добавьте шаг, который отображает секреты переменных среды или записывает их в файлы. Для OIDC настройте Vault с помощью метода JWT auth, доверенного эмитенту и связанного с конкретными репозиториями или ветвями.

CircleCI: Используйте Vault orb или прямые вызовы API. Функция контекста CircleCI может хранить токен Vault, но предпочтительнее AppRole или OIDC.

Образец рабочего процесса с AppRole в Дженкинсе

Рассмотрим конвейер Дженкинса, который строит изображение Докера и развертывает его в кластер Кубернетов. Вместо того, чтобы хранить конфигурацию Кубернетов и пароль реестра в Дженкинсе, он извлекает их из хранилища во время выполнения.

  1. Преднастройка хранилища: Создайте политику, позволяющую читать доступ к и . Создайте роль приложения с этой политикой, TTL 10 минут и , хранящуюся в Jenkins в качестве учетных данных.
  2. Шаг пикселей: Используйте плагин HashiCorp Vault с идентификатором роли AppRole (также учетным лицом) и SecretID. Плагин аутентифицирует и получает токен Vault.
  3. Fetch Secrets: Прочитайте пароль реестра Docker и токен Kubernetes из Vault. Плагин записывает их во временные переменные среды или файлы.
  4. Использование: Запуск с учетными данными. Затем запустение с конфигурацией. После шага трубопровод заканчивается и токен Vault истекает.
  5. Cleanup: Опционально отозвать Секретный идентификатор AppRole, если повторное использование нежелательно.

Передовые соображения

Секретные двигатели и их использование

Vault поддерживает множество секретных двигателей. Для CI/CD наиболее актуальными являются:

  • KV v2 (Key-Value): Храните статические секреты, такие как ключи API, сертификаты или настройки, специфичные для окружающей среды.
  • База данных: Создавать временные пользователи баз данных с динамическими учетными данными для MySQL, PostgreSQL, MongoDB и других.
  • Облачные провайдеры (AWS, Azure, GCP): Создавайте временные роли IAM, принципы обслуживания или ключи учетной записи хранения.
  • PKI: Выдача краткосрочных сертификатов TLS для mTLS между микросервисами или для контейнерных реестров.
  • Переход: Шифровать/расшифровать данные без их хранения — полезно для шифрования артефактов перед их хранением в репозитории.

Разработка политики Лучшие практики

Разработка политики с четким соглашением об именах и иерархической структурой.

  • — для CI-специфических секретов.
  • [[ФЛТ:19]] — для постановки тайн окружающей среды.
  • — для производственных секретов (с очень ограниченным доступом).

Избегайте использования путей с дикими картами слишком широко. Вместо этого, предоставьте доступ к определенным секретным путям. Используйте , чтобы избежать правил скупо; Отрицание по умолчанию Vault достаточно. Комбинации и должны быть проверены перед развертыванием на производство. Команда Vault CLI полезна для проверки.

Резервное копирование и аварийное восстановление

Бэкэнд хранилища Vault (консул, рафт, файл и т. Д.) должен регулярно резервироваться. Если использовать интегрированное хранилище (Raft), включите резервные копии снимков. Для трубопроводов CI / CD, которые зависят от Vault для всех секретов, отключение Vault разрушит развертывание.

  • Запуск Vault в высокодоступной конфигурации (HA) с тремя узлами.
  • Хранение запасного набора секретов в альтернативном зашифрованном магазине (например, AWS Secrets Manager) с коротким TTL, но рассматривайте это как последнее средство.
  • Регулярно тестируйте процедуры аварийного восстановления, включая восстановление после снимка.

Обычные подводные камни, чтобы избежать

  • Хардкодирование Vault Token в переменных CI/CD: Даже если токен хранится как секретная переменная, он может просочиться через журналы сборки или артефакты.Используйте динамическую аутентификацию (AppRole, OIDC), чтобы токен генерировался для каждого запуска и никогда не сохранялся.
  • Использование корневого токена в трубопроводах: Корневой токен должен использоваться только для инициализации и чрезвычайных ситуаций. Все трубопроводы должны использовать токены с ограниченным диапазоном с соответствующей политикой.
  • Не устанавливая короткие TTL: Трубопровод CI обычно работает в течение минут, а не часов. Установка токенов TTL на ожидаемую продолжительность работы плюс небольшой буфер. Долгоживущие токены увеличивают риск.
  • Игнорирование журналов аудита: Без мониторинга аудита вы пропускаете индикаторы компромиссных или неправильно настроенных политик.
  • Хранение секретов в трубопроводных выводах: Никогда не печатайте секреты для консолей, файлов журналов или создания артефактов. Используйте инъекцию на основе файлов или удалите секрет из переменных среды сразу после использования.
  • Забывание отзыва аренды: Динамические секреты остаются в силе до истечения срока аренды или аннулирования. Явно отменяйте аренду на этапах пост-строительства или очистки вашего трубопровода (].

Заключение

Интеграция HashiCorp Vault в ваши CI/CD-трубопроводы устраняет самый опасный источник секретных утечек: жесткие или хранимые в окружающей среде статические учетные данные. Следуя лучшим практикам, изложенным здесь - динамические секреты, мелкозернистый контроль доступа, шифрование, автоматизированная ротация и всесторонний аудит - вы можете достичь надежного, готового к производству секретного рабочего процесса управления.

Начните с малого: примите аутентификацию AppRole для одного трубопровода, возьмите динамическую базу данных и проверьте журналы аудита. Постепенно расширяйтесь, чтобы охватить все трубопроводы и секретные типы. С Vault безопасность и скорость идут рука об руку, гарантируя, что ваши выходы CI / CD являются безопасными и надежными.

Дополнительные ресурсы: