🤫 쿠버네티스 시크릿 관리의 정석: Vault와 KMS로 etcd 데이터 안전하게 지키기

쿠버네티스(Kubernetes)를 운영하다 보면 데이터베이스 접속 정보, API 키, TLS 인증서 등 수많은 민감 정보를 다루게 됩니다. 그리고 이런 정보들은 쿠버네티스의 Secret 오브젝트로 생성되어 클러스터의 핵심 저장소인 etcd에 저장되죠.

하지만 여기에 한 가지 중요한 사실이 있습니다. **기본적으로 etcd에 저장되는 데이터는 암호화되지 않은 평문(Plain Text)**이라는 점입니다. 이는 etcd 데이터베이스 파일에 접근 권한이 있는 사람이라면 누구나 Secret의 내용을 쉽게 들여다볼 수 있다는 것을 의미합니다.

이번 글에서는 왜 etcd에 민감한 정보를 그대로 저장하는 것이 위험한지 알아보고, 클라우드 KMS와 HashiCorp Vault를 이용해 이 문제들을 어떻게 해결할 수 있는지 상세히 살펴보겠습니다.

---

 🚨 etcd, 비밀을 지키기엔 너무 위험한 곳

etcd는 분산 시스템의 상태를 안정적으로 저장하고 동기화하기 위해 설계된 강력한 키-값 저장소입니다. 하지만 '비밀번호 금고'와 같은 보안 기능에 특화된 솔루션은 아닙니다. etcd에 민감 정보를 그대로 저장할 때 발생하는 주요 위험은 다음과 같습니다.

1. 평문 저장의 위험: 앞서 말했듯, 별도의 설정을 하지 않으면 Secret 데이터는 Base64로 인코딩만 된 채 etcd에 저장됩니다. 이는 암호화가 아니며, 누구나 쉽게 디코딩하여 원본 내용을 볼 수 있습니다.
2. 광범위한 접근 가능성: 클러스터 관리자, 특정 권한을 가진 사용자, 그리고 API 서버와 통신하는 다양한 컴포넌트들이 etcd 데이터에 접근할 수 있습니다. 이는 공격 표면이 넓다는 것을 의미합니다.
3. 백업 파일 노출: 클러스터 장애 복구를 위해 etcd를 정기적으로 백업합니다. 만약 이 백업 파일이 암호화되어 있지 않다면, 파일이 유출되었을 때 클러스터의 모든 민감 정보가 한 번에 노출되는 심각한 보안 사고로 이어질 수 있습니다.
4. 로그 및 감사 기록: 시스템 로그나 감사 기록에 민감 정보가 평문으로 남을 가능성이 있어, 또 다른 유출 경로가 될 수 있습니다.

---

 🔒 해결책 1: 쿠버네티스의 내장 암호화 기능 활용 (Encryption at Rest with KMS)

쿠버네티스는 이러한 문제를 해결하기 위해 저장 데이터 암호화(Encryption at Rest) 기능을 제공합니다. 이 기능은 etcd에 데이터를 저장하기 전에 암호화하고, 데이터를 읽을 때 복호화하는 방식으로 동작합니다.

특히 클라우드 환경에서는 각 클라우드 제공사(AWS, GCP, Azure 등)가 제공하는 KMS(Key Management Service)와 연동하여 더욱 안전하고 편리하게 키를 관리할 수 있습니다.

동작 원리 (Envelope Encryption)

KMS 연동은 봉투 암호화(Envelope Encryption)라는 방식을 사용합니다.

1. kube-apiserver가 Secret과 같은 민감한 리소스를 암호화하기 위해 DEK(Data Encryption Key)라는 데이터 암호화 키를 생성합니다.
2. 생성된 DEK를 이용해 Secret 데이터를 암호화합니다.
3. kube-apiserver는 DEK 자체를 클라우드의 KMS에 보내 KEK(Key Encryption Key)라는 마스터 키로 암호화해달라고 요청합니다.
4. 암호화된 Secret 데이터와 암호화된 DEK를 etcd에 함께 저장합니다.

