시크릿을 어디에 둘 것인가 - SealedSecret과 OpenBao를 같이 쓰는 이유
Git에 커밋 가능한 SealedSecret과, 회전이 잦은 값을 위한 중앙 시크릿 저장소 OpenBao + External Secrets Operator. 둘을 구분해서 쓰는 기준을 정리한다.
문제: 시크릿 관리에 정답 하나만 있는 게 아니었다
Keycloak 클라이언트 시크릿은 SealedSecret으로 푼 상태였다(1편 참고) - kubeseal로 암호화해서 Git에 커밋하고, 클러스터 안의 컨트롤러만 복호화할 수 있는 방식. 이 방식은 "값이 거의 안 바뀌고, Git으로 이력 관리가 되면 좋은" 시크릿에는 잘 맞았다.
그런데 서비스가 9개로 늘면서 시크릿의 성격이 다양해졌다. DB 접속 정보, 외부 API 키, 서비스 간 통신에 쓰는 토큰처럼 회전(rotation)이 필요하거나, 여러 서비스가 같은 값을 공유해야 하거나, 값 자체를 감사(audit)해야 하는 시크릿들이 늘었다. SealedSecret은 "이미 암호화된 값을 Git에 안전하게 두는 것"에는 강하지만, 그 값 자체를 중앙에서 관리하고 회전 이력을 추적하는 용도로는 설계되어 있지 않다. 시크릿마다 성격이 다른데 하나의 도구로 전부 해결하려 하면 어느 한쪽이 억지스러워진다.
시도한 것: 성격에 따라 두 도구를 나누기
OpenBao - 시크릿의 단일 진실 공급원
OpenBao(HashiCorp Vault 계열의 오픈소스 시크릿 관리 도구)를 시크릿의 중앙 저장소로 뒀다. 서비스가 직접 OpenBao를 호출하는 대신, **External Secrets Operator(ESO)**가 중간에서 OpenBao의 값을 읽어 각 네임스페이스의 Kubernetes Secret으로 동기화한다.
[ OpenBao ] ← 시크릿의 단일 진실 공급원, 회전·감사 이력 관리
│ ExternalSecret 리소스가 참조
▼
[ External Secrets Operator ]
│ 주기적으로 동기화
▼
[ 네임스페이스별 Kubernetes Secret ]
│ 일반 Secret처럼 마운트/환경변수로 주입
▼
[ 서비스 파드 ]
서비스 입장에서는 그냥 평범한 Kubernetes Secret을 쓰는 것과 다르지 않다 - OpenBao를 직접 호출하는 코드가 어디에도 없다. ESO가 백그라운드에서 동기화를 책임지기 때문에, OpenBao 쪽에서 값을 회전시키면 다음 동기화 주기에 맞춰 Secret도 갱신된다. 회전이 필요하면 배포를 다시 트리거하는 것만으로 새 값이 반영된다 - 서비스 코드나 매니페스트를 고칠 필요가 없다.
SealedSecret과의 역할 분담
두 도구를 같이 쓰는 기준은 결국 이 질문이다 - "이 시크릿의 진실 공급원이 Git이어야 하는가, 아니면 별도 저장소여야 하는가."
| SealedSecret | OpenBao + ESO | |
|---|---|---|
| 진실 공급원 | Git (암호화된 형태로) | OpenBao |
| 적합한 경우 | 값이 거의 안 바뀌는 서비스별 클라이언트 시크릿 | 회전이 필요하거나 여러 서비스가 공유하는 값 |
| 회전 방식 | 새로 kubeseal → 커밋 | OpenBao에서 값 변경 → 배포 재시작 |
| 이력 추적 | Git 커밋 이력 | OpenBao 자체 감사 로그 |
Keycloak 클라이언트 시크릿처럼 "서비스 하나에 매여 있고 자주 안 바뀌는" 값은 SealedSecret 쪽이 더 단순하다 - 별도 인프라(OpenBao) 없이 GitOps 흐름 안에서 끝난다. 반면 DB 크리덴셜처럼 "주기적으로 회전하거나 여러 서비스가 참조하는" 값은 OpenBao에 두는 쪽이 회전·감사 관점에서 낫다.
결과
두 시스템을 나눠 쓰면서 얻은 건 "시크릿 관리 도구를 하나로 통일하지 못했다"는 찜찜함이 아니라, 시크릿마다 실제로 필요한 속성이 다르다는 걸 인정한 구조다. 모든 시크릿을 하나의 방식으로 우겨넣었다면 회전이 필요한 값도 SealedSecret처럼 매번 재커밋해야 했거나, 반대로 거의 안 바뀌는 값도 OpenBao 운영 부담을 그대로 짊어졌을 것이다.
공통점은 하나 있다 - 어느 쪽이든 평문 시크릿이 Git에 직접 올라가는 경로가 없다. SealedSecret은 애초에 암호문만 커밋되고, OpenBao 경로는 Git에 아예 값이 들어가지 않는다. 시크릿 관리 도구를 고르는 기준은 여러 개일 수 있지만, "평문이 저장소에 노출되지 않는다"는 이 최소 기준만큼은 두 경로 모두 동일하게 지킨다.