Как ConfigMap и Secret работают для внедрения конфигурации в нагрузки?

Question

IT Interview Practice · Accepted Answer

**ConfigMap** и **Secret** отделяют конфигурацию от образов контейнеров, поэтому один и тот же образ работает в dev, staging и production с разными настройками. ConfigMap хранят **несекретную** конфигурацию; Secret хранят **чувствительные** данные (пароли, токены, ключи) и обрабатываются более осторожно.

## Идея: конфигурация вне образа

```text
Образ = код (неизменяемый, собирается один раз).  Конфиг = значения на окружение.
Запекать конфиг в образ — антипаттерн (пересборка на окружение, утечка секретов).
→ Храните конфиг в ConfigMap/Secret, внедряйте в рантайме как env vars или файлы.
```

## ConfigMap: несекретные настройки

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  FEATURE_X: "true"
  app.properties: |
    timeout=30
    retries=3
```

## Secret: чувствительные значения

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # здесь открытый текст; в etcd хранится в base64
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Обычно создаётся императивно, чтобы не коммитить секреты в git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Внедрение в Pod: как env vars или как файлы

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # один ключ из ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # один ключ из Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # импортировать ВСЕ ключи как env vars
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # смонтировать конфиг как файлы
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Важные оговорки о Secret

```text
⚠ Данные Secret по умолчанию ЗАКОДИРОВАНЫ в base64, а не зашифрованы.
  → Включите ШИФРОВАНИЕ AT REST для etcd (EncryptionConfiguration).
  → Ограничьте доступ через RBAC (кто может 'get secrets').
  → Предпочитайте внешние менеджеры (Vault, облачный Secrets Manager) или sealed secrets.
  → Никогда не коммитьте настоящие манифесты Secret в git.
Конфиг через env-var читается ОДИН раз при старте контейнера; смонтированные файлы могут обновляться на лету.
```

## Почему это важно

Отделение конфигурации от кода — ключевая операционная практика, и ConfigMap и Secret — это то, как Kubernetes её реализует, поэтому понимание их — существенное знание уровня middle. Запекать настройки, специфичные для окружения, в образ — антипаттерн: это заставляет пересобирать образ на каждое окружение и рискует утечкой секретов, поэтому Kubernetes позволяет держать единый неизменяемый образ и внедрять конфигурацию в рантайме: **ConfigMap** для несекретных значений (уровни логирования, feature-флаги, файлы конфигурации) и **Secret** для чувствительных данных (пароли, токены, ключи). Знание двух способов их потребления — как **переменные окружения** (отдельные ключи через `configMapKeyRef`/`secretKeyRef` или все ключи через `envFrom`) и как **смонтированные файлы** (с нюансом, что env vars читаются один раз при старте, тогда как смонтированные файлы могут обновляться на лету) — повседневное практическое знание для развёртывания реальных приложений. Не менее важно понимать оговорки по безопасности, на которых спотыкаются многие инженеры: данные Secret по умолчанию лишь **закодированы в base64, а не зашифрованы**, поэтому для их подлинной защиты нужно включить **шифрование at rest** для etcd, ограничить доступ через **RBAC**, не коммитить манифесты Secret в систему контроля версий и часто интегрировать внешний менеджер секретов. Поскольку практически каждой нагрузке нужна конфигурация и учётные данные на каждое окружение, и поскольку неправильное обращение с Secret — распространённая и серьёзная брешь в безопасности, твёрдое понимание ConfigMap и Secret фундаментально для безопасного и корректного запуска приложений на Kubernetes.

Идея: конфигурация вне образа

ConfigMap: несекретные настройки

Secret: чувствительные значения

Внедрение в Pod: как env vars или как файлы

Важные оговорки о Secret

Почему это важно

Похожие вопросы