Agent Injector vs Vault CSI

Agent Injector vs Vault CSI (Sidecar vs CSI provider)

Vault와 쿠버네티스를 통합하는 Agent Injector(Sidecar) 방식과 Vault CSI 제공자 방식을 비교합니다.

출처: 문서

본문

이 문서는 HashiCorp Vault를 쿠버네티스와 통합하는 두 가지 방법을 살펴봅니다. 이 정보는 시크릿 관리 개념을 이해하고 HashiCorp Vault와 쿠버네티스에 익숙한 DevOps 실무자를 위한 것입니다. 또한 이 문서는 사용 사례에 가장 적합한 방법을 이해하고 선택하는 데 도움이 되는 실용적인 지침을 제공합니다.

이 문서에 담긴 정보는 이 문서에서 Vault Sidecar 또는 Sidecar 라고도 하는 Agent Injector와, Vault와 쿠버네티스를 통합하는 데 사용하는 Vault CSI(Container Storage Interface) 제공자 사이의 대비를 자세히 다룹니다.

Vault Agent Injector

Vault Agent Injector는 sidecar 패턴을 활용해 파드 명세를 변경해 Vault 시크릿을 공유 메모리 볼륨에 렌더링하는 Vault Agent 컨테이너를 포함시킵니다. 시크릿을 공유 볼륨에 렌더링함으로써 파드 안의 컨테이너들은 Vault를 인식하지 않아도 Vault 시크릿을 사용할 수 있어요. injector는 쿠버네티스 변경(mutating) webhook 컨트롤러예요. 컨트롤러는 파드 이벤트를 가로채 요청 안에 어노테이션이 있으면 파드에 변경을 적용합니다. 이 기능은 vault-k8s 프로젝트가 제공하며 Vault Helm 차트로 자동 설치·구성할 수 있어요.

Vault CSI 제공자

Vault CSI 제공자는 임시(ephemeral) CSI Secrets Store 볼륨으로 파드가 Vault 시크릿을 사용하게 해 줍니다. 높은 수준에서 CSI Secrets Store 드라이버는 사용자가 SecretProviderClass 객체를 만들 수 있게 합니다. 이 객체는 어떤 시크릿 제공자를 사용하고 무엇을 가져올지 정의해요. CSI 볼륨을 요청하는 파드가 만들어지면, 제공자가 vault라면 CSI Secrets Store 드라이버는 요청을 Vault CSI 제공자로 보냅니다. 그러면 Vault CSI 제공자는 지정된 SecretProviderClass와 파드의 서비스 어카운트를 사용해 Vault에서 시크릿을 가져와 파드의 CSI 볼륨에 마운트합니다. 시크릿은 ContainerCreation 단계에서 Vault에서 검색되어 CSI 시크릿 저장소 볼륨에 채워집니다. 따라서 파드는 Vault에서 시크릿을 읽어 볼륨에 쓸 때까지 시작이 차단됩니다.

참고: 시크릿은 파드 라이프사이클의 더 이른 시점에 가져오므로 Istio 같은 Sidecar와의 호환성 문제가 더 적어요.

두 솔루션의 유사점과 차이점을 살펴보기 전에, 몇 가지 공통 설계 고려사항을 알아봅시다.

