쿠버네티스 환경에서 시크릿 관리하기: Sealed Secret vs SOPS 비교

최근 GitOps 환경에서 프로젝트를 진행하면서 고민이 하나 생겼습니다. ArgoCD로 배포 자동화는 잘 구축했는데, 헬름 차트의 values.yaml 파일에 있는 시크릿 정보들을 어떻게 안전하게 관리할 것인가 하는 문제였죠.

yaml

# 이런 식으로 평문 시크릿이 values.yaml에...
database:
  host: "db.example.com"
  username: "admin"
  password: "super-secret-password"  # 😱 Git에 그대로 노출

그래서 쿠버네티스 시크릿 관리 도구를 찾아보다가 Sealed Secret과 SOPS라는 두 가지 도구를 발견했습니다. 실제로 둘 다 테스트해보니 각각 다른 접근 방식과 장단점이 있더군요.

왜 쿠버네티스 시크릿 관리가 중요할까?

현실적인 문제

개발하면서 마주치는 시크릿 관리 문제는 생각보다 복잡합니다.

bash

# 1. Git 저장소에 시크릿 노출 위험
git add values.yaml  # 평문 패스워드가 포함된 파일

# 2. 환경별 시크릿 관리의 어려움
dev-values.yaml      # 개발 환경 시크릿
staging-values.yaml  # 스테이징 환경 시크릿  
prod-values.yaml     # 운영 환경 시크릿

# 3. 팀원 간 시크릿 공유 문제
# Slack으로 패스워드 공유? 😰

GitOps와 시크릿의 딜레마

특히 ArgoCD 같은 GitOps 도구를 사용할 때는 더욱 고민스럽습니다.

코드

Git Repository (모든 설정 저장) ← GitOps 철학
       ↕️
   시크릿도 Git에?
   보안은 어떻게?

이런 고민을 풀려고 쓰는 것이 암호화된 시크릿 관리 도구입니다.

Sealed Secret과 SOPS의 시크릿 흐름

선 설명

워크플로의 명령과 결과
SOPS가 쓰는 암호화 백엔드

Sealed Secret과 SOPS의 시크릿 흐름

Sealed Secret은 kubeseal로 봉인한 매니페스트를 Git에 두고 클러스터 컨트롤러가 Secret으로 푼다. SOPS는 KMS 같은 백엔드 키로 values 값만 암호화해 Git에 두고 helm-secrets로 설치한다.

그림 관계를 글로 읽기

Sealed Secret: kubectl create --dry-run으로 만든 Secret 매니페스트를 kubeseal이 SealedSecret으로 바꾼다.
SealedSecret(encryptedData)을 Git에 저장한다.
클러스터의 Sealed Secret Controller가 SealedSecret을 자동 복호화한다.
컨트롤러가 Secret 리소스를 만든다.
SOPS: 평문 values.yaml(.gitignore로 제외)을 sops -e로 암호화해 values.enc.yaml을 만든다. 파일 구조는 두고 값만 암호화한다.
암호화 키는 AWS KMS, Azure Key Vault, GPG 같은 백엔드를 쓴다.
values.enc.yaml을 Git에 저장한다.
helm-secrets 플러그인으로 암호화된 파일을 써서 바로 설치한다.

Sealed Secret: 쿠버네티스 네이티브 접근

개념과 동작 원리

Sealed Secret은 Bitnami에서 개발한 쿠버네티스 컨트롤러입니다. 핵심 아이디어는 간단합니다.

yaml

# 일반 Secret (평문)
apiVersion: v1
kind: Secret
data:
  password: cGFzc3dvcmQ=  # base64 인코딩 (암호화 아님)

# SealedSecret (암호화됨)  
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: database-secret
spec:
  encryptedData:
    password: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEQAx...  # 실제 암호화!

워크플로우

실제 사용해 본 워크플로우는 이렇습니다.

bash

# 1. Sealed Secret Controller 설치
kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.24.0/controller.yaml

# 2. kubeseal CLI 설치  
wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.24.0/kubeseal-0.24.0-linux-amd64.tar.gz

# 3. 시크릿 암호화
echo -n mypassword | kubectl create secret generic mysecret --dry-run=client --from-file=password=/dev/stdin -o yaml | kubeseal -o yaml > mysealedsecret.yaml

# 4. Git에 안전하게 저장
git add mysealedsecret.yaml
git commit -m "Add encrypted secret"

장점

쿠버네티스 네이티브: CRD 기반으로 k8s와 자연스럽게 통합
즉시 사용 가능: 컨트롤러 설치 후 바로 사용
자동 복호화: 클러스터에서 자동으로 Secret 리소스 생성

단점

실제 사용해 보니 몇 가지 한계가 있었습니다.

bash

# 헬름 차트와의 궁합 문제
# values.yaml의 각 시크릿을 일일이 찾아서 SealedSecret으로 변환해야 함
database:
  password: "secret123"  # 이걸 찾아서
  
# 이렇게 바꿔야 함
database:
  password:
    valueFrom:
      secretKeyRef:
        name: database-secret
        key: password

헬름 차트 수정 필요: 기존 values.yaml 구조를 바꿔야 함
시크릿 개별 관리: 각 시크릿마다 별도 SealedSecret 리소스 필요
클러스터 종속적: 클러스터마다 다른 키 쌍 사용

SOPS: 파일 레벨 암호화

개념과 철학

SOPS(Secret OPerationS)는 Mozilla에서 개발하고 현재 CNCF Sandbox 프로젝트가 된 도구입니다. 접근 방식이 Sealed Secret과는 완전히 다릅니다.

yaml

