Доступно в редакциях: CE, BE, SE, SE+, EE, CSE Lite (1.73), CSE Pro (1.73)
Стадия жизненного цикла модуля: General Availability
У модуля есть требования для установки
Модуль secrets-store-integration реализует доставку секретов для приложений в Kubernetes-кластерах.
Модуль позволяет приложениям получать секреты из внешнего хранилища, совместимого с API HashiCorp Vault.
Основные возможности
- Доставляет секреты в поды в виде примонтированных файлов или переменных окружения без хранения в Kubernetes.
- Поддерживает автоматическое подключение к внутреннему экземпляру Deckhouse Stronghold без ручной настройки (режим
DiscoverLocalStronghold). - Работает с любым Vault-совместимым хранилищем секретов в режиме
Manual. - Автоматически обновляет примонтированные секреты каждые две минуты при изменении значения в хранилище.
- Поддерживает инъекцию entrypoint для приложений, которые нельзя модифицировать для прямого чтения секретов из хранилища.
- Поддерживает доставку бинарных секретов в формате Base64 (например, JKS-хранилища, keytab-файлы для Kerberos) с автоматическим раскодированием.
Секреты могут быть доставлены в приложение разными способами. Чтобы не путаться в вариантах, в этой документации они разделены на три уровня:
- архитектурная модель — кто получает секрет из внешнего хранилища;
- форма доставки — как приложение читает секрет;
- механизм реализации — каким способом это реализовано в Kubernetes.
Это важно, потому что приложение, CSI, entrypoint injection и переменные окружения — не сущности одного уровня.
Архитектурные модели
Приложение получает секрет самостоятельно
В этом сценарии приложение обращается во внешнее хранилище напрямую и получает секрет без промежуточного хранения в Kubernetes.
Это наиболее безопасный вариант. Он рекомендован к использованию, если приложение можно модифицировать.
Платформа доставляет секрет в приложение через файл
В этом сценарии секрет получает инфраструктурный компонент, а приложение читает его из файла, смонтированного в контейнер.
Основной механизм реализации — CSI. Для этого варианта в сравнительной таблице указан сценарий, в котором приложение получает данные из дискового тома, а секрет в Kubernetes не хранится.
Платформа доставляет секрет в приложение через переменные окружения
В этом сценарии секрет получает инфраструктурный компонент, а приложение видит его как переменную окружения.
Один из реализованных способов — инъекция entrypoint: секреты доставляются из хранилища в момент запуска приложения в виде переменных окружения и при этом не хранятся в Kubernetes.
Формы доставки секрета
Через файл
Приложение читает секрет из файла в примонтированном томе.
Этот сценарий реализуется через CSI. Секрет извлекается из хранилища драйвером CSI на этапе создания контейнера, поэтому запуск пода блокируется до тех пор, пока секреты не будут прочитаны из хранилища и записаны в том.
Через переменные окружения
Приложение читает секрет из переменных окружения.
Для этого используется инжектор: при наличии у пода аннотации secrets-store.deckhouse.io/role mutating webhook изменяет манифест пода, добавляет init-контейнер и заменяет команду запуска контейнера на запуск инжектора. Инжектор получает секреты из Vault-совместимого хранилища, помещает их в ENV процесса и затем запускает оригинальную команду через execve.
Если у контейнера в манифесте не задана команда запуска, она извлекается из манифеста образа в хранилище образов контейнеров.
Механизмы реализации
CSI
CSI — основной механизм доставки секрета в виде файла.
Для сценария с CSI:
- приложение получает секрет из дискового тома как файл;
- секрет не хранится в Kubernetes;
- запуск пода зависит от успешного чтения секрета и записи его в том.
Инъекция entrypoint
Entrypoint injection — механизм доставки секрета в переменные окружения в момент запуска приложения.
С точки зрения приложения это отдельный сценарий потребления секрета через ENV, а не через файл.
Инжектор переменных окружения
Инжектор переменных окружения — технический механизм, который реализует доставку секрета в ENV через mutating webhook, init-контейнер и запуск оригинальной команды через execve.
Если одновременно используются:
- аннотация
secrets-store.deckhouse.io/env-from-path; - и явно заданная переменная окружения с тем же именем,
приоритет получает значение из аннотации env-from-path.
Сравнение сценариев
| Архитектурная модель | Механизм реализации | Как приложение получает данные | Где хранится в Kubernetes | Потребление ресурсов |
|---|---|---|---|---|
| Приложение получает секрет самостоятельно | Прямой доступ приложения | Напрямую из хранилища секретов | Не хранится | Не меняется |
| Платформа доставляет секрет через файл | CSI | Из дискового тома (как файл) | Не хранится | Два пода на каждый узел (DaemonSet) |
| Платформа доставляет секрет через переменные окружения | Инъекция entrypoint | Секреты доставляются из хранилища в момент запуска приложения в виде переменных окружения | Не хранится | Один под на каждый узел (DaemonSet) |
Что учитывать при выборе
- Если приложение можно модифицировать, предпочтителен прямой доступ приложения к хранилищу как наиболее безопасный вариант.
- Если приложение умеет читать секреты из файлов, используйте доставку через CSI.
- Если приложение нельзя изменить и ему нужны переменные окружения, используйте инъекцию переменных окружения.
Ограничения и особенности
- При использовании CSI запуск пода блокируется до тех пор, пока секреты не будут прочитаны из хранилища и записаны в том.
- При подходе, где используются дополнительные контейнеры, число метрик по контейнерам увеличивается, так как сбор метрик выполняется с каждого контейнера.