이 방식의 장점은 실제 마스터 키(KEK)가 클러스터 외부에 있는 안전한 KMS에 보관된다는 점입니다. KMS는 키 생성, 순환, 접근 제어, 감사 등 키 수명 주기 전반을 관리해주므로 보안성이 크게 향상됩니다.

https://cloud.google.com/kms/docs/envelope-encryption?hl=ko

 

---

 🏦 해결책 2: 외부 시크릿 관리 솔루션 사용 (HashiCorp Vault)

쿠버네티스 내장 암호화도 훌륭한 방법이지만, 더 많은 기능과 중앙화된 관리가 필요하다면 HashiCorp Vault와 같은 외부 시크릿 관리 솔루션을 사용하는 것이 좋습니다. 이 방식은 애초에 민감 정보를 etcd에 저장하지 않는다는 점에서 근본적인 차이가 있습니다.

동작 원리 (Secrets Operator Pattern)

Vault를 연동하는 가장 일반적인 방법은 Vault Agent Injector나 External Secrets Operator와 같은 패턴을 사용하는 것입니다.

1. 중앙화된 관리: 모든 민감 정보(DB 계정, API 키 등)는 Vault에 안전하게 저장하고 관리합니다. Vault는 동적 시크릿 생성, 자동 키 순환, 세분화된 접근 정책, 상세한 감사 로그 등 강력한 보안 기능을 제공합니다.
2. 인증: 쿠버네티스의 ServiceAccount를 이용해 파드(Pod)가 Vault에 자신을 인증합니다.
3. 시크릿 주입:
   • Vault Agent Injector: 파드가 생성될 때 사이드카(Sidecar) 형태로 Vault Agent 컨테이너를 자동으로 주입합니다. 이 에이전트가 Vault에 인증하여 필요한 시크릿을 가져온 후, 공유 볼륨이나 메모리에 파일 형태로 저장하여 애플리케이션 컨테이너에 제공합니다.
   • External Secrets Operator: 쿠버네티스 클러스터에 설치된 이 오퍼레이터는 ExternalSecret이라는 CRD(Custom Resource Definition)를 감시합니다. ExternalSecret에 Vault의 어떤 경로에서 시크릿을 가져올지 정의해두면, 오퍼레이터가 Vault에서 해당 시크릿을 가져와 쿠버네티스 Secret 오브젝트로 자동으로 생성해줍니다.
4. 애플리케이션 사용: 애플리케이션은 etcd가 아닌, Vault로부터 동적으로 주입된 시크릿을 사용합니다.

이 방식의 가장 큰 장점은 민감 정보가 etcd에 전혀 저장되지 않는다는 점과, 여러 클러스터와 애플리케이션의 시크릿을 하나의 Vault에서 중앙 집중적으로 관리할 수 있다는 것입니다.

 

https://developer.hashicorp.com/vault/tutorials/kubernetes-introduction/kubernetes-minikube-raft

 

 

 

---

결론: 무엇을 선택해야 할까?

etcd는 쿠버네티스의 심장이지만, 민감 정보를 보관하기 위한 안전한 금고는 아닙니다. 따라서 민감 정보 암호화는 선택이 아닌 필수입니다.

• KMS 연동: 클라우드 환경에서 비교적 간단하게 강력한 보안을 적용하고 싶을 때 훌륭한 선택입니다. 쿠버네티스 네이티브 기능을 활용하여 etcd에 저장되는 Secret을 안전하게 보호할 수 있습니다.
• HashiCorp Vault: 여러 클러스터와 애플리케이션에 걸쳐 시크릿을 중앙에서 관리하고, 동적 시크릿 생성이나 자동 순환과 같은 고급 기능이 필요할 때 가장 이상적인 솔루션입니다.

어떤 방식을 선택하든, 더 이상 민감한 정보를 평문 그대로 etcd에 방치해서는 안 됩니다. 지금 바로 클러스터의 보안 수준을 한 단계 높여보세요.