# 원본 values.yaml
database:
  host: db.example.com
  username: admin
  password: secret123

# SOPS로 암호화한 후
database:
  host: db.example.com
  username: admin  
  password: ENC[AES256_GCM,data:Tr7o1T8w5...,iv:1234...,tag:abcd...]

핵심: 파일의 구조는 유지하면서 값만 선택적으로 암호화합니다.

실제 워크플로우

SOPS를 사용한 실제 워크플로우는 정말 간단했습니다.

bash

# 1. SOPS 설치
curl -LO https://github.com/mozilla/sops/releases/download/v3.8.1/sops-v3.8.1.linux.amd64
sudo mv sops-v3.8.1.linux.amd64 /usr/local/bin/sops
chmod +x /usr/local/bin/sops

# 2. 헬름 차트 다운로드
helm pull grafana/grafana
tar -xzf grafana-*.tgz

# 3. values.yaml 수정 (평문으로 편하게)
vi grafana/values.yaml
adminPassword: "my-super-secret-admin-password"

# 4. 암호화
sops -e grafana/values.yaml > values.enc.yaml

# 5. Git에 안전하게 저장  
echo "values.yaml" >> .gitignore  # 평문 파일 제외
git add values.enc.yaml
git commit -m "Add encrypted grafana config"

helm-secrets와의 연동

SOPS의 진짜 장점은 helm-secrets 플러그인과 함께 쓸 때 드러납니다.

bash

# helm-secrets 플러그인 설치
helm plugin install https://github.com/jkroepke/helm-secrets

# 암호화된 파일로 바로 설치!
helm secrets install grafana grafana/grafana -f values.enc.yaml

# ArgoCD와 연동
# ArgoCD가 자동으로 복호화해서 배포

두 도구의 비교 분석

실제 사용해 본 경험을 바탕으로 비교해 보겠습니다.

항목	Sealed Secret	SOPS
설치 복잡도	🟢 쉬움 (컨트롤러만)	🟡 보통 (CLI + 플러그인)
헬름 차트 호환성	🔴 어려움 (구조 변경 필요)	🟢 우수함 (그대로 사용)
학습 곡선	🟢 쉬움	🟡 보통
GitOps 친화성	🟢 좋음	🟢 매우 좋음
다중 환경 지원	🔴 복잡함 (클러스터별 키)	🟢 간단함 (KMS 활용)
백업/이관	🔴 어려움	🟢 쉬움
에코시스템	🟡 쿠버네티스 전용	🟢 다양한 도구 지원

실제 사용 시나리오별 추천

Sealed Secret을 선택해야 하는 경우:

bash

# 1. 순수 쿠버네티스 매니페스트만 사용
# 2. 헬름 차트 커스터마이징 가능
# 3. 클러스터별 독립적 시크릿 관리 선호

SOPS를 선택해야 하는 경우:

bash

# 1. 헬름 차트 기반 배포 (대부분의 경우)
# 2. 기존 values.yaml 구조 유지 필요  
# 3. 다양한 환경에서 동일한 워크플로우 원함
# 4. GitOps와 CI/CD 파이프라인 통합

개인적인 결론과 권장사항

두 도구를 직접 사용해본 결과, SOPS가 더 실용적이라는 결론에 도달했습니다.

SOPS를 선택한 주요 이유

1. 헬름 에코시스템과의 자연스러운 통합

bash

# 기존 헬름 차트를 그대로 사용 가능
helm pull bitnami/postgresql
# values.yaml 수정
# sops로 암호화
# helm secrets로 배포

2. 개발 워크플로우의 단순함

bash

# 로컬에서는 평문으로 편집
vi values.yaml

# Git에는 암호화해서 저장
sops -e values.yaml > values.enc.yaml
git add values.enc.yaml

3. 다양한 암호화 백엔드 지원

bash

# AWS KMS
sops --kms "arn:aws:kms:us-east-1:123456789:key/12345678" -e secrets.yaml

# Azure Key Vault  
sops --azure-kv "https://myvault.vault.azure.net/keys/mykey/version" -e secrets.yaml

# GPG (온프레미스)
sops --pgp "user@example.com" -e secrets.yaml

4. CNCF 프로젝트로서의 안정성

2023년 CNCF Sandbox 프로젝트로 승인되면서 장기적 지속가능성도 확보했습니다.

실무 적용 권장사항

초기 도입 시

bash

# 1. 작은 프로젝트부터 시작
# 2. GPG 키 기반으로 시작 (클라우드 KMS 학습 전)
# 3. helm-secrets 플러그인 활용

운영 환경 적용 시

bash

# 1. 클라우드 KMS 활용 (AWS KMS, Azure Key Vault 등)
# 2. 환경별 암호화 키 분리
# 3. ArgoCD와 연동하여 GitOps 구현

다음 단계

이 글을 보고 계신다면, 직접 두 도구를 테스트해 보는 것을 추천합니다.

k3s나 minikube로 로컬 클러스터 구성
간단한 헬름 차트로 두 도구 모두 테스트
본인의 환경과 워크플로우에 맞는 도구 선택

개인적으로는 SOPS + helm-secrets 조합이 현재 대부분의 쿠버네티스 환경에서 가장 실용적인 선택이라고 생각합니다. 하지만 환경과 요구사항에 따라 Sealed Secret이 더 적합할 수도 있으니, 직접 경험해 보시길 권합니다.

시크릿 관리는 보안의 기본이지만, 너무 복잡해서 개발 생산성을 해치면 안 되겠죠. 적절한 도구를 골라 보안과 편의성을 함께 챙기시기 바랍니다.

참고 자료: