Каждый кластер Kubernetes поставляется со встроенным объектом Secret. Это похоже на безопасность. Это похоже на безопасность. Это не безопасность.
Секрет Kubernetes по умолчанию представляет собой просто строку в кодировке Base64, хранящуюся в etcd, которую может прочитать любой, у кого есть доступ к кластеру, и тривиально декодировать с помощью однострочной строки: echo "c2VjcmV0" | base64 -д. Если вы явно не включили шифрование в состоянии покоя (а большинство команд этого не сделали), пароли вашей базы данных, токены API и закрытые ключи TLS находятся в незашифрованном виде в хранилище данных плоскости управления вашего кластера. Передайте Git манифест Kubernetes, содержащий «Секрет», и эти учетные данные навсегда останутся в истории вашего репозитория.
Это проблема, для решения которой появилось новое поколение инструментов управления секретами, и в 2026 году экосистема значительно повзрослела. В этом руководстве рассматриваются шесть наиболее важных инструментов для управления секретами в средах Kubernetes: что они делают, чего не делают и какой из них соответствует уровню зрелости вашей команды.
Связанное чтение: Если вас беспокоит утечка секретов через ваш конвейер CI/CD, ознакомьтесь с нашим сводкой лучших инструментов конвейера CI/CD. Чтобы получить более широкую картину безопасности контейнеров, ознакомьтесь с нашим руководством по инструментам сканирования уязвимостей.
Почему секреты Kubernetes по умолчанию не работают
Прежде чем углубляться в инструменты, стоит точно определить, чего не хватает Kubernetes Secrets, потому что понимание этого пробела — это то, что позволяет вам выбрать правильное решение.
По умолчанию неактивное шифрование отсутствует. etcd хранит секреты Kubernetes в формате Base64, а не в зашифрованном виде. Включение Шифрование при хранении — это этап настройки на уровне кластера, который управляемые поставщики Kubernetes (EKS, GKE, AKE) обрабатывают по-разному, а многие самоуправляемые кластеры полностью его пропускают.
Нет ротации секретов. Для секрета Kubernetes не существует встроенного механизма, позволяющего узнать, что его резервные учетные данные изменились. Вы меняете пароль базы данных извне, и ваши модули продолжают использовать старый, пока вы вручную не обновите секрет и не перезапустите затронутые модули.
Нет журнала аудита для секретного доступа. Стандартный журнал аудита Kubernetes записывает изменения секретных объектов, но в большинстве конфигураций отдельные операции чтения не регистрируются — это означает, что вы не можете ответить «какая служба получила доступ к этому токену и когда?»
Git враждебен по замыслу. Стандартный совет: «никогда не передавайте секреты в Git». Но в мире GitOps, где целью является все как код, поддерживать такое исключение — болезненное исключение.
RBAC как простой инструмент. Kubernetes RBAC позволяет предоставлять или запрещать доступ к секретным объектам на уровне пространства имен. Он не может выражать «Служба A может читать секрет X, но не секрет Y» или «Срок действия этого секрета истекает через 24 часа».
Ничто из этого не является причиной отказа от Kubernetes — это причины использовать поверх него специальные инструменты управления секретами.
TL;DR — Сравнение функций
| Инструмент | Шифрование в состоянии покоя | Динамические секреты | Журналы аудита | K8s родной | Мультиоблако | Цены |
|---|---|---|---|---|---|---|
| Хранилище ХашиКорп | ✅ | ✅ | ✅ | ⚠️ (через агента) | ✅ | OSS бесплатно / HCP платно |
| Оператор внешних секретов | ✅ (через бэкэнд) | ✅ (через бэкэнд) | ✅ (через бэкэнд) | ✅ | ✅ | Бесплатно / OSS |
| Засекреченные секреты | ✅ | ❌ | ❌ | ✅ | ❌ | Бесплатно / OSS |
| Менеджер секретов AWS | ✅ | ✅ | ✅ | ⚠️ (через ESO/CSI) | ❌ (только для AWS) | Цена за секрет |
| Допплер | ✅ | ❌ | ✅ | ✅ (оператор) | ✅ | Бесплатные → платные уровни |
| Несущественный | ✅ | ✅ | ✅ | ✅ (оператор) | ✅ | OSS/платное облако |
⚠️ = требуются дополнительные компоненты
1. Хранилище HashiCorp — золотой стандарт корпоративных секретов
HashiCorp Vault — это эталон, по которому оцениваются все остальные инструменты управления секретами. Он прошел боевые испытания в корпоративных средах в течение почти десяти лет, и его набор функций отражает эту глубину.
Основная функция Vault — динамические секреты — учетные данные, которые генерируются по требованию и срок действия которых истекает автоматически. Вместо хранения статического пароля PostgreSQL Vault генерирует уникальную пару имени пользователя и пароля для каждой запрашивающей службы, действительную в течение настраиваемого периода аренды (например, одного часа). По истечении срока аренды удостоверение аннулируется. Это устраняет разрастание целых классов учетных данных и значительно облегчает сдерживание нарушений.
Для Kubernetes путями интеграции являются Vault Agent Injector или Оператор секретов хранилища. Инжектор работает как изменяющийся веб-перехватчик, который автоматически подключает агент Vault к вашим модулям, который выполняет аутентификацию в Vault с использованием учетной записи службы Kubernetes модуля и записывает секреты в общий том в памяти. Оператор Vault Secrets (VSO), новый подход, синхронизирует секреты Vault с собственными секретными объектами Kubernetes — более знакомыми операторам, за счет секретов, недолго существовавших в etcd.
Секретные двигатели Убежища охватывают впечатляющий диапазон:
- Учетные данные базы данных (PostgreSQL, MySQL, MongoDB и т. д.)
- Динамические учетные данные AWS, GCP, Azure.
- Генерация сертификатов PKI и TLS
- Подписание сертификата SSH
- Токены сервисного аккаунта Kubernetes
Чем Сейф хорош: Динамические учетные данные, детальные политики доступа, подробный журнал аудита и развитая экосистема плагинов. Если вам необходимо управление секретами на уровне соответствия требованиям с полной информацией о том, кто и когда имел доступ, Vault часто является единственным разумным вариантом.
На что следует обратить внимание: У Хранилища есть сложности в работе. Запуск его в режиме высокой доступности требует пристального внимания к серверным модулям хранения (теперь рекомендуется использовать Raft), процедурам распечатывания и путям обновления. Кривая обучения реальна. Бюджет времени на разработку платформы.
Цена: Версия с открытым исходным кодом бесплатна и удовлетворяет большинству потребностей. HashiCorp Cloud Platform (HCP) Vault — это управляемое предложение, цены которого основаны на часах работы кластера и секретных операциях. Изменение лицензии BSL в 2023 году привело к появлению форка OpenTofu для Terraform, но эквивалент форка Vault (OpenBao) все еще находится на стадии разработки.
📚 Рекомендуем к прочтению: Hacking Kubernetes Эндрю Мартина и Майкла Хаузенбласа — отличное описание поверхностей атак Kubernetes, включая сценарии секретной эксфильтрации.
2. Оператор внешних секретов (ESO) — уровень интеграции K8s-Native.
Внешний оператор секретов занимает принципиально иную архитектурную позицию: он не является хранилищем секретов сам по себе, а является мостом между Kubernetes и любым внешним хранилищем, которое у вас уже есть. ESO синхронизирует секреты из AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler и растущего списка других бэкэндов с собственными секретными объектами Kubernetes.
Основная абстракция — это пользовательский ресурс «ExternalSecret»:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: database-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets-manager
kind: ClusterSecretStore
target:
name: db-creds
data:
- secretKey: password
remoteRef:
key: production/db/password
ESO просматривает этот ресурс, извлекает секрет из AWS Secrets Manager (или откуда-то еще) и создает стандартный секрет Kubernetes. Ваше приложение читает db-creds так же, как и любой другой секрет Kubernetes — никаких изменений кода не требуется. Когда установлен флажок RefreshInterval, ESO автоматически повторно извлекает и обновляет секрет.
Почему ESO так популярна в 2026 году: Она хорошо сочетается с существующими инвестициями. В вашей организации уже есть AWS Secrets Manager (или Vault, или GCP Secret Manager) — ESO просто делает эти секреты доступными для использования в Kubernetes, не меняя код приложения или существующие рабочие процессы ротации секретов.
ESO или оператор секретов Vault? Если вы используете Vault, VSO имеет более тесную интеграцию с конкретным хранилищем (динамические секреты Vault, Vault PKI). Если вы используете собственное секретное хранилище облачного провайдера, ESO — более чистый выбор. Многие команды используют оба варианта — ESO для статических секретов, хранящихся в облаке, и VSO для динамических учетных данных, управляемых Vault.
Цены: ESO — бесплатная версия с открытым исходным кодом (Apache 2.0), поддерживаемая проектом песочницы CNCF при сильной поддержке сообщества.
3. Запечатанные секреты — зашифрованные секреты, дружественные к GitOps
Sealed Secrets от Bitnami решает конкретную проблему: как хранить манифесты Kubernetes Secret в Git без сохранения фактического открытого текста? Ответ — асимметричное шифрование.
Контроллер Sealed Secrets работает в вашем кластере и хранит закрытый ключ. Интерфейс командной строки kubeseal шифрует секретный манифест Kubernetes с помощью открытого ключа кластера, создавая CRD SealedSecret. Этот зашифрованный манифест можно безопасно передать в Git — его можно расшифровать только закрытым ключом кластера, и его можно расшифровать только в этом конкретном кластере (по умолчанию зашифрованный текст привязан к пространству имен + имени).
# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
--from-literal=password=s3cr3t \
--dry-run=client -o yaml | \
kubeseal --format=yaml > db-creds-sealed.yaml
# This file is safe to commit
git add db-creds-sealed.yaml
Когда вы применяете «SealedSecret» к кластеру, контроллер расшифровывает его и создает соответствующий объект «Secret».
Что хорошо в Sealed Secrets: Рабочие процессы GitOps. Если вы используете Argo CD или Flux и хотите, чтобы каждый ресурс кластера (включая секреты) декларативно хранился в Git, Sealed Secrets идеально подходит для этой модели. Он не требует никаких внешних зависимостей, кроме контроллера внутри кластера.
Чего он не делает: Ротация, динамические учетные данные и ведение журнала аудита помимо стандартных событий Kubernetes. Sealed Secrets — это решение для хранения Git, а не полноценная платформа для управления секретами. Если ваш пароль изменится, вы повторно зашифруете и снова зафиксируете его.
Резервное копирование закрытого ключа имеет решающее значение. Если вы потеряете закрытый ключ контроллера, вы потеряете возможность расшифровать свои запечатанные секреты. Создайте резервную копию секретного ключа «sealed-secrets-key» в отдельном безопасном месте.
Цены: Полностью бесплатное приложение с открытым исходным кодом (Apache 2.0).
4. Менеджер секретов AWS с Kubernetes
Если ваши рабочие нагрузки выполняются в основном на EKS (или активно подключаются к сервисам AWS), вам подойдет AWS Secrets Manager в сочетании с Secrets Store CSI Driver или внешним оператором секретов. Вы храните секреты в управляемом, зашифрованном хранилище с журналами аудита AWS и при необходимости извлекаете их в Kubernetes.
Драйвер Secrets Store CSI (SSCSID) — это подход, поддерживаемый CNCF: секреты монтируются непосредственно в модули в виде файлов через том CSI и никогда не записываются в etcd как секретные объекты Kubernetes. Это путь с наивысшим уровнем безопасности — секреты существуют в памяти модуля, но не в хранилище секретов Kubernetes.
volumes:
- name: secrets-store
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: aws-secrets
Встроенные возможности AWS Secrets Manager включают автоматическую ротацию поддерживаемых сервисов (RDS, Redshift, DocumentDB и Lambda для пользовательской ротации), доступ к нескольким учетным записям и глубокую интеграцию CloudTrail для отслеживания аудита соответствия.
Учет затрат: AWS Secrets Manager взимает плату за каждый секрет в месяц и за каждый вызов API. Для больших автопарков с множеством мелких секретов затраты могут возрасти. См. наше руководство по оптимизации затрат на облако для получения информации о стратегиях управления расходами на AWS, связанными с секретностью.
Наилучший вариант для: команды разработчиков EKS, уже инвестировавшие средства в экосистему AWS, которым требуется тесная интеграция IAM и собственная ротация учетных данных RDS.
5. Doppler — первая секретная платформа SaaS для разработчиков
Doppler использует подход SaaS, в котором опыт разработчиков ставится выше сложности эксплуатации. Вы определяете секреты в пользовательском интерфейсе Doppler (или через CLI/API), организуете их по средам (разработка, промежуточное исполнение, производство), а оператор Doppler Kubernetes автоматически синхронизирует их с Kubernetes Secrets.
Оператор опрашивает Doppler на наличие изменений и обновляет соответствующий секрет Kubernetes, при необходимости запуская перезапуск модуля при изменении секретов. Настройка представляет собой установку одной диаграммы Helm:
helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator
Где сияет Doppler: Локальная разработка и интеграция CI/CD с Kubernetes. Doppler CLI полностью заменяет файлы среды («doppler run – your-command»), предоставляя одни и те же секреты в локальной, CI и производственной средах. Для конвейеров CI/CD встроенная интеграция Doppler с GitHub Actions, CircleCI и другими устраняет необходимость копировать секреты в переменные среды конвейера.
Что не охватывает Doppler: Учетные данные динамической базы данных. Doppler — это статическое хранилище секретов с историей версий и журналом аудита, а не механизм генерации секретов, такой как Vault.
Цены: Doppler предлагает бесплатный уровень для небольших команд. Платные планы добавляют единый вход, запросы доступа и функции обеспечения соответствия. Проверьте страницу цен Doppler, чтобы узнать текущие уровни (цены изменились; проверьте перед составлением бюджета).
6. Infisical — альтернатива хранилищу с открытым исходным кодом
Infisical является сильнейшим конкурентом дуополии Vault/Doppler с открытым исходным кодом. Он предоставляет веб-интерфейс, интерфейс командной строки, пакеты SDK и оператора Kubernetes, которые можно развернуть самостоятельно или использовать в качестве облачной службы.
В 2024 году Infisical добавила поддержку динамических секретов, нацеленную на создание учетных данных базы данных, аналогично механизму секретов базы данных Vault. Оператор Infisical Kubernetes синхронизирует CRD InfisicalSecret с собственными секретами Kubernetes с настраиваемыми интервалами обновления.
Для команд, которым нужен UX-уровень SaaS (веб-панель, рабочие процессы запросов доступа, журналы аудита), но которые не могут использовать внешний SaaS из-за требований соответствия, автономный хостинг Infisical является привлекательным. Им значительно проще управлять, чем Vault, и он более удобен для разработчиков.
Цены: Ядро с открытым исходным кодом бесплатно. Облачная версия имеет бесплатный уровень и платные планы для расширенных функций. Самостоятельная корпоративная лицензия доступна для сред с высокими требованиями к соблюдению требований.
📚 Для более глубокого изучения архитектуры безопасности Kubernetes: Kubernetes Security and Observability на Amazon охватывает секреты, RBAC, сетевую политику и безопасность во время выполнения в одной связной структуре.
Советы по реализации
Начните с шифрования неактивных данных. Прежде чем добавлять какие-либо дополнительные инструменты, включите шифрование неактивных файлов Kubernetes и etcd. Для управляемых кластеров это часто один флажок. Для самоуправляемых кластеров следуйте официальному руководству. Это немедленно повысит ваш базовый уровень безопасности.
Примените RBAC с наименьшими привилегиями для секретов. Проверяйте, какие учетные записи служб имеют разрешения «получить», «список» или «просмотр» для секретных объектов. Учетные записи служб по умолчанию во многих диаграммах Helm имеют избыточное количество ресурсов. Затяните RBAC перед переключением на внешний накопитель.
Планируйте соглашения об именах секретов заранее. Секреты быстро распространяются. Последовательная иерархия ({env}/{service}/{credential-type}) значительно упрощает автоматизацию, политики RBAC и рабочие процессы ротации для всех инструментов.
Не пропускайте секретное тестирование ротации. Какой бы инструмент вы ни выбрали, запустите тренировку по ротации до того, как она вам понадобится. Убедитесь, что ваше приложение получает новые учетные данные без простоя. Динамические секреты с помощью Vault или ESO значительно упрощают эту задачу, чем статические секреты, обновляемые вручную.
Отслеживайте разрастание секретов. По мере роста вашей платформы секреты накапливаются. Интегрируйте отчеты по управлению секретами в информационные панели разработки вашей платформы. См. наше Руководство по инструментам мониторинга Kubernetes для получения информации об инструментах наблюдения, которые могут отслеживать шаблоны секретного доступа.
Какой инструмент для какой команды?
Небольшая команда, работающая в облаке (AWS/GCP/Azure): Начните с внешнего оператора секретов, подключающегося к собственному секретному хранилищу вашего облачного провайдера. Минимальные эксплуатационные накладные расходы, надежная интеграция аудита, бесплатно.
Команда GitOps-first (Argo CD/Flux): Sealed Secrets для конфигурации, хранимой в GitOps, в сочетании с ESO для конфиденциальных учетных данных времени выполнения, которые не должны храниться в Git даже в зашифрованном виде.
Предприятие с требованиями соответствия (SOC 2, PCI, HIPAA): HashiCorp Vault — либо автономный кластер Raft, либо управляемый HCP Vault. Журнал аудита, динамические учетные данные и механизм детальной политики трудно воспроизвести где-либо еще.
Смешанная среда, ориентированная на опыт разработчиков (K8s + локальная + CI/CD): Doppler для унифицированного DX во всех средах или автономное размещение Infisical, если местонахождение данных имеет значение.
Большая команда платформы, управляющая многокластерными средами: Внешний оператор секретов в качестве уровня абстракции на стороне K8s, поддерживаемый Vault или облачным хранилищем. Централизация источника правды в одном хранилище при использовании ESO в качестве универсального адаптера между кластерами — хорошо зарекомендовавшая себя модель в 2026 году.
По теме: Информацию об угрозах безопасности, которые инструменты ИИ-кодирования вносят в ваши манифесты Kubernetes и конвейеры CI/CD, см. в нашем руководстве по рискам безопасности кодирования vibe в 2026 году.