본문으로 건너뛰기
K03: Secrets — 민감 정보의 안전한 관리

K03: Secrets — 민감 정보의 안전한 관리

많은 초보 개발자가 실수하는 패턴 중 하나가 데이터베이스 접속 정보, API 키 등 민감한 정보를 환경 변수(environment variable)에 평문으로 저장하는 것입니다. K03은 이런 ‘정보 노출’의 위험성을 직접 확인하고 해결하는 실습입니다.

미션: 민감 정보의 안전한 관리

쿠버네티스 Pod의 환경 변수에 비밀 정보를 넣어두면, kubectl get pod <pod-name> -o yaml 명령어만으로도 누구나 해당 값을 들여다볼 수 있습니다.

1. 취약한 코드 (vulnerable.yaml)

Pod의 스펙(spec)에 비밀번호를 평문으로 직접 기입한 상태입니다.

apiVersion: v1
kind: Pod
metadata:
  name: vulnerable-app
spec:
  containers:
    - name: app
      image: my-app
      env:
        - name: DB_PASSWORD
          value: "super-secret-password-123" # 🚨 위험: 평문 노출

분석: Pod 설정 정보는 클러스터 권한이 있는 사용자라면 누구나 읽을 수 있습니다. 설정 파일 안에 비밀번호가 그대로 적혀 있다면, 이 정보는 사실상 공개된 것과 다름없습니다.

2. 해결책 코드 (fixed.yaml)

쿠버네티스의 Secret 객체를 별도로 생성하고, 이를 Pod에서 안전하게 참조합니다.

# 1. Secret 객체 생성
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
stringData:
  password: "super-secret-password-123"

---
# 2. Pod에서 참조
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
    - name: app
      image: my-app
      env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret  # ✅ 개선: 직접 입력 대신 Secret 객체 참조
              key: password

분석: 비밀번호를 Pod 설정 파일(YAML)에서 분리했습니다. Secret 객체는 별도로 권한(RBAC)을 관리할 수 있고, 민감 정보가 Pod의 설정값으로 직접 노출되지 않습니다.

Secret 객체로 옮기는 것은 “설정 파일에서의 평문 노출"만 막습니다. etcd에 저장된 Secret 자체는 여전히 base64 인코딩일 뿐 암호화가 아닙니다. etcd 디스크 탈취까지 방어하려면 Concept의 Secret 암호화에서 다루는 KMS encryption-at-rest, Vault Agent Injector 같은 별도 계층이 필요합니다.

실습: 공격 → 방어 검증

1) 공격 — 환경 변수에서 평문 비밀번호 확인

kubectl apply -f vulnerable.yaml
kubectl describe pod vulnerable-app
# Environment:
#   DB_PASSWORD: super-secret-password-123

describe 한 번으로 비밀번호가 그대로 출력됩니다. 공격자는 이를 이용해 데이터베이스에 무단 접속할 수 있습니다.

2) 방어 — Secret 참조로 전환 후 재확인

kubectl apply -f fixed.yaml
kubectl describe pod secure-app
# Environment:
#   DB_PASSWORD: <set to the key 'password' in secret 'db-secret'>  Optional: false

환경 변수에는 비밀번호 대신 “Secret 객체를 참조한다"는 레퍼런스만 남습니다. 실제 값을 보려면 db-secret에 대한 별도의 get secrets 권한이 있어야 하므로, K02에서 다룬 RBAC 최소 권한 설계와 자연스럽게 이어집니다.

체크리스트

  • Pod 스펙(env.value)에 비밀번호·API 키·토큰이 평문으로 박혀 있지 않은가
  • 모든 민감 정보가 Secret 객체(secretKeyRef) 또는 볼륨 마운트로 주입되는가
  • Secret에 대한 get/list 권한이 꼭 필요한 ServiceAccount에만 부여되어 있는가
  • etcd Secret이 KMS로 encryption-at-rest 적용되어 있는가 (검증 방법)

“설정 파일에 비밀번호를 직접 적지 마라"는 대원칙이 쿠버네티스에서 어떻게 구현되는지를 보여주는 랩입니다. 다음 미션(K04: Policy Enforcement)에서는 이런 안전한 패턴을 사람이 매번 기억하는 대신, 시스템이 자동으로 강제하게 만드는 방법을 다룹니다.