Управление секретами контейнеров Docker с хранилищем Hashicorp

Понимание необходимости безопасного управления секретными данными в Docker

Контейнеры преобразовали развертывание приложений, предлагая легкие, портативные среды. Однако этот сдвиг усилил проблему управления конфиденциальными данными, такими как ключи API, учетные данные базы данных и сертификаты TLS. Секреты жесткого кодирования в изображениях Docker, связывая их с контролем версий или передавая их в качестве простых переменных среды, вводят значительные риски безопасности. Специальное секретное решение управления, такое как HashiCorp Vault , устраняет эти риски, предоставляя централизованную, проверяемую и динамическую систему для хранения и распространения секретов в контейнерных приложениях.

Что такое хранилище HashiCorp?

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

Vault поддерживает несколько секретных движков (ключевое значение, базы данных, PKI, транзит и т.д.) и методов аутентификации (токены, AppRole, Kubernetes, LDAP и т.д.), что делает его адаптируемым практически к любой инфраструктуре.

Зачем использовать Vault с Docker?

Интеграция Vault с контейнерами Docker имеет ряд преимуществ перед традиционными методами секретного впрыска:

HashiCorp Vault Architecture для контейнерных рабочих нагрузок

Перед погружением в интеграцию полезно понять архитектуру развертывания Vault. Vault работает как демон сервера с бэкэндом хранилища ключевых значений (Consul, etcd, интегрированное хранилище Raft или облачное хранилище). Он раскрывает RESTful HTTP API. Клиенты аутентифицируют и извлекают секреты с помощью токенов, AppRole или методов, основанных на идентификации.

Для контейнерных сред Vault часто используется одним из двух способов:

  • Кластер серверов Vault (производство): Доступный, герметичный/незапечатанный кластер обработки запросов из нескольких контейнеров. Используйте интегрированное хранилище Raft для простоты или Consul для более крупных развертываний.
  • Vault Dev Server (разработка): одноузловый, в памяти экземпляр с авто-непечатью. Идеально подходит для локального тестирования, но никогда для производства.

Контейнеры взаимодействуют с Vault через официальный Vault CLI, HTTP API или агент коляски (Vault Agent), который автоматически обрабатывает аутентификацию и секретную выборку.

Интеграция Vault с Docker: Core Patterns

Есть несколько проверенных шаблонов для впрыскивания секретов хранилища в контейнеры Docker. Выбор зависит от уровня оркестровки и операционной зрелости.

1. Использование CLI Vault в сценариях Entrypoint

Это самый простой шаблон. Изображение контейнера включает в себя Vault CLI, а скрипт оболочки точки входа аутентифицируется в Vault, извлекает секреты и вставляет их в приложение в качестве переменных среды или файлов.

# Dockerfile
FROM alpine:latest
RUN apk add --no-cache vault ca-certificates
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
# entrypoint.sh
#!/bin/sh
export VAULT_ADDR="http://vault.example.com:8200"
vault login -method=approle role_id="$ROLE_ID" secret_id="$SECRET_ID"
API_KEY=$(vault kv get -field=api_key secret/myapp)
export API_KEY
exec myapp

Контейнер принимает и в качестве переменных среды (или через монтируемые файлы). Такой подход требует, чтобы контейнер имел сетевой доступ к Vault и полной двоичной системе Vault, что увеличивает размер изображения.

2. Штурмовой агент.

Агент хранилища — демон, который может аутентифицировать, извлекать секреты и передавать их в файлы или шаблоны. Он поддерживает шаблон sidecar , где агент работает рядом с основным контейнером в той же капсуле (Kubernetes) или сервисе Docker Compose. Агент автоматически возобновляет аренду и обрабатывает секретное вращение.

# config.hcl for Vault Agent
vault {
 address = "http://vault.example.com:8200"
}
auto_auth {
 method "approle" {
 mount_path = "auth/approle"
 config = {
 role_id_file_path = "/tmp/role-id"
 secret_id_file_path = "/tmp/secret-id"
 }
 }
}
template {
 source = "/tmp/secrets.ctmpl"
 destination = "/etc/secrets/app.env"
}

Агент наблюдает за шаблоном изменений и переоформляет вывод при обновлении секретов. Это отделяет секретное извлечение из кода приложения.

3. Docker Swarm Secrets с Vault Driver

Docker Swarm имеет встроенную секретную систему, но хранение секретов в журналах Swarm Raft может не соответствовать требованиям соответствия. Для маршрутизации секретных запросов Swarm в Vault может использоваться сторонний драйвер Vault. Это менее распространено, но полезно для организаций, уже инвестирующих в Swarm.

