Настройка Kubernetes ConfigMaps и Secrets для конфигурации

База данных сменила пароль. Вы открываете манифесты, ищете, где в env или args захардкожено значение, и понимаете — это займёт полдня. Мы сталкивались с такими ситуациями десятки раз. Наша команда DevOps-инженеров с 5-летним опытом помогает компаниям организовать управление конфигурацией в Kubernetes так, чтобы ротация секретов занимала минуты, а не дни. В этой статье расскажем, как правильно использовать ConfigMap и Secret, какие подводные камни есть, и как интегрировать внешние хранилища.

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 минут.

Как правильно организовать хранение секретов?

Вот пошаговая инструкция:

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 минут без участия человека. 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-репозитории, оператор расшифровывает его в кластере.

Что входит в работу

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

Наши компетенции

• 5 лет опыта в DevOps и администрировании Kubernetes
• Более 30 успешных проектов по миграции и оптимизации конфигурации
• Сертифицированные администраторы Kubernetes (CKA)
• Работаем с AWS EKS, GKE, Yandex Cloud, Selectel
• Собственные runbook для типовых инцидентов, что снижает MTTR в 3 раза

Подробнее о Kubernetes Secret читайте в официальной документации. О External Secrets Operator — на GitHub.

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