Как правильно организовать secrets в Kubernetes в 2026 — Vault, External Secrets или просто sealed-secrets?

[py_wizard]

Поднимаем новый проект, k8s 1.32 на bare metal (три мастера, восемь воркеров). Нужно решить как хранить секреты: пароли БД, API-ключи сторонних сервисов, TLS-сертификаты. Вижу три варианта: HashiCorp Vault (сложно, но мощно), External Secrets Operator с каким-то бекендом, или Sealed Secrets (просто, но ограничено). Команда небольшая, два DevOps. Посоветуйте с чего начать.

[barbs]

Для двух DevOps и нового проекта — начните с External Secrets Operator (ESO) + любой managed-бекенд. Если есть доступ к Yandex Cloud — там есть Lockbox, ESO умеет с ним работать из коробки. Если всё on-prem — поднимайте Vault в dev-режиме для старта, потом переведёте на HA. Главное преимущество ESO: секреты живут в внешней системе, в Git и в etcd попадает только `ExternalSecret`-манифест без значений.

[burneddeadlock]

Sealed Secrets — отличный выбор для старта, не надо недооценивать. `kubeseal` шифрует секрет публичным ключом кластера, зашифрованный yaml можно коммитить в Git, расшифровать может только этот кластер. Никакого внешнего бекенда, никаких зависимостей. Мы так работаем на трёх prod-кластерах уже два года. Минус один: если потеряли приватный ключ кластера — всё, надо перешифровывать все секреты. Делайте бекап ключа обязательно.

[barbs]

@burneddeadlock, Vault — это правильно, но порог входа высокий. Мы потратили три недели чтобы нормально поднять Vault HA на трёх нодах с auto-unseal через Yandex KMS. Зато потом получили: динамические секреты для PostgreSQL (пароли ротируются каждые час автоматически), PKI для внутренних TLS, audit log кто что читал. Если у вас compliance-требования — без Vault не обойтись.

[ralfalfa]

@barbs, Рекомендую ESO + Vault как финальная цель, но стартуйте с ESO + Yandex Lockbox или AWS SSM если есть доступ. Когда команда вырастет — мигрируете на Vault, поменяв только `SecretStore` в ESO. Сами `ExternalSecret` манифесты не меняются. Это правильная стратегия для небольшой команды: не хоронить полгода в настройке Vault когда можно запуститься за день.

[tor2000]

Важный момент который все забывают: ротируйте secrets encryption key в etcd. По умолчанию k8s хранит секреты в etcd в base64, не зашифрованными. Включите `EncryptionConfiguration` с провайдером `aescbc` или `secretbox`. Это первое что нужно сделать на новом кластере до всего остального.

[hogan20]

@burneddeadlock, Ещё вариант который набирает популярность — CSI Secrets Store driver. Монтирует секреты из Vault/AWS SSM/Azure KeyVault прямо как volume в под, без создания k8s Secret объектов вообще. Секрет существует только в памяти пода, в etcd не попадает никак. Для параноиков по безопасности — самое то. Из минусов: нет env-переменных из коробки (только файлы), некоторые приложения не умеют читать секреты из файлов.

[kernel_veteran]

@tor2000, про EncryptionConfiguration — абсолютно верно, это часто первое что забывают. Добавлю: после включения шифрования уже существующие секреты в etcd остаются в незашифрованном виде до тех пор, пока их не пересоздадут. Нужно явно прогнать `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` чтобы зашифровать все текущие объекты. Без этого шага EncryptionConfiguration защищает только новые секреты.

[kotlin123]

Для команды из двух DevOps на старте проекта оптимальная последовательность примерно такая: сначала включить EncryptionConfiguration в etcd (час работы, нулевые зависимости), потом поднять ESO с простым бекендом — Sealed Secrets если всё on-prem и нет managed-облака, Lockbox/SSM если есть. Vault оставить на момент когда появятся реальные compliance-требования или потребность в динамических credentials для БД. Главное — ESO как слой абстракции с самого начала, чтобы переход на Vault в будущем не требовал переписывания манифестов деплоя.

[norym]

@burneddeadlock, Sealed Secrets недооценивают незаслуженно, согласен. Но есть ещё один минус помимо потери ключа: ротация секрета требует пересоздания SealedSecret-объекта и нового коммита в Git. При большом числе секретов и частой ротации (например, API-ключи партнёров) это ручная работа. Для статичных секретов типа TLS-сертификатов или паролей БД с редкой ротацией — идеально. Для динамической ротации Vault с его lease-механизмом реально удобнее.