4.Кубернеты с CSI драйвером

Для пользователей Kubernetes поставщик CSI-сервера Vault позволяет стручкам монтировать секреты хранилища в виде томов. Для этого используется интерфейс хранения контейнеров (CSI) для установки секретов без каких-либо модификаций приложения. Он легко интегрируется с драйвером CSI магазина секретов Kubernetes и поддерживает автоматическое вращение.

Методы аутентификации контейнеров

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

  • AppRole: Идеально подходит для автоматизации. Контейнеру даются и (последний может быть обернутым токеном или другим секретом. Контейнер обменивает их на токен Vault).
  • Kubernetes Auth: При работе на Kubernetes Vault может аутентифицировать подсистемы путем проверки токенов учетной записи службы.
  • JWT/OIDC: Подходит для облачных сред, где контейнеры имеют токены JWT от надежного поставщика идентификационных данных.
  • Токен: Простейший, но наименее безопасный.Токены могут быть предварительно сконфигурированы в трубопроводах CI/CD или введены с помощью оркестровки.

Динамические секреты: реальная сила

Одной из самых сильных функций Vault для рабочих нагрузок Docker является динамическая секретность . Вместо хранения статических учетных данных в хранилище ключей Vault, Vault может подключаться к базе данных (PostgreSQL, MySQL, MongoDB) и создавать временного пользователя на лету. Контейнер получает этот учетный данные, использует его, и когда срок аренды истекает (или контейнер умирает), Vault автоматически удаляет пользователя.

# Example: Enable PostgreSQL secrets engine
vault secrets enable database
vault write database/config/my-postgres-database \
 plugin_name=postgresql-database-plugin \
 allowed_roles="my-role" \
 connection_url="postgresql://{{username}}:{{password}}@postgres.example.com:5432/myapp" \
 username="vault_admin" \
 password="super_secret"

vault write database/roles/my-role \
 db_name=my-postgres-database \
 creation_statements="CREATE USER \"{{name}}\" WITH PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
 default_ttl="1h" \
 max_ttl="24h"

Контейнер запрашивает учетные данные: . Это возвращает уникальное имя пользователя / пароль, действительный в течение одного часа. Нигде не хранятся статические учетные данные.

Лучшие практики для Docker + Vault

  • Никогда не секреты жесткого кода в изображениях. Используйте только инъекцию среды выполнения.
  • Используйте политики хранилища с наименьшими привилегиями. Каждый контейнер или услуга должны иметь возможность читать только свои собственные секреты и пути.
  • Предпочитает Vault Agent или коляски над встраиванием Vault CLI в изображения. Это упрощает управление жизненным циклом и уменьшает размер изображения.
  • Часто вращайте секретные идентификаторы AppRole. Используйте или периодические токены, чтобы минимизировать воздействие.
  • Запустить регистрацию аудита в хранилище и судовых журналах в центральном SIEM.
  • Само хранилище безопасности: Используйте TLS для всех коммуникаций, отпечатайте через авто-незапечатанное (KMS, облачный HSM) и ограничьте доступ к сети Vault только оркестраторам и контейнерам.
  • Следует изящно обновлять секрет. Приложения должны быть в состоянии обновить учетные данные без перезапуска. Шаблоны агента хранилища или механизмы наблюдения за окружающей средой помогают.
  • Тест на сценарии отказа: Имитировать время простоя хранилища, сетевые разделы и истечение срока действия токена, чтобы обеспечить изящное ухудшение приложений.
  • Используйте короткие TTL для динамических секретов и токенов, чтобы ограничить воздействие, если контейнер скомпрометирован.
  • Рассматривайте секретный кэширующий слой (например, кэш агента хранилища), чтобы уменьшить нагрузку на хранилище и улучшить производительность для высокопроизводительных сред.

Сравнение с альтернативами

Хотя Vault является ведущим решением, стоит понимать, как он сравнивается с другими подходами:

  • Коренные секреты докера (Swarm): простые, но ограниченные статичными секретами, отсутствие динамического генерирования, аудиторского следа или мелкозернистых политик. Хранятся в журналах Raft, которые могут не удовлетворять строгому соблюдению.
  • Секреты Kubernetes: Базовые статические секреты, кодируемые в формате base64 и т. д. Без шифрования в покое (что требует дополнительной конфигурации) они могут быть небезопасными. Никакого центрального управления по кластерам.
  • Секретные менеджеры облачных провайдеров (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager): Хорошая интеграция с их экосистемами, но блокировка.
  • CyberArk Conjur: Корпоративно ориентированный, сильный на управление привилегированным доступом, но более сложный и дорогостоящий, чем Vault для контейнерных вариантов использования.