시크릿 투영(projection): 모든 애플리케이션은 시크릿이 명시적으로 표시되도록 요구합니다. 일반적으로 애플리케이션은 시크릿이 환경 변수로 내보내지거나 애플리케이션 패키지가 시작 시 읽을 수 있는 파일로 기록되길 기대해요. 적절한 방법을 결정할 때 이것을 염두에 두세요.
시크릿 범위(scope): 일부 애플리케이션은 데이터 센터, 에지, 공용 클라우드에 걸친 여러 쿠버네티스 환경(예: dev, qa, prod)에 배포됩니다. 일부 서비스는 VM, 서버리스, 기타 클라우드 관리 서비스의 쿠버네티스 밖에서 실행됩니다. 이 애플리케이션들이 이런 이기종 환경에 걸쳐 시크릿 집합을 공유해야 하는 시나리오가 있을 수 있어요. 시크릿을 쿠버네티스 환경에 국한하거나 다른 환경에 걸쳐 전역으로 범위를 올바르게 지정하면 각 애플리케이션이 배포된 환경 안에서 자신의 시크릿 집합에 쉽고 안전하게 접근할 수 있습니다.
시크릿 타입: 시크릿은 텍스트 파일, 바이너리 파일, 토큰, 인증서이거나 정적·동적으로 생성될 수 있어요. 또 영구적으로 유효하거나 시간 범위가 있을 수 있고 크기도 다양할 수 있습니다. 애플리케이션이 요구하는 시크릿 타입과 애플리케이션에 어떻게 투영되는지 고려해야 해요.
시크릿 정의: 각 시크릿이 어떻게 정의·생성·업데이트·제거되는지와 그 과정에 관련된 도구도 고려해야 합니다.
암호화: 저장 데이터와 전송 중 데이터를 모두 암호화하는 것은 많은 기업 조직의 핵심 요구사항이에요.
거버넌스: 애플리케이션과 시크릿은 다대다 관계를 가질 수 있는데, 애플리케이션이 각자의 시크릿을 가져갈 수 있도록 접근을 부여할 때 세심한 고려가 필요합니다. 애플리케이션과 시크릿 수가 늘어날수록 접근 정책 관리의 어려움도 커집니다.
시크릿 업데이트와 회전: 시크릿은 리스(lease)되거나 시간 범위가 있거나 자동 회전될 수 있으며, 새 시크릿이 애플리케이션 파드에 제대로 전파되도록 각 시나리오는 프로그래밍 프로세스여야 합니다.
시크릿 캐싱: 특정 쿠버네티스 환경(예: 에지, 리테일)에서는 환경과 시크릿 저장소 사이의 통신·네트워크 실패 시 시크릿 캐싱이 필요할 수 있어요.
감사 가능성: 모든 시크릿 접근 정보를 상세히 담은 시크릿 접근 감사 로그를 유지하는 것은 시크릿 접근 이벤트의 추적 가능성을 보장하는 데 중요합니다.

이제 일부 설계 고려사항에 익숙해졌으니, 쿠버네티스 환경에서 시크릿 관리 전략을 설계·구현할 때 사용할 최적의 솔루션을 결정하는 데 도움을 주기 위해 두 솔루션의 유사점과 차이점을 살펴봅시다.

유사점 (Similarities)

Agent Injection과 Vault CSI 솔루션 모두 다음의 유사점이 있어요.

Vault에 저장된 다양한 타입의 시크릿 검색을 단순화하고, 그리 사소하지 않은 Vault 프로세스를 알지 않아도 쿠버네티스에서 실행되는 대상 파드에 노출합니다. 이 솔루션들을 사용하는 데 애플리케이션 로직이나 코드를 바꿀 필요가 없어 기존(brownfield) 애플리케이션을 쿠버네티스로 마이그레이션하기 더 쉬워진다는 점에 주목하세요. 그린필드(greenfield) 애플리케이션 개발자는 Vault SDK를 활용해 Vault와 직접 통합할 수 있어요.
모든 타입의 Vault 시크릿 엔진을 지원합니다. 이 지원으로 정적 키-값 시크릿부터 동적으로 생성된 데이터베이스 자격 증명, 커스텀 TTL의 TLS 인증서까지 광범위한 시크릿 타입을 활용할 수 있어요.
애플리케이션의 쿠버네티스 파드 서비스 어카운트 토큰을 Secret Zero로 활용해 쿠버네티스 인증 방식으로 Vault에 인증합니다. 이 방식으로는 애플리케이션 파드를 Vault에 인증할 때 또 다른 별도 신원을 관리할 필요가 없어요.
두 방식 모두 시크릿 수명이 파드의 수명에 묶입니다. 파드 안의 파일 내용뿐 아니라 CSI가 만드는 쿠버네티스 시크릿에도 이 내용이 해당됩니다. 시크릿은 파드가 생성·삭제되면서 자동으로 생성·삭제돼요.
둘 다 애플리케이션을 배포하기 전에 원하는 시크릿이 Vault 안에 존재해야 합니다.
둘 다 파드의 서비스 어카운트가 원하는 시크릿에 대한 접근 권한을 부여하는 정책을 가진 Vault 역할에 바인딩되어야 해요(즉, 쿠버네티스 RBAC가 시크릿 접근을 인가하는 데 사용되지 않습니다).
둘 다 Helm으로 배포할 수 있어요.
둘 다 파드가 시작되기 전에 Vault에서 시크릿 검색에 성공해야 합니다.
둘 다 Vault에서 필요한 시크릿을 가져오기 위해 사용자 정의 파드 어노테이션에 의존합니다.

차이점 (Differences)

유사점을 이해했으니, 고려할 두 솔루션 사이의 차이점이 있어요.

