SRE / DevOps 시작하기 (3) - 기반공사

SRE / DevOps 시작하기 (3) - 기반공사

Photo by Andres Idda Bianchi from Pexels: https://www.pexels.com/photo/skyscrapers-by-the-river-at-night-15087220/

KMS: AWS Secret Manager vs Vault

KMS와 같은 시스템은 on-premise 또는 이에 준하는 환경에서 구현되어야 한다는 것이 나의 기본적인 관점이다. 회사 건물 내에 물리적으로 존재하고, 외부 망으로부터 분리된 서버를 완전히 대체할 수 있는 옵션은 현실적으로 없다.

 

데이터를 독립된 키로 암호화하는 방식 등이 존재하긴 하지만, 그럼에도 불구하고 내가 직접 제어할 수 있는 인스턴스 위에서 보안 시스템을 독립적으로 구축한다는 것은 여전히 의미가 있다.

 

AWS Secret Manager를 써본 사람은 알 거다. 간단한 키 하나 관리하려다가 AWS 계정 구조, IAM 정책, 서비스 연동이 덕지덕지 붙는다. 추상화가 직관적이지 않아서 뭘 하고 있는지 모르게 되는 순간이 온다. 그리고 그 불편함에 돈을 낸다.

 

두 가지 질문으로 정리된다.

 

첫째, 보안성을 신뢰할 수 있나.

 

AWS의 인프라가 뚫릴 가능성보다, 내가 통제할 수 없는 곳에 시크릿이 있다는 구조적 문제가 더 크다. 벤더가 정책을 바꾸거나, 계정이 잠기거나, 서비스가 변경되는 순간 내 시크릿 관리 체계 전체가 흔들린다.

 

둘째, 비용 대비 효율성이 존재하나.

그 불편함을 감수하면서 돈까지 내야 한다.

 

Vault는 다르다. CLI로 직접 제어하고, 의존성이 없고, 내가 띄운 인스턴스 위에서 돌아간다. 1편에서 말한 것과 같은 원칙이다 — 벤더가 정책을 바꿔도 내 시크릿 관리 체계는 흔들리지 않아야 한다.

 

KV(Key-Value) 시크릿 엔진 위에서 동작하고, 초기 구성은 단순하다.

# KV v2 엔진 활성화
vault secrets enable -path=secret kv-v2

# 시크릿 저장
vault kv put secret/infra/github username="..." password="..."
vault kv put secret/services/jenkins vault-token="..."

 

경로 구조만 잡히면 끝이다. infra/는 공통 인프라 시크릿, services/는 서비스별 시크릿. Jenkins 파이프라인은 이 경로를 참조할 뿐이다.