ConfigMap と Secret は、workload に設定を注入するためにどう動きますか？

Question

IT Interview Practice · Accepted Answer

**ConfigMap** と **Secret** は、設定をコンテナ image から切り離します。そのため同じ image が、異なる設定で dev・staging・production で動きます。ConfigMap は**機密でない**設定を保持し、Secret は**機密**データ（パスワード、トークン、鍵）を保持し、より慎重に扱われます。

## 発想：設定を image の外へ

```text
Image = code (immutable, built once).  Config = per-environment values.
Baking config into the image is an anti-pattern (rebuild per env, secrets leak).
→ Store config in ConfigMaps/Secrets, inject at runtime as env vars or files.
```

## 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
# secret を git にコミットしないよう、通常は命令的に作成する：
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Pod への注入：env var またはファイルとして

```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 var としてインポート
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # config をファイルとしてマウント
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Secret に関する重要な注意点

```text
⚠ Secret data is base64-ENCODED, not encrypted, by default.
  → Enable ENCRYPTION AT REST for etcd (EncryptionConfiguration).
  → Restrict access with RBAC (who can 'get secrets').
  → Prefer external managers (Vault, cloud Secrets Manager) or sealed secrets.
  → Never commit real Secret manifests to git.
Env-var config is read ONCE at container start; mounted files can update live.
```

## なぜ重要なのか

設定をコードから分離することは中核的な運用実践であり、ConfigMap と Secret はそれを Kubernetes が実装する手段なので、これらを理解することは必須の中級知識です。環境固有の設定を image に焼き込むのは anti-pattern です — 環境ごとの再ビルドを強い、secret を漏らす危険があります — そこで Kubernetes は、単一の不変な image を保ちつつ runtime で設定を注入させます。機密でない値（log level、feature flag、設定ファイル）には **ConfigMap**、機密データ（パスワード、トークン、鍵）には **Secret** を使います。それらを消費する 2 つの方法 — **環境変数**として（`configMapKeyRef`/`secretKeyRef` による個別キー、または `envFrom` による全キー）と**マウントされたファイル**として（env var は起動時に一度だけ読まれる一方、マウントされたファイルはライブで更新されうる、というニュアンス付き）— を知ることは、実際のアプリケーションをデプロイするうえで日常的で実践的な知識です。同じくらい重要なのが、多くのエンジニアがつまずくセキュリティ上の注意点の理解です。Secret data はデフォルトでは **base64 エンコードされているだけで、暗号化されていません**。そのため本当に保護するには、etcd の**保存時暗号化（encryption at rest）**を有効にし、**RBAC** でアクセスを制限し、Secret manifest をバージョン管理にコミットするのを避け、しばしば外部の secret manager を統合する必要があります。ほぼすべての workload が環境ごとの設定と認証情報を必要とし、Secret の扱いを誤ることは一般的かつ深刻なセキュリティ上の欠陥であるため、ConfigMap と Secret をしっかり把握することは、Kubernetes 上でアプリケーションを安全かつ正しく動かすための基礎です。

発想：設定を image の外へ

ConfigMap：機密でない設定

Secret：機密の値

Pod への注入：env var またはファイルとして

Secret に関する重要な注意点

なぜ重要なのか

関連する質問