Xем отличаются secrets и configmaps

Сравнение ConfigMaps и Secrets в Kubernetes

Хотя ConfigMaps и Secrets в Kubernetes решают схожие задачи — предоставляют конфигурационные данные приложениям, — между ними есть фундаментальные различия в предназначении, безопасности и реализации.

Основные различия

1. Предназначение и тип данных

ConfigMaps предназначены для хранения неконфиденциальных данных в формате пар "ключ-значение":

• Конфигурационные файлы (JSON, XML, YAML)
• Переменные окружения
• Командные строки
• Настройки приложений

Secrets созданы для чувствительных данных, требующих защиты:

• Пароли и токены
• SSH-ключи и сертификаты TLS
• Ключи шифрования
• Учетные данные баз данных

# Пример ConfigMap (открытые данные)
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  log_level: "INFO"
  max_connections: "100"
  config.json: |
    {
      "server": "api.example.com",
      "port": 8080
    }

# Пример Secret (зашифрованные данные)
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=  # admin в base64
  password: cGFzc3dvcmQxMjM=  # password123 в base64

2. Безопасность и шифрование

ConfigMaps:

• Хранят данные в чистом виде (plain text)
• Нет встроенного шифрования
• Не подходят для секретных данных

Secrets:

• Данные кодируются в base64 (не путать с шифрованием!)
• Поддерживают шифрование на уровне etcd (с включением EncryptionAtRest)
• Могут использовать внешние провайдеры секретов (Hashicorp Vault, Azure Key Vault)
• Имеют типизированную структуру для разных видов секретов

# Различия в создании
# ConfigMap - обычный текст
kubectl create configmap my-config --from-literal=key=value

# Secret - автоматическое base64 кодирование
kubectl create secret generic my-secret --from-literal=password=secret123

3. Особенности управления

Хранение и доступ:

• ConfigMaps доступны всем, кто имеет доступ к namespace
• Secrets имеют встроенные механизмы RBAC для ограничения доступа
• Secrets передаются узлам только при необходимости (меньший риск экспозиции)

Монтирование в поды:

# ConfigMap как volume
volumes:
  - name: config-volume
    configMap:
      name: app-config

# Secret как volume
volumes:
  - name: secret-volume
    secret:
      secretName: db-credentials

Переменные окружения:

# ConfigMap в переменных окружения
envFrom:
  - configMapRef:
      name: app-config

# Secret в переменных окружения (значения декодируются автоматически)
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password

4. Жизненный цикл и обновления

ConfigMaps:

• Обновления применяются относительно быстро
• Можно использовать ConfigMap как volume с автоматическим обновлением

Secrets:

• Более консервативная политика обновлений
• Требуют перезапуска пода для применения изменений (по умолчанию)
• Поддерживают механизмы ротации секретов

Практические рекомендации

Когда использовать ConfigMaps:

• Настройки логирования
• Конфигурационные файлы приложений
• Параметры функциональности
• URL API (без учетных данных)

Когда использовать Secrets:

• Учетные данные базы данных
• TLS-сертификаты
• Токены API и ключи шифрования
• Данные аутентификации

Важные предупреждения:

1. Base64 ≠ шифрование — Secrets лишь кодируют данные, но не шифруют их по умолчанию
2. Аудит логов — секреты могут попасть в логи при неправильном использовании
3. Доступ к etcd — с доступом к etcd можно прочитать все секреты
4. Регулярная ротация — обязательная практика для безопасности

Современные подходы

Для повышения безопасности рекомендуется:

• Использовать External Secret Operators для интеграции с внешними хранилищами
• Включать Encryption at Rest для etcd
• Реализовать автоматическую ротацию секретов
• Использовать SealedSecrets или SOPS для безопасного хранения в Git

ConfigMaps и Secrets — это не взаимозаменяемые, а взаимодополняющие инструменты. Правильное их использование позволяет создать баланс между удобством управления конфигурацией и безопасностью чувствительных данных в Kubernetes-кластере.