Sidecar Agent Injector 솔루션은 두 요소로 구성됩니다.
- Sidecar Service Injector — 클러스터 서비스로 배포되며 쿠버네티스 apiserver 파드 이벤트를 가로채 필요한 sidecar 컨테이너를 추가하도록 파드 스펙을 변경하는 역할.
- Vault Sidecar Container — 각 애플리케이션 파드와 함께 배포되며 Vault에 인증하고, Vault에서 시크릿을 가져오고, 애플리케이션이 사용할 시크릿을 렌더링하는 역할.
반면 Vault CSI 드라이버는 쿠버네티스 클러스터의 모든 노드에 daemonset으로 배포되며, 지정된 Secret Provider Class와 파드의 서비스 어카운트를 사용해 Vault에서 시크릿을 가져와 파드의 CSI 볼륨에 마운트합니다.
Sidecar Agent Injector는 모든 Vault auto-auth 방식을 지원합니다. Sidecar CSI 드라이버는 Vault의 Kubernetes 인증 방식만 지원해요.
각 애플리케이션 파드와 함께 시작되는 Sidecar 컨테이너는 auto-auth, 템플릿, 캐싱 같은 강력한 기능 집합을 제공하는 Vault Agent를 사용합니다. CSI 드라이버는 Vault Agent를 사용하지 않으므로 이런 기능이 없어요.
Vault CSI 드라이버는 Vault 시크릿을 쿠버네티스 시크릿과 환경 변수로 렌더링하는 것을 지원합니다. Sidecar Injector Service는 시크릿을 쿠버네티스 시크릿으로 렌더링하는 것을 지원하지 않지만, agent templating으로 시크릿을 환경 변수로 렌더링하는 방법이 있어요.
CSI 드라이버는 파드에 임시 볼륨을 마운트할 때 hostPath를 사용하는데, 일부 컨테이너 플랫폼(예: OpenShift)은 이것을 기본으로 비활성화합니다. 반면 Sidecar Agent Service는 메모리 내 tmpfs 볼륨을 사용해요.
Sidecar Injector Service는 자동으로 시크릿/토큰을 갱신·회전·가져오지만, CSI 드라이버는 그것을 지원하지 않습니다.

비교표 (Comparison chart)

참고: 공유 메모리 볼륨의 환경 변수는 Agent templating으로 달성할 수 있어요.

네이티브 쿠버네티스 시크릿을 넘어서

겉보기에는 쿠버네티스 네이티브 시크릿이 위의 두 접근 방식과 비슷해 보일 수 있지만, 둘 사이에는 상당한 차이가 있어요.

쿠버네티스는 시크릿 관리 솔루션이 아니에요. 네이티브 시크릿 지원이 있지만, 이는 엔터프라이즈 시크릿 관리 솔루션과는 꽤 다릅니다. 쿠버네티스 시크릿은 클러스터에만 범위가 지정되며, 많은 애플리케이션은 쿠버네티스 밖이나 다른 쿠버네티스 클러스터에서 실행되는 일부 서비스를 가집니다. 이런 애플리케이션이 쿠버네티스 환경 밖에서 쿠버네티스 시크릿을 사용하는 것은 번거롭고 인증·인가 문제를 일으킵니다. 따라서 설계 과정의 일부로 시크릿 범위를 고려하는 것이 중요해요.
쿠버네티스 시크릿은 본질적으로 정적입니다. kubectl이나 쿠버네티스 API로 시크릿을 정의할 수 있지만, 한 번 정의되면 etcd에 저장되고 파드 생성 중에만 파드에 표시됩니다. 이런 방식으로 정의하면 시크릿이 오래되거나, 낡거나, 만료되는 시나리오가 생겨 시크릿을 업데이트·회전하고 새 버전을 사용하도록 애플리케이션을 재배포하는 추가 워크플로가 필요할 수 있는데, 이는 복잡성을 더하고 꽤 시간이 걸릴 수 있어요. 설계 과정의 일부로 시크릿 신선도, 업데이트, 회전에 대한 모든 요구사항을 고려해야 합니다.
시크릿 접근 관리 보안 모델은 쿠버네티스 RBAC 모델에 묶여 있습니다. 이 모델은 쿠버네티스에 익숙하지 않은 사용자에게는 어려울 수 있어요. 플랫폼에 구애받지 않는 보안 거버넌스 모델을 채택하면 애플리케이션이 어떻게·어디서 실행되든 그에 맞는 워크플로를 적용할 수 있습니다.

요약 (Summary)

쿠버네티스에서 시크릿 관리를 설계하는 것은 복잡한 작업이에요. 각각의 특성을 가진 여러 접근 방식이 있습니다. 이 문서에 제시된 옵션을 탐색해 내부 동작을 더 잘 이해하고 사용 사례에 가장 적합한 옵션을 결정할 것을 권장해요.

Agent Injector vs Vault CSI