서비스 전반에 걸쳐 중앙집중식 구성과 시크릿을 어떻게 처리하나요?

Question

Accepted Answer

수십 개의 서비스가 있으면 배포마다 임시방편으로 구성과 시크릿을 관리할 수 없습니다. **중앙집중식 구성(centralized configuration)**은 설정을 하나의 관리되는 소스에 두고, **시크릿 매니저(secrets manager)**는 민감한 값을 안전하게 저장합니다.

## 외부화된 구성

구성은 빌드 아티팩트 밖에 존재하므로, 동일한 이미지가 서로 다른 설정으로 dev/staging/prod에서 실행됩니다.

```yaml
# 이미지에 구워 넣지 않고 런타임에 주입되는 값
DATABASE_URL: ${DB_URL}        # 환경별
FEATURE_NEW_CHECKOUT: "true"   # 재배포 없이 토글
PAYMENT_TIMEOUT_MS: "3000"
```

## 구성 접근법

| 접근법 | 예시 |
|---|---|
| 구성 서버 | Spring Cloud Config, Consul |
| 오케스트레이터 네이티브 | Kubernetes ConfigMaps |
| 시크릿 매니저 | HashiCorp Vault, AWS Secrets Manager |

## 시크릿 — 분리해서 보관

시크릿을 평문 ConfigMap이나 git에 절대 저장하지 마세요.

```bash
# 시작 시 시크릿을 가져옴, 짧은 수명, 감사 기록됨
export DB_PASSWORD=$(vault kv get -field=password secret/orders/db)
```

## 좋은 관행

```text
✓ 구성 외부화(12-factor): 환경 안의 구성
✓ 시크릿은 회전 + 감사 로그를 갖춘 전용 매니저에
✓ 비시크릿 토글은 동적 리프레시(재배포 없음)
✗ 절대 시크릿을 소스 관리에 커밋하지 말 것
```

## 왜 중요한가

중앙집중식 구성은 각 서비스를 재빌드하고 재배포하지 않고도 동작(타임아웃, 기능 플래그)을 변경하고 여러 서비스에 걸쳐 자격 증명을 회전할 수 있게 해줍니다.

시크릿을 이미지나 git이 아닌 실제 시크릿 매니저에 두는 것은 서비스 수에 따라 확장되는 기본 보안 요구사항입니다.

접근법	예시
구성 서버	Spring Cloud Config, Consul
오케스트레이터 네이티브	Kubernetes ConfigMaps
시크릿 매니저	HashiCorp Vault, AWS Secrets Manager