조직이 작아 Vault 처럼 외부 주입되는 Secret 관리 체계가 미비하다면 Sealed Secret을 고려해 볼만하다.

최근 xAI의 API Key 유출 사례에서 보듯, GitOps 배포 파이프라인을 구성할 때 암호나 인증키는 골치거리이다.
Secret 정보들을 git repo나 helm chart에 포함시키자니 보안 리스크가 걱정되고, 배포 시에만 Secret을 외부 주입하자니 자동화 흐름을 깨트리고.. 때문에 GitOps 흐름을 유지하면서 Secret정보를 안전하게 관리하려면 Vault 나 AWS Secret Manager 류의 외부 Secret 주입 서비스를 이용하기 마련이다.(오픈소스로는 Infisical이라는 훌륭한 대체제가 있다.)

하지만 여건상 Vault 류를 쓸 수 없는 애매한 환경도 존재한다. 서비스 규모가 애매하거나, Vault를 도입하지 않은 Private Cloud를 사용하거나.. 이럴 때 도입을 고려해 볼 만한 것이 bitnami 에서 만든 Sealed Secrets 이다.

Sealed Secrets 는 서비스 외부의 Secret 관리 체계를 별도로 갖고 있지 않으며,

• Cluster Side Secret Controller(=Operator)
• Client Side Utility(=kubeseal)

두 도구로 Secret 정보를 관리한다.

큰 흐름은 다음과 같다. 1) Secret 암호화 2) 암호화된 Secret 형상관리하면서 배포 3) cluster 에서 복호화

단계	작업	주요 내용
1. 컨트롤러 설치	Helm/Kustomize 등으로 Sealed Secrets Controller + CRD를 클러스터에 한 번만 배포	컨트롤러/오퍼레이터가 클러스터 전역에서 SealedSecret 객체를 감시해 복호화한다
2. 공개키 확보	개발 · CI 환경에서 kubeseal --fetch-cert > pub.pem (또는 자동으로 Operator에서 가져오기)	이 단계는 Secret Controller Operator 접근 가능한 환경에서는 생략 가능
3. 원본 Secret 작성	로컬에서 임시 Secret 생성 kubectl create secret … --dry-run=client -o yaml > secret.yaml	이 Secret은 운영자 / CI 환경에서 임시로 생성되는 값
4. 암호화(Seal)	cat secret.yaml | kubeseal \ --cert pub.pem \ --format yaml > secret-sealed.yaml	kubeseal이 공개키로 AES-256-GCM + RSA-4096 방식 암호화된 kind: SealedSecret 출력. 이 암호화된 데이터는 노출되어도 안전함
5. Git 커밋 & PR	secret-sealed.yaml 을 Git 리포지토리(Argo CD/Flux 소스)로 커밋	암호화된 데이터이므로 공개 저장소에 올려도 무방
6. 적용(Deploy)	GitOps 툴 또는 kubectl apply -f secret-sealed.yaml	컨트롤러가 Private Key로 복호화 → 동일 name·namespace의 K8s Secret 생성
7. 어플리케이션 사용	Deployment/Pod에서 평소처럼 envFrom, secretKeyRef 등으로 참조	생성된 Secret은 일반 Secret과 100% 동일하게 동작하고, SealedSecret이 변경·삭제되면 자동 갱신·정리됨

이렇듯 대칭키로 암호화된 Secret은 여러 설정이나 helm chart 같은 배포 패키지에 포함되더라도 안전하기 때문에 GitOps 흐름이 끊기지 않는다.

하지만 Cluster Side 에 저장된 키를 털리거나 분실하는 경우에는 방법이 없으므로 이에 대한 대책을 또 마련하다보면 결국 Vault 류 같은게 나울 수밖에 없는데.. 그렇더라도 Sealed Secrets는 중소 규모 서비스에서 보안과 자동화의 균형점을 적당히 타협하여 쓸만한 도구라 생각한다.

https://github.com/bitnami-labs/sealed-secrets