Transit 플러그인 auto-unseal 모범 사례

이 문서는 HSM이나 클라우드 기반 KMS auto-unseal 메커니즘을 사용할 수 없는 환경(예: 내부 데이터 센터 배포)에서 Vault로 auto-unseal을 위한 실용적인 솔루션을 만드는 프레임워크를 제공합니다.

출처: 문서

본문

용어집

리전(Region): 개인적이고, 지연 시간이 낮으며, 높은 대역폭을 가진 네트워킹 환경입니다. 퍼블릭 인터넷을 통과하는 통신을 제외하며, 보통 단일 물리 데이터 센터 또는 클라우드 리전입니다. 리전은 일반적으로 하나 이상의 가용 영역(availability zone)으로 구성됩니다.
클러스터(Cluster): Vault를 고가용성 방식으로 운영하기 위한 완전한 배포 단위입니다. 하나의 active Vault 노드와 임의 개수의 standby 및/또는 performance standby Vault 노드로 구성됩니다. 단일 클러스터의 모든 노드는 데이터 영속화를 위해 같은 storage backend를 공유합니다.
기본 클러스터(Primary cluster): Vault Enterprise 복제 모드는 리더-팔로워 패턴을 사용합니다. 리더 클러스터를 기본 클러스터라고 합니다. Vault 복제 관계에서 기본 클러스터는 모든 공유 데이터를 구성된 storage backend에 기록할 책임이 있습니다.
보조 클러스터(Secondary cluster): Vault Enterprise 복제 모드는 리더-팔로워 패턴을 사용합니다. 팔로워 클러스터를 보조 클러스터라고 합니다. 데이터는 기본 클러스터에서 구성된 모든 보조 클러스터로 스트리밍됩니다.

Transit secrets engine

transit secrets engine은 전송 중인 데이터에 대한 암호화 함수를 처리합니다. Vault는 secrets engine으로 보내진 데이터를 저장하지 않습니다. 이는 "cryptography as a service" 또는 "encryption as a service"라고도 합니다. transit secrets engine은 데이터를 서명하고 검증하고, 데이터의 해시와 HMAC를 생성하고, 무작위 바이트 소스로도 작동할 수 있습니다.

transit secrets engine의 주요 사용 사례는 애플리케이션의 데이터를 암호화하면서도 그 암호화된 데이터를 일부 기본 데이터 저장소에 계속 저장하는 것입니다. 이는 애플리케이션 개발자에게서 적절한 암호화/복호화의 부담을 덜고 그 책임을 Vault 운영자에게 옮깁니다.

키 유도(key derivation)가 지원되므로, 사용자가 제공한 컨텍스트 값에 기반한 새 키를 유도해 같은 키를 여러 목적으로 사용할 수 있습니다. 이 모드에서 transit secrets engine은 수렴 암호화(convergent encryption)를 지원해 같은 입력 값이 같은 암호문을 생성하게 할 수 있습니다.

데이터키(datakey) 생성은 프로세스가 지정된 비트 길이의 고엔트로피 키를, 명명된 키로 암호화된 상태로 반환받도록 요청할 수 있게 합니다. 보통 이렇게 하면 즉시 사용할 수 있도록 키도 평문으로 반환하지만, 감사 요구 사항에 따라 이를 비활성화할 수 있습니다.

Vault는 외부 Vault 클러스터의 마운트된 transit secrets engine을 봉인 해제 자료를 복호화하는 신뢰 시스템으로 사용할 수 있어, 봉인 해제 작업을 자동화할 수 있습니다. 이 작업은 sealed Vault 서버가 자신을 봉인 해제하는 Vault의 위치와 알려진 transit 키에 대해 암호화/복호화할 수 있는 적절한 권한을 가진 유효한 토큰을 알고 있다고 가정합니다.

권장 구성

봉인 해제 작업을 위한 transit 키만 보관하는 최소 구성 Vault 클러스터를 세워 Vault 클러스터에 봉인 해제 기능을 제공하세요. 이 Vault 클러스터는 일반 클라이언트 요청을 처리하기 위한 것이 아니며, 복원력 요구 사항이 더 낮습니다. 종종 최소한의 오버헤드와 복잡성을 가진 작은 "Unseal as a Service" Vault를 원하게 됩니다.

