kt cloud PLATFORM 보안 거버넌스 구축: Vault 도입과 효율적인 시크릿 전달 전략 (ESO & CSI)
핵심 내용
GitOps 환경의 시크릿 문제를 Vault, ESO, CSI로 분리해 해결한다.
자세히 보기
GitOps로 인프라를 코드화해도 시크릿(Secret) 은 별도 보안 체계가 필요하다. Kubernetes Secret은 사실상 평문에 가깝고, Git 저장소에 남기면 유출·감사·권한 통제 문제를 동시에 안게 된다.
이를 해결하기 위해 HashiCorp Vault 를 중앙 금고로 두고, 시크릿 전달 방식은 두 축으로 나눈다.
- External Secrets Operator(ESO): Vault의 값을 Kubernetes Secret으로 동기화한다.
- Vault CSI Provider: 시크릿을 etcd에 남기지 않고 Pod 실행 시 메모리 기반(tmpfs) 으로 직접 주입한다.
ESO는 기존 애플리케이션의 환경 변수 사용 방식을 거의 바꾸지 않아 전환 비용이 낮고, Vault 값이 바뀌면 Kubernetes Secret도 자동으로 갱신된다. 반면 CSI Provider는 시크릿을 Kubernetes 객체로 저장하지 않아 보안성이 더 높고, Pod가 종료되면 메모리에서도 함께 사라진다.
선택 기준도 분명하다. 호환성과 운영 편의성 이 우선이면 ESO가 적합하고, 강한 보안과 규정 준수 가 필요하면 CSI Provider가 맞다.
- ESO 추천: 범용 웹 서비스, 레거시 애플리케이션의 클라우드 전환, 환경 변수 기반 마이크로서비스
- CSI 추천: 금융 서비스, 고권한 API Key 관리, AI Foundry 처럼 데이터 보호가 중요한 워크로드
운영 전략의 핵심은 Vault를 단순 저장소가 아니라 보안 거버넌스 엔진 으로 다루는 것이다. 이를 위해 Kubernetes Auth Method 로 Pod의 ServiceAccount와 Vault를 연동해 별도 비밀번호 없이 인증하고, 멀티-AZ HA 와 Raft 기반 구성으로 단일 장애점을 줄여야 한다.
또한 권한은 네임스페이스와 경로 단위로 최소화해야 한다. projects/{team-name}/{env}/ 같은 표준 경로를 두고, 각 워크로드는 자신에게 허용된 Secret만 읽도록 설계해야 플랫폼 차원의 보안 경계가 유지된다.
결국 이 아키텍처는 보안을 개별 팀의 숙제가 아니라 플랫폼이 제공하는 기본 기능 으로 바꾸는 작업이다. 개발자는 시크릿 관리보다 비즈니스 로직과 모델 개발에 집중하고, 플랫폼은 Vault와 ESO, CSI로 뒤에서 보안 가드레일을 책임진다.
이 한국어 요약은 AI가 자동으로 만들었습니다. 원문의 주장과 맥락은 원문에서 확인해 주세요. 저작권은 원저작자에게 있습니다.