Какие варианты хранения и управления секретами (secrets) вы знаете в Kubernetes?

В Kubernetes есть несколько подходов к управлению секретами, и выбор зависит от требований безопасности и сложности инфраструктуры.

1. Встроенный ресурс Secret: Базовый способ. Данные хранятся в etcd, по умолчанию в base64 (не шифрование). Я использую его для некритичных данных в dev-средах или когда кластер хорошо изолирован.

apiVersion: v1
kind: Secret
metadata:
  name: postgres-credentials
type: Opaque
data:
  username: YWRtaW4= # admin
  password: cG9zdGdyZXM= # postgres

Подам он монтируется как volume или переменные окружения. Недостаток: Без дополнительного шифрования at-rest для etcd секреты уязвимы.

2. External Secret Stores (Интеграция с внешними системами): Для продакшена я предпочитаю не хранить секреты в etcd, а получать их динамически из специализированных хранилищ.

• HashiCorp Vault: Наиболее гибкое решение. Использую Vault Sidecar Injector или CSI Provider. Поды получают временные токены через Service Account, а CSI драйвер монтирует секреты как файлы в pod.
• Cloud Provider Secrets Manager:
  • AWS: Использую External Secrets Operator (ESO) или Secrets Store CSI Driver для AWS Secrets Manager/Parameter Store. Оператор автоматически создает k8s Secret из значения в AWS.
  • Azure/GCP: Аналогично, через свои CSI драйверы для Key Vault и Secret Manager.

3. GitOps-дружественные зашифрованные секреты: Когда вся конфигурация хранится в Git, нельзя коммитить plain-text секреты.

• Sealed Secrets (Bitnami): Шифрую секрет локально с помощью публичного ключа кластера. В Git попадает только зашифрованный SealedSecret CRD, который может расшифровать только контроллер внутри целевого кластера (с приватным ключом).
• SOPS + Age/GPG: Шифрую YAML-файлы с секретами целиком с помощью SOPS перед коммитом. В CI/CD пайплайне или с помощью init-контейнера расшифровываю их при развертывании, используя ключ из k8s Secret или внешнего источника.

4. Шифрование на уровне etcd: Это дополнительный уровень защиты. Настраиваю EncryptionConfiguration для kube-apiserver, чтобы данные ресурсов Secret шифровались перед записью в etcd, используя ключи из KMS (например, AWS KMS, GCP KMS). Это защищает от компрометации raw etcd backups.

Моя типичная схема: Для продакшена в облаке — External Secrets Operator + AWS Secrets Manager. Для on-prem или гибридных сред — HashiCorp Vault с CSI. Sealed Secrets отлично подходят для сред, где Git — единственный источник истины, а доступ к облачным KMS ограничен.