다만 이 봉인 해제 Vault 클러스터는 기본 Vault 클러스터의 시크릿 데이터를 보호하는 체인의 한 엔티티가 됩니다. 따라서 여전히 민감한 자료를 포함합니다.

봉인 해제 Vault 클러스터는 작은 가상 머신이나 컨테이너에 배포할 수 있습니다. 리소스를 최소화하려면 단일 노드 클러스터로 실행할 수 있습니다. 단순함을 위해 filesystem storage backend 같은 비-HA 지원 backend를 사용하는 것이 일반적인 관행입니다.

정책 요구 사항

기본 Vault 클러스터는 자신을 봉인 해제하기 위해 봉인 해제 Vault 클러스터에서 유효한 Vault 토큰이 필요합니다. Vault Agent 또는 스크립트 프로세스를 활용해 Vault로 인증함으로써 토큰을 얻으세요. Vault 토큰은 Vault 구성 파일에 쓰는 대신 환경 변수에 저장하는 것을 권장합니다.

Vault 토큰은 사용 중인 transit 키의 암호화 및 복호화 엔드포인트에 대한 권한을 부여하는 Vault 정책이 있어야 합니다. 아래는 예시 정책입니다.

path "<mount path>/encrypt/<key_name>" {
  capabilities = ["update"]
}

path "<mount path>/decrypt/<key_name>" {
  capabilities = ["update"]
}

배포 고려 사항

더 복잡한 Vault 토폴로지에는 몇 가지 과제가 있습니다. 이러한 우려 중 일부는 봉인 해제 Vault 사용 패턴에 보편적으로 적용되고, 일부는 여러 데이터 센터 간 복제를 활용하는 Vault 토폴로지에 더 특화되어 있습니다.

봉인 해제 Vault를 봉인 해제

봉인 해제 Vault 클러스터 자체도 시작 시 봉인 해제가 필요합니다. 실제로 이 패턴은 자동화되지 않은 봉인 해제의 부담을 프로덕션 서비스 Vault 클러스터에서 지원 서비스 봉인 해제 Vault로 옮길 뿐입니다. 서비스에서 수동 작업을 관리하면 그 서비스에 더 가벼운 부하가 걸립니다.

봉인 해제 Vault 주소

봉인 해제 작업에는 환경 변수 또는 구성 값으로 대상 Vault 서버 주소가 필요하므로, 봉인 해제 Vault의 네트워크 위치에 대한 신뢰할 수 있는 참조가 필요합니다. 이 문제는 Consul 같은 서비스 검색 시스템을 사용하는 것이 가장 우아합니다. 그러한 도구가 없다면 환경의 기능과 활용되는 패턴에 따라 관리 DNS 항목, 로드 밸런서 VIP, Anycast IP 주소 같은 서비스 위치의 추상화된 참조를 사용하세요.

복제 관련 우려

기본 Vault 클러스터 간에 Vault 복제를 구성한 다중 사이트 배포에서 작업할 때 봉인 해제 동작에 대한 추가 우려가 발생할 수 있습니다. 복제 구성의 각 클러스터에는 알려진 봉인 해제 Vault가 필요합니다. 모든 복제된 클러스터에 단일 봉인 해제 Vault를 사용하는 것이 가능하지만, 모든 클러스터와 단일 사이트 간의 네트워크 연결이 필요할 것입니다. 각 데이터 센터에 봉인 해제 Vault를 제공하는 것을 권장합니다.

키 회전

봉인 해제 Vault 클러스터에서 봉인 해제 키를 회전할 때 각 데이터 센터의 각 Vault primary에서 회전 작업을 실행하세요. 일부 시나리오에서는 storage backend를 각 데이터 센터로 특정 시점 복제하며 모든 봉인 해제 Vault에 같은 구성을 사용할 수 있습니다. 이 옵션을 선택한다면 각 기본 클러스터에 고유한 키를 사용해 회전 작업이 일관되도록 하고, 각 회전을 같은 봉인 해제 Vault에 대해 실행하는 것을 권장합니다. 그렇지 않으면 각 회전 사이에 복제 작업을 수행해야 합니다.

Transit 플러그인 auto-unseal 모범 사례