Керування Секретами Kubernetes у 2026: External Secrets, Vault та Питання для Співбесід

Керування секретами Kubernetes залишається одним із найважливіших викликів безпеки в оркестрації контейнерів. Нативні Kubernetes Secrets зберігають чутливі дані як закодовані в base64 значення, що не забезпечує шифрування в стані спокою за замовчуванням і створює ризики безпеки, які інтерв'юери часто досліджують під час процесів найму DevOps.

Чому Нативні Kubernetes Secrets Недостатні

Вбудований ресурс Secret зберігає дані в etcd з кодуванням base64. Це кодування можна скасувати однією командою:

# decoding-secret.sh
# Decode any Kubernetes secret value instantly
kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d

Base64 — це не шифрування. Будь-хто з доступом до кластера може прочитати значення секретів. Документація Kubernetes явно попереджає, що Secrets "не зашифровані за замовчуванням" і рекомендує увімкнути шифрування в стані спокою.

Три основні обмеження впливають на продакшн розгортання:

1. Відсутність аудит-логів: Нативні Secrets не логують хто, коли і до якого значення отримав доступ
2. Відсутність механізму ротації: Зміна секрету вимагає ручного втручання та перезапуску подів
3. Несумісність з GitOps: Зберігання зашифрованих секретів у Git все одно оголює проблему керування ключами шифрування

Архітектура External Secrets Operator

External Secrets Operator (ESO) з'єднує Kubernetes із зовнішніми системами керування секретами. Випущений як проект CNCF Sandbox у 2023 році та досягнувши версії v0.10 у 2026, ESO підтримує AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault та 15 інших бекендів.

Архітектура включає три користувацькі ресурси:

# secret-store.yaml
# ClusterSecretStore defines the connection to Vault
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "external-secrets"
          serviceAccountRef:
            name: "external-secrets"
            namespace: "external-secrets"

Цей ClusterSecretStore налаштовує ESO для автентифікації з Vault за допомогою токенів service account Kubernetes. Метод автентифікації kubernetes валідує JWT service account через TokenReview API кластера.

# external-secret.yaml
# ExternalSecret fetches and syncs the actual secret data
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-secret
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/database
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

ESO опитує Vault щогодини (refreshInterval: 1h) та автоматично оновлює Kubernetes Secret. Налаштування creationPolicy: Owner гарантує видалення Secret при видаленні ExternalSecret.

Патерни Інтеграції HashiCorp Vault

Vault надає динамічні секрети, автоматичну ротацію та комплексне аудит-логування. Метод автентифікації Kubernetes, задокументований у документації Vault Kubernetes Auth, дозволяє подам автентифікуватися без розповсюдження довготривалих облікових даних.

Налаштування автентифікації Vault вимагає трьох кроків:

# vault-k8s-auth.sh
# Enable Kubernetes auth method in Vault
vault auth enable kubernetes

# Configure Vault to validate tokens against the Kubernetes API
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc:443" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# Create a role that binds service accounts to policies
vault write auth/kubernetes/role/external-secrets \
  bound_service_account_names=external-secrets \
  bound_service_account_namespaces=external-secrets \
  policies=readonly-secrets \
  ttl=1h

Ця конфігурація прив'язує service account external-secrets до політики Vault. TTL обмежує термін дії токена, примушуючи до повторної автентифікації та зменшуючи радіус ураження при компрометації токенів.

Для продакшн розгортань політика повинна дотримуватися принципу найменших привілеїв:

# readonly-secrets.hcl
# Vault policy granting read-only access to specific paths
path "secret/data/production/*" {
  capabilities = ["read"]
}

path "secret/metadata/production/*" {
  capabilities = ["list"]
}

Ця політика надає доступ лише для читання до шляху продакшн секретів. Команди, що керують різними середовищами, отримують окремі політики з відповідними обмеженнями шляхів.

Ротація Секретів Без Простою

Автоматична ротація запобігає перетворенню секретів на застарілі вектори атак. ESO обробляє сторону Kubernetes, але застосунок повинен перезавантажувати секрети без перезапуску.

Існують два підходи для ротації без простою:

Секрети, змонтовані як volumes з відстеженням файлів:

# deployment-volume-secrets.yaml
# Mount secrets as files that update automatically
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
        - name: api
          image: api:v2.1.0
          volumeMounts:
            - name: secrets
              mountPath: /etc/secrets
              readOnly: true
      volumes:
        - name: secrets
          secret:
            secretName: db-secret

Kubernetes оновлює змонтовані файли секретів протягом періоду синхронізації kubelet (за замовчуванням 1 хвилина). Застосунок зчитує облікові дані з /etc/secrets/password при кожному з'єднанні з базою даних, отримуючи нові значення без перезапуску.

Reloader для секретів змінних середовища:

Застосунки, що використовують змінні середовища, вимагають перезапуску подів. Stakater Reloader автоматизує цей процес:

# deployment-with-reloader.yaml
# Annotation triggers rolling restart when secret changes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  annotations:
    reloader.stakater.com/auto: "true"
spec:
  template:
    spec:
      containers:
        - name: api
          envFrom:
            - secretRef:
                name: db-secret

Reloader відстежує оновлення Secrets та виконує поступові перезапуски, підтримуючи доступність протягом ротації.

Питання для Співбесід про Kubernetes Secrets

Співбесіди DevOps постійно тестують розуміння керування секретами. Ці питання з'являються на всіх рівнях від junior до senior:

П: Яке кодування використовують Kubernetes Secrets і чому це недостатньо для безпеки?

