Нужно выбрать способ доставки секретов в Pod'ы Kubernetes: обычные Kubernetes Secrets, Vault Agent Injector (sidecar) или External Secrets Operator. Как сравнить эти варианты при диагностике требований конкретного проекта?

Короткий ответ

Выбор зависит от того, где должен жить источник правды для секрета и насколько важна динамическая ротация: обычный Kubernetes Secret проще, но статичен и слабо защищён без доп. мер; Vault Agent Injector даёт динамические, короткоживущие секреты прямо в Pod через sidecar, но усложняет инфраструктуру; External Secrets Operator синхронизирует секреты из внешнего хранилища (Vault, AWS Secrets Manager) в обычный Kubernetes Secret, сочетая простоту использования приложением с централизованным управлением источником.

Как это работает подробнее

Kubernetes Secret хранится в etcd (в base64, опционально зашифрованно) и доступен приложению как переменная окружения или volume — простой механизм без встроенной ротации. Vault Agent Injector добавляет sidecar-контейнер, который сам получает секрет из Vault по токену Pod'а (через Kubernetes auth method) и обновляет файл на volume при истечении TTL, не требуя хранения значения в etcd вообще. External Secrets Operator работает по-другому: периодически вытягивает значение из внешнего хранилища и создаёт/обновляет обычный Kubernetes Secret, который приложение потребляет как привычно.

Пример кода

security-example-462.yamlКопировать

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: secret/data/prod/db
        property: password

Что использовать на практике

• Практика. для простых проектов без строгих требований к ротации достаточно обычного Secret с шифрованием etcd и строгим RBAC; если нужна полная динамика (короткоживущие БД-креды, выписываемые Vault на лету) — Vault Agent Injector; если нужна централизация во внешнем хранилище, но без изменения кода приложения и без sidecar — External Secrets Operator.
• Проверка. Ожидаемое поведение: External Secrets Operator создаёт/обновляет обычный Kubernetes Secret db-credentials, подставляя значение из Vault; при смене пароля в Vault и наступлении интервала синхронизации (refreshInterval) значение Secret автоматически обновится — проверяется сравнением содержимого Secret до и после изменения значения в Vault.

Подводные камни

• Ошибка. внедрять Vault Agent Injector «потому что это современно» для проекта без реальной потребности в динамических секретах, усложняя эксплуатацию без выигрыша; использовать ESO, но не ограничивать RBAC на созданный Kubernetes Secret, обесценивая смысл централизации; не учитывать задержку синхронизации ESO при проектировании сценариев быстрой ротации по инциденту.