Vault обеспечивает баланс между гибкостью с открытым исходным кодом, богатством функций и широкой поддержкой платформы, что делает его популярным выбором для развертывания многооблачных и гибридных Docker.

Создание производственного хранилища для Docker

  1. Развернуть высокодоступный кластер хранилища: Используйте официальную диаграмму рулевого управления на Kubernetes или запустите Vault в ручном режиме HA с Raft storage. Обеспечьте по меньшей мере три узла.
  2. Настройка автоматической уплотнения: Используйте облачную KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS) или HSM. Никогда не храните неуплотненные ключи в том же кластере, что и Vault.
  3. Включить Аудиторские устройства : Отправить журналы аудита в стадный и безопасный внешний магазин.
  4. Установить политики и роли : Создать политики для каждой услуги (например, ). Привяжите их к ролям AppRole или учетным записям службы Kubernetes.
  5. Интегрируйтесь с оркестровкой: В Kubernetes установите Vault CSI Provider или Vault Injector (мутирующий веб-хук). Для сырого Docker используйте контейнеры коляски Vault Agent через Docker Compose.
  6. Испытайте динамические секреты: Включите механизм секретов базы данных и создайте роли. Проверьте, что контейнеры могут запрашивать и использовать временные учетные данные.
  7. Внедрить интеграцию CI/CD: В вашем конвейере используйте API Vault для предоставления временных токенов для каждой стадии сборки, избегая статических учетных данных.

За пределами секретного хранения

Использование Vault снижает риск секретного воздействия, но не устраняет все векторы атаки:

  • Безопасность сети: Убедитесь, что хранилище не подвергается публичному доступу в Интернет. Используйте внутреннюю взаимную аутентификацию DNS и TLS, если это возможно.
  • Происхождение изображения: Проверьте, что базовые изображения и вытащенные пакеты взяты из доверенных реестров. Компрометированное изображение может выводить секреты до инъекции Vault.
  • Мониторинг времени выполнения: : Используйте инструменты безопасности контейнеров (Falco, Tracee, AppArmor) для обнаружения неожиданных выполнения процессов или доступа к файлам.
  • Секретное разрастание: Даже с Vault разработчики могут по-прежнему жестко кодировать секреты в файлах среды для локального тестирования.
  • Управление арендой: Заявки, которые не возобновляют аренду, могут потерять доступ в критические моменты. Внедрить проверки здоровья и механизмы резервного копирования.

Реальный случай использования: микросервисы с учетными данными базы данных

Рассмотрим платформу электронной коммерции с 20 микросервисами, каждый из которых подключается к конкретной базе данных PostgreSQL. Без Vault каждая служба имеет в своем манифесте или изображении жестко закодированный пользователь базы данных/пароль. Вращающиеся пароли требуют перераспределения всех сервисов. С Vault:

  • Каждый сервис проходит аутентификацию через AppRole или Kubernetes auth.
  • Все службы запрашивают динамические учетные данные базы данных при запуске.
  • Полномочия действительны в течение 1 часа и автоматически продлеваются агентом Vault.
  • Если услуга скомпрометирована, оператор отменяет все свои активные договоры аренды в одной команде.
  • Журналы аудита базы данных показывают, что временные пользователи создаются, уменьшая радиус взрыва любых украденных учетных данных.

Эта модель значительно снижает эксплуатационные накладные расходы и значительно улучшает положение в области безопасности.

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

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

Заключение

Интеграция HashiCorp Vault с контейнерами Docker является лучшей практикой для любой организации, серьезно относящейся к безопасности, соблюдению и операционной эффективности. Переходя от статических, жестко закодированных секретов к динамичному, централизованно управляемому секретному жизненному циклу, вы снижаете риск, упрощаете ротации и получаете полную аудиторскую способность. Независимо от того, используете ли вы коляски агентов, Kubernetes CSI или пользовательские скрипты точек входа, Vault обеспечивает надежную основу для тайного управления в контейнерных средах. Начните с малого с одной службы, а затем расширяйте свой флот - ваше будущее я (и ваша команда безопасности) будет вам благодарен.

Для дальнейшего чтения, обратитесь к официальной документации хранилища , Обзор секретов докера и Руководство для поставщиков CSI хранилища .