Управление конфигурациями и безопасностью

В современной разработке (IaC — Infrastructure as Code) крайне важно отделять код приложения от его настроек. Kubernetes предоставляет для этого два основных объекта: ConfigMap (для обычных данных) и Secret (для конфиденциальных данных).

Эволюция хранения конфигов

Простой файл: Раньше настройки хранились прямо в коде или в файле рядом с исполняемым файлом.
Роли и окружения: С ростом проекта появились разные окружения (Dev, Staging, Prod) и роли доступа. Хранить всё в одном месте стало невозможно.
Централизованное хранение (IaC): В Kubernetes конфигурации хранятся в etcd, управляются через API и динамически подключаются к подам.

Способы передачи переменных

Самый простой способ передать настройки — прописать их прямо в манифесте Пода через поле env.

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
spec:
  containers:
    - name: envar-demo-container
      image: gcr.io/google-samples/node-hello:1.0
      env:
        - name: DEMO_GREETING
          value: "Hi all!"

ConfigMap: Хранение обычных настроек

ConfigMap позволяет хранить конфигурационные данные в виде пар «ключ-значение» или целых конфигурационных файлов.

Пример манифеста ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-app-config
data:
  DRIVER_ADDR: "https://payment.prod.env:8080"
  JWT_ISSUER: "team.prod.env"

Как подключить ConfigMap к Поду?

Вы можете загрузить все переменные разом через envFrom или выбрать конкретный ключ через valueFrom.

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  containers:
    - name: demo-app
      image: gcr.io/google-samples/node-hello:1.0
      envFrom:
        - configMapRef:
            name: demo-app-config  # Загрузит все ключи из ConfigMap как переменные
      env:
        - name: JWT_ISSUER_SECOND
          valueFrom:
            configMapKeyRef:
              name: demo-app-config
              key: JWT_ISSUER      # Загрузит только конкретное значение

Secrets: Хранение чувствительных данных

Secrets похожи на ConfigMaps, но предназначены для паролей, токенов и ключей. Данные в манифесте секрета должны быть закодированы в base64.

Пример манифеста Secret:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=        # admin в base64
  password: MWYyZDFlMmU2N2Rm # хеш пароля в base64

Типы секретов в Kubernetes:

Opaque: Обычный секрет для произвольных данных (по умолчанию).
kubernetes.io/service-account-token: Токен для сервисных аккаунтов.
kubernetes.io/dockercfg / .dockerconfigjson: Данные для авторизации в Docker Registry.
kubernetes.io/basic-auth: Логин и пароль для базовой аутентификации.
kubernetes.io/ssh-auth: Данные для SSH-авторизации.
kubernetes.io/tls: Для хранения сертификатов (публичный ключ и приватный ключ).
bootstrap.kubernetes.io/token: Токен для начальной загрузки узлов (bootstrap).

Итог

Характеристика	ConfigMap	Secret
Для чего?	Настройки, URL-адреса, флаги.	Пароли, токены, ключи TLS.
Безопасность	Данные в открытом виде.	Данные в base64 (нужно шифрование etcd).
Обновление	Можно обновлять "на лету" (при монтировании файлов).	Можно обновлять "на лету", но требует осторожности.
Типичный объем	До 1 МБ.	До 1 МБ.

Важно: Кодирование в base64 — это не шифрование. Любой, кто имеет доступ к API Kubernetes, может легко декодировать ваши секреты. Для реальной безопасности используйте шифрование etcd или внешние хранилища (HashiCorp Vault, AWS Secrets Manager).