Secrets використовують кодування base64, яке є оборотною трансформацією, а не шифруванням. Будь-який користувач з правами get на Secrets може декодувати значення. Безпека вимагає шифрування в стані спокою (увімкнення шифрування etcd) та обмеження прав RBAC. Для глибшого розуміння концепцій Kubernetes варто переглянути основи співбесід з Kubernetes.

П: Як запобігти появі секретів у Git репозиторіях при використанні GitOps?

External Secrets Operator зберігає в Git лише посилання на секрети, а не самі значення. Маніфест ExternalSecret містить шлях до секрету в Vault або AWS Secrets Manager, тоді як фактичний секрет ніколи не потрапляє до репозиторію. Sealed Secrets від Bitnami пропонує альтернативний підхід з використанням асиметричного шифрування.

П: Поясніть різницю між SecretStore та ClusterSecretStore.

SecretStore обмежений namespace: ExternalSecrets у тому ж namespace можуть посилатися на нього. ClusterSecretStore доступний у всьому кластері: будь-який namespace може посилатися на нього. ClusterSecretStore використовується коли кілька команд спільно використовують один екземпляр Vault, а SecretStore — коли кожен namespace має ізольовані бекенди секретів.

П: Pod не може отримати доступ до своїх секретів після розгортання. Як провести діагностику?

Починати слід зі статусу ExternalSecret:

# troubleshoot-secrets.sh
# Check ExternalSecret sync status and conditions
kubectl get externalsecret database-credentials -o yaml

# Verify the Secret was created
kubectl get secret db-secret -o yaml

# Check ESO controller logs for auth errors
kubectl logs -n external-secrets deployment/external-secrets

Типові помилки включають прострочені токени Vault, неправильні шляхи секретів та помилки конфігурації RBAC у ClusterSecretStore.

П: Як обробити ротацію облікових даних бази даних у продакшні?

Рушій секретів бази даних Vault генерує динамічні, короткотривалі облікові дані. ESO налаштовується з refreshInterval коротшим за TTL облікових даних. Для статичних облікових даних, що вимагають ротації, використовується API ротації Vault у поєднанні з Reloader для перезапуску подів після оновлень. Застосунок повинен грамотно обробляти помилки з'єднання під час вікна ротації.

AWS Secrets Manager з ESO

Інтеграція з AWS Secrets Manager вимагає IAM roles for service accounts (IRSA). Цей патерн повністю усуває статичні облікові дані:

# aws-secret-store.yaml
# ClusterSecretStore for AWS Secrets Manager with IRSA
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: aws-secrets
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-west-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
            namespace: external-secrets

Анотація service account зв'язується з IAM роллю:

# service-account-irsa.yaml
# Service account with IAM role annotation
apiVersion: v1
kind: ServiceAccount
metadata:
  name: external-secrets-sa
  namespace: external-secrets
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/external-secrets

AWS автоматично ротує секрети, створені через Secrets Manager, за допомогою Lambda функції. У поєднанні з інтервалом оновлення ESO секрети поширюються до Kubernetes протягом налаштованого періоду опитування.

Синхронізація Секретів між Кількома Кластерами

Організації, що керують кількома кластерами, потребують послідовного розповсюдження секретів. Два патерни вирішують цю вимогу:

Hub-and-spoke з ClusterSecretStore:

Усі кластери з'єднуються з центральним екземпляром Vault. Інсталяція ESO кожного кластера посилається на ті ж секрети, а Vault керує контролем доступу через політики на основі namespace.

Реплікація з Vault Enterprise:

Vault Enterprise підтримує реплікацію продуктивності між регіонами. Кожен кластер з'єднується зі своєю локальною реплікою Vault, зменшуючи затримку при збереженні консистентності. Документація реплікації Vault охоплює режими disaster recovery та реплікації продуктивності.

Для команд, що використовують ArgoCD, стаття про патерни GitOps розгортання охоплює ApplicationSets, що розгортають ExternalSecrets у кількох кластерах.

Посилення RBAC для Доступу до Секретів

Стандартні ролі кластера надають надмірний доступ до секретів. Посилення RBAC вимагає створення мінімальних ролей:

# restricted-role.yaml
# Role allowing secret access only in specific namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]
    resourceNames: ["db-secret", "api-key"]

Поле resourceNames обмежує доступ до явно перелічених секретів. Без цього поля роль надає доступ до всіх секретів у namespace.

Аудит-логування фіксує спроби доступу до секретів:

# audit-policy.yaml
# Kubernetes audit policy for secret operations
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    verbs: ["get", "list", "watch"]

Ця політика логує повний запит і відповідь для операцій із секретами, дозволяючи командам безпеки виявляти неавторизовані патерни доступу.

Продакшн Чек-лист для Kubernetes Secrets

• Увімкнути шифрування etcd в стані спокою за допомогою API ресурсу EncryptionConfiguration
• Розгорнути External Secrets Operator v0.10+ з ClusterSecretStore, що вказує на Vault або хмарного провайдера
• Налаштувати refreshInterval нижче TTL облікових даних для оновлення секретів до закінчення терміну дії
• Використовувати IRSA (AWS), Workload Identity (GCP) або Kubernetes auth (Vault) замість статичних облікових даних
• Обмежити RBAC за допомогою resourceNames для обмеження доступу до конкретних іменованих секретів
• Увімкнути аудит-логування Kubernetes для операцій із секретами з рівнем RequestResponse
• Розгорнути Reloader для застосунків, що використовують змінні середовища, для обробки оновлень секретів
• Тестувати ротацію секретів у staging середовищі перед продакшн розгортанням
• Задокументувати процедури відновлення на випадок відмови бекенду секретів, що впливає на планування подів