Какие знаешь варианты хранения секретов в Kubernetes?

Варианты хранения секретов в Kubernetes

Как DevOps инженер с более чем 10-летним опытом работы с Kubernetes, я могу выделить несколько подходов к хранению секретов, каждый из которых имеет свои особенности использования в разных сценариях.

Нативные ресурсы Kubernetes - Secrets

Базовый вариант - использование встроенного ресурса Secret. Хотя это самый простой способ, у него есть важные ограничения:

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  database-password: c3VwZXJfc2VjcmV0X3Bhc3N3b3JkCg==  # base64 encoded
  api-key: YW5vdGhlcl9zZWNyZXRfa2V5Cg==

Особенности:

• Секреты хранятся в base64-кодировке (не шифрование!)
• По умолчанию хранятся в etcd незашифрованными
• Можно включить шифрование на уровне etcd через EncryptionConfiguration
• Подходят для простых случаев, но недостаточны для production-сред

Внешние системы управления секретами (Hashicorp Vault)

Hashicorp Vault - промышленный стандарт для enterprise-сред:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-vault
spec:
  template:
    spec:
      containers:
      - name: app
        image: myapp:latest
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: vault-agent-secret
              key: db_password
      initContainers:
      - name: vault-agent
        image: vault:latest
        # Vault Agent для получения секретов

Преимущества Vault:

• Динамические секреты - временные credentials для БД, сервисов
• Lease management - автоматический ротация секретов
• Audit logging - детальное логирование доступа
• Fine-grained policies - тонкая настройка прав доступа
• Multiple backends - поддержка различных storage backends

Cloud-специфичные решения

Для облачных сред существуют интегрированные решения:

• AWS: Secrets Manager + Secrets Store CSI Driver или Parameter Store
• Azure: Azure Key Vault + Secrets Store CSI Driver
• GCP: Secret Manager + Secrets Store CSI Driver

Пример использования AWS Secrets Manager через CSI driver:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: aws-secrets
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "prod/db/password"
        objectType: "secretsmanager"

Sealed Secrets от Bitnami

Интересный подход для GitOps workflow - Sealed Secrets:

# Локальное шифрование секрета
kubeseal --format=yaml < secret.yaml > sealed-secret.yaml

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: my-sealed-secret
spec:
  encryptedData:
    password: AgBy3i4OJSWK+PiTySYZZA9rO43...

Принцип работы:

1. Секрет шифруется публичным ключом
2. Зашифрованный секрет можно хранить в Git
3. Расшифровка происходит только внутри кластера
4. Идеально для GitOps-практик

External Secrets Operator (ESO)

External Secrets Operator - популярный CRD-based подход для синхронизации секретов из внешних систем:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secret-store
    kind: SecretStore
  target:
    name: k8s-secret
  data:
  - secretKey: password
    remoteRef:
      key: /prod/database/password
      property: value

Сравнение подходов

Критические рекомендации по безопасности

Из моего опыта, ключевые практики включают:

1. Никогда не храните raw секреты в Git - даже в private repositories
2. Регулярная ротация секретов - автоматизируйте процесс
3. Principle of least privilege - минимальные необходимые права
4. Audit trails - обязательно логируйте доступ к секретам
5. Network policies - ограничьте доступ к etcd и системам управления секретами
6. Pod Security Standards - используйте ограниченные security contexts

Архитектурные соображения

Выбор решения зависит от:

• Комплаенс-требований (PCI DSS, HIPAA, GDPR)
• Гибридности среды (on-prem, multi-cloud)
• Существующей инфраструктуры (уже используется Vault или облачные сервисы)
• Команды и экспертизы - сложные решения требуют соответствующей экспертизы
• Бюджета - enterprise-решения имеют стоимость лицензирования

В production-средах я обычно рекомендую комбинированный подход: Vault для критичных секретов + External Secrets Operator для интеграции + нативные Secrets для нечувствительных конфигураций. Это обеспечивает баланс между безопасностью, удобством использования и maintainability.