ConfigMap과 Secret은 워크로드에 설정을 주입하기 위해 어떻게 동작하는가?

Question

IT Interview Practice · Accepted Answer

**ConfigMap**과 **Secret**은 설정을 컨테이너 이미지에서 분리하므로, 같은 이미지가 서로 다른 설정으로 dev, staging, production에서 실행된다. ConfigMap은 **민감하지 않은** 설정을 담고; Secret은 **민감한** 데이터(비밀번호, 토큰, 키)를 담으며 더 조심스럽게 다뤄진다.

## 아이디어: 설정을 이미지 밖으로

```text
Image = code (immutable, built once).  Config = per-environment values.
설정을 이미지에 굽는 것은 안티패턴이다 (환경마다 재빌드, secret 유출).
→ 설정을 ConfigMap/Secret에 저장하고, 런타임에 env var나 파일로 주입한다.
```

## 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           # 설정을 파일로 마운트
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Secret에 관한 중요한 주의점

```text
⚠ Secret 데이터는 기본적으로 base64로 인코딩될 뿐, 암호화되지 않는다.
  → etcd에 대해 저장 시 암호화(EncryptionConfiguration)를 활성화하라.
  → RBAC로 접근을 제한하라 (누가 'get secrets' 할 수 있는지).
  → 외부 관리자(Vault, cloud Secrets Manager)나 sealed secret을 선호하라.
  → 실제 Secret manifest를 절대 git에 커밋하지 말라.
env-var 설정은 컨테이너 시작 시 한 번만 읽힌다; 마운트된 파일은 실시간 갱신 가능.
```

## 왜 중요한가

설정을 코드에서 분리하는 것은 핵심적인 운영 관행이고, ConfigMap과 Secret은 Kubernetes가 이를 구현하는 방식이므로, 그것들을 이해하는 것은 미들급의 필수 지식이다. 환경별 설정을 이미지에 굽는 것은 안티패턴이다 — 환경마다 재빌드를 강요하고 secret 유출 위험이 있다 — 그래서 Kubernetes는 단일한 immutable 이미지를 유지하면서 런타임에 설정을 주입하게 해준다: 민감하지 않은 값(로그 레벨, feature flag, 설정 파일)에는 **ConfigMap**을, 민감한 데이터(비밀번호, 토큰, 키)에는 **Secret**을 쓴다. 그것들을 소비하는 두 가지 방법을 아는 것 — **환경 변수**로(`configMapKeyRef`/`secretKeyRef`를 통한 개별 키, 또는 `envFrom`을 통한 모든 키)와 **마운트된 파일**로(env var는 시작 시 한 번 읽히지만 마운트된 파일은 실시간 갱신될 수 있다는 미묘한 차이와 함께) — 은 실제 애플리케이션을 배포하는 데 매일 쓰는 실용 지식이다. 똑같이 중요한 것은 많은 엔지니어를 걸려 넘어지게 하는 보안 주의점을 이해하는 것이다: Secret 데이터는 기본적으로 **암호화가 아니라 base64로 인코딩될 뿐**이므로, 그것을 진정으로 보호하려면 etcd에 대한 **저장 시 암호화** 활성화, **RBAC**로 접근 제한, Secret manifest를 버전 관리에 커밋하지 않기, 그리고 종종 외부 secret 관리자 통합이 필요하다. 사실상 모든 워크로드가 환경별 설정과 자격 증명을 필요로 하고 Secret을 잘못 다루는 것이 흔하고 심각한 보안 허점이므로, ConfigMap과 Secret을 확실히 파악하는 것은 Kubernetes에서 애플리케이션을 안전하고 올바르게 실행하는 데 기초가 된다.

아이디어: 설정을 이미지 밖으로

ConfigMap: 민감하지 않은 설정

Secret: 민감한 값

Pod로 주입: env var 또는 파일로

Secret에 관한 중요한 주의점

왜 중요한가

관련 질문