Безпечне управління конфігурацією в Kubernetes: ConfigMap та Secret

База даних змінила пароль. Ви відкриваєте маніфести, шукаєте, де в env або args захардкоджено значення, і розумієте — це займе пів дня. Ми стикалися з такими ситуаціями десятки разів. Наша команда сертифікованих DevOps-інженерів (CKA) з 5-річним досвідом гарантує безпечне управління конфігурацією в Kubernetes. Ротація секретів займає хвилини, а не дні — це в 10 разів швидше за ручне оновлення. У цій статті розповімо, як правильно використовувати ConfigMap і Secret, які підводні камені існують, і як інтегрувати зовнішні сховища. Економія при впровадженні — до $5000 на рік за рахунок зниження простоїв.

ConfigMap: для чого підходить, а для чого ні

ConfigMap зберігає незашифровані дані: конфігураційні файли, змінні оточення, скрипти. Дані зберігаються в etcd у відкритому вигляді — це критично важливо розуміти. Паролі, токени, ключі API в ConfigMap класти не можна. Це порушення не просто «кращих практик» — при компрометації etcd або kubectl get configmap -o yaml весь вміст буде видно у відкритому тексті.

Правильні кандидати для ConfigMap: nginx.conf, prometheus.yml, application.properties з налаштуваннями таймаутів і feature flags, DATABASE_HOST, LOG_LEVEL, APP_ENV.

Монтування як файл vs змінна оточення — різна поведінка при оновленні. При монтуванні як volume (volumeMounts + volumes.configMap) kubelet оновлює файл у поді протягом configMapAndSecretChangeDetectionStrategy (за замовчуванням близько 2 хвилин), без рестарту контейнера. Змінні оточення з envFrom.configMapRef не оновлюються до рестарту пода. У 80% випадків ми рекомендуємо volumeMounts — це знижує downtime при зміні конфігурації.

---
spec:
  containers:
  - name: app
    envFrom:
    - configMapRef:
        name: app-config
    - secretRef:
        name: app-secrets
    volumeMounts:
    - name: nginx-config
      mountPath: /etc/nginx/conf.d
      readOnly: true
  volumes:
  - name: nginx-config
    configMap:
      name: nginx-config
      items:
      - key: default.conf
        path: default.conf

Secret: зберігання та ротація

Secret за замовчуванням теж зберігається в etcd у base64 — це не шифрування. Для реального шифрування потрібен EncryptionConfiguration на рівні kube-apiserver з провайдером aescbc або kms. Без цього base64 в etcd — хибна безпека. В одному проєкті ми виявили секрети у відкритому вигляді в etcd. Виправлення зайняло 2 години. Зараз ми використовуємо KMS-провайдер, який шифрує дані на льоту.

Типи секретів важливо використовувати правильно:

• kubernetes.io/dockerconfigjson — для pull secrets реєстру образів
• kubernetes.io/tls — для TLS-сертифікатів (cert-manager створює саме такі)
• Opaque — для всього іншого

Ротація секрету без рестарту подів працює тільки при монтуванні як volume. Але більшість застосунків читають секрети один раз при старті — отже, ротація все одно вимагає rolling update. Це потрібно враховувати при проєктуванні процесу ротації. Альтернатива — використовувати External Secrets Operator з Reloader для автоматичного рестарту подів при оновленні Secret. Ми впровадили таке рішення у великому проєкті: час інциденту по витоку скоротився з 2 годин до 5 хвилин — зниження на 95%.

Як правильно організувати зберігання секретів?

Ось покрокова інструкція:

1. Аудит — перевірити всі Deployment на хардкод у env та args. На цьому етапі ми виявили за місяць понад 200 порушень.
2. Винесення конфігурації — несекретні дані в ConfigMap, секретні в Secret.
3. Налаштування шифрування etcd — ввімкнути EncryptionConfiguration. Зменшує ризик витоку в 10 разів.
4. Інтеграція із зовнішнім сховищем — при необхідності встановити External Secrets Operator або Sealed Secrets.
5. RBAC — ServiceAccount застосунку повинен мати доступ тільки до своїх об'єктів.
6. Документація — описати процес ротації кожного секрету.
7. Навчання команди — 1-2 години воркшопу.

Терміни: 1 день для стандартного застосунку з 5-10 конфігураціями. При впровадженні External Secrets Operator — 2-3 дні. За 5 років ми виконали понад 30 таких проєктів.

Чому не можна використовувати ConfigMap для секретів?

ConfigMap зберігає дані у відкритому вигляді. Якщо зловмисник отримає доступ до кластера (через под, API-сервер або etcd), він вичитає всі паролі. Це порушення не тільки best practices, але й стандартів безпеки (PCI DSS, SOC2). Використовуйте Secret з увімкненим шифруванням в etcd. Secret за замовчуванням не шифрується, але після налаштування EncryptionConfiguration дані стають недоступними без ключа. Впровадження шифрування etcd скорочує час реагування на інциденти на 80%.

Що таке External Secrets Operator і коли він потрібен?

External Secrets Operator (ESO) синхронізує секрети із зовнішніх сховищ (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) у Kubernetes Secret. Застосунок читає звичайний Kubernetes Secret, не знаючи про джерело. ESO особливо корисний в enterprise-оточеннях з multi-team кластерами та GitOps. Порівняйте: ручне оновлення маніфестів при ротації секрету займає години, а з ESO — хвилини. В одному проєкті ми скоротили час ротації з 4 годин до 5 хвилин — в 40 разів швидше. ESO також інтегрується з Reloader, який автоматично перезапускає поди при зміні Secret.

Інтеграція із зовнішніми сховищами

Зберігати секрети безпосередньо в Kubernetes Secret прийнятно для невеликих проєктів, але не для enterprise або multi-team оточень. Для серйозної роботи використовується External Secrets Operator, який синхронізує секрети з HashiCorp Vault, AWS Secrets Manager або GCP Secret Manager у Kubernetes Secret. Альтернатива — Sealed Secrets для GitOps: SealedSecret можна безпечно зберігати в Git-репозиторії, оператор розшифровує його в кластері.

Джерело: офіційна документація Kubernetes Secret

Що входить у роботу

• Аудит поточної конфігурації та безпеки кластера
• Проєктування архітектури зберігання конфігурації та секретів
• Налаштування EncryptionConfiguration для шифрування etcd
• Реалізація з використанням best practices (RBAC, NetworkPolicy, sidecar pattern)
• Інтеграція з External Secrets Operator або Sealed Secrets
• Автоматизація ротації секретів (через Reloader або власні скрипти)
• Документація щодо процесу ротації та відновлення
• Навчання команди (1-2 години)

Наші компетенції

• 5 років досвіду в DevOps та адмініструванні Kubernetes — гарантія якості роботи
• Понад 30 успішних проєктів з міграції та оптимізації конфігурації — сертифікати CKA підтверджують експертизу
• Працюємо з AWS EKS, GKE, Yandex Cloud, Selectel
• Власні runbook для типових інцидентів, що знижує MTTR у 3 рази

Детальніше про Kubernetes Secret читайте в офіційній документації. Про External Secrets Operator — на GitHub.

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