아키텍처
아키텍처 (Architecture)
Vault는 수많은 개별 구성 요소로 이루어진 복잡한 시스템입니다. 이 페이지는 시스템 아키텍처를 자세히 설명하며, Vault 사용자와 개발자가 동작 원리를 이해하면서 정신적 모델을 구축하는 데 도움을 주고자 합니다.
출처: 문서
본문
참고: 이 페이지는 Vault의 기술적 세부 사항을 다룹니다. 여기에 포함된 설명과 요소들은 소스 코드를 참조하지 않고 Vault를 배우고자 하는 사용자를 위한 것입니다. 필수는 아니지만, Vault가 환경에서 차지하는 중요성 때문에 모든 사용자와 운영자에게 Vault 사용 전에 제공된 정보를 검토할 것을 권장합니다.
상위 수준 개요 (High-Level overview)
아래 다이어그램은 Vault의 복잡한 구성 요소와 개별 구성 요소들을 보여줍니다.
Vault의 암호화 계층인 barrier 는 Vault 데이터를 암호화하고 복호화하는 역할을 담당합니다. Vault 서버가 시작되면 데이터를 스토리지 백엔드에 씁니다. 스토리지 백엔드는 barrier 외부에 있으므로 신뢰할 수 없는 것으로 간주되어, Vault는 데이터를 스토리지 백엔드로 보내기 전에 암호화합니다. 이 메커니즘은 악의적인 공격자가 스토리지 백엔드에 접근하려 해도, Vault가 데이터를 복호화하기 전까지는 데이터가 암호화된 상태로 유지되므로 손상될 수 없음을 보장합니다. 스토리지 백엔드는 서버 재시작에도 데이터가 안전하고 사용 가능하게 유지되는 내구성 있는 데이터 영속 계층을 제공합니다.
Vault 서버가 시작되면 봉인(sealed) 상태로 시작합니다. Vault에서 어떤 작업을 수행하기 전에 반드시 봉인 해제(unseal)를 해야 합니다. 이것은 봉인 해제 키를 제공함으로써 이루어집니다. Vault 초기화 과정에서 Vault는 모든 Vault 데이터를 보호하는 데 사용되는 암호화 키를 생성합니다. 이 키는 다른 모든 Vault 데이터와 함께 저장되지만 다른 메커니즘인 봉인 해제 키(unseal key) 로 암호화되는 루트 키(root key) 에 의해 보호됩니다.
기본적으로 Vault는 Shamir's Secret Sharing을 사용해 봉인 해제 키를 구성된 수의 조각(shard, 즉 키 공유 또는 봉인 해제 키)으로 나눕니다. 봉인 해제 키를 재구성하려면 정확한 수의 조각이 필요하며, 그 키가 Vault의 루트 키를 복호화하는 데 사용됩니다.
Seal/Unseal 문서에서 더 자세한 내용을 참고하세요. 공유 수와 필요한 최소 조각 수를 모두 지정할 수 있습니다. Shamir 기법을 비활성화하고 루트 키를 직접 봉인 해제에 사용할 수도 있습니다. Vault가 암호화 키를 검색하면 스토리지 백엔드의 데이터를 복호화하고 봉인 해제 상태로 들어갑니다. 일단 봉인 해제되면 Vault는 요청을 처리할 수 있습니다.
Vault의 처리 흐름은 다음과 같습니다. 클라이언트가 처음 Vault에 연결하면 인증해야 합니다. Vault는 구성 가능한 인증 메서드를 제공하며 사용되는 인증 메커니즘에 유연성을 부여합니다. 운영자는 username/password나 GitHub 같은 메커니즘을 사용할 수 있고, 애플리케이션은 공개/개인 키나 토큰으로 인증할 수 있습니다. core를 통과해 인증 메서드로 흘러 들어가는 인증 요청은 요청이 유효한지 판별하고 연결된 정책 목록을 반환합니다.
정책은 이름이 붙은 ACL 규칙일 뿐입니다. 예를 들어 "root" 정책은 내장되어 있으며 모든 리소스에 대한 접근을 허용합니다. 경로에 대한 세밀한 제어로 원하는 만큼 많은 이름의 정책을 만들 수 있습니다. Vault는 허용-접근 모드로 작동하므로, 정책으로 접근이 명시적으로 부여되지 않으면 그 동작은 허용되지 않습니다. 사용자에게 여러 정책이 연결될 수 있으므로, 정책이 허용하면 그 동작이 허용됩니다. 정책은 내부 정책 저장소(policy store)에 저장되고 관리되며, 이 내부 저장소는 항상 sys/ 에 마운트되는 시스템 백엔드를 통해 영향을 받습니다.
인증이 이루어지고 인증 메서드가 적용 가능한 정책 세트를 제공하면, 새 클라이언트 토큰이 생성되어 토큰 저장소(token store)에서 관리됩니다. 이 클라이언트 토큰은 이후 요청에 사용됩니다. 이 토큰 방식은 사용자가 로그인할 때 웹사이트가 보내는 쿠키와 비슷합니다. 인증 메서드 구성에 따라 클라이언트 토큰에는 임대(lease)가 연결될 수 있으며, 무효화를 피하려면 주기적으로 갱신해야 할 수 있습니다.
인증 후에는 클라이언트 토큰을 제공해 요청을 만듭니다. 클라이언트 토큰은 관련 정책을 로드하면서 클라이언트를 검증하고 권한을 확인하는 데 사용됩니다. 정책은 클라이언트 요청을 인가(authorize)하는 데 사용됩니다. 그런 다음 요청은 시크릿 엔진으로 라우팅되어 그 유형에 따라 처리됩니다. 시크릿 엔진이 시크릿을 반환하면 core는 그것을 만료 관리자(expiration manager)에 등록하고 임대 ID를 붙입니다. 클라이언트는 임대 ID로 시크릿을 갱신하거나 폐기합니다. 클라이언트가 임대가 만료되도록 두면 만료 관리자가 그 시크릿을 자동으로 폐기합니다.
core는 요청과 응답을 감사 브로커(audit broker)에 기록해 모든 구성된 감사 장치에 분배합니다. 요청 흐름 밖에서 core는 특정 백그라운드 활동을 수행합니다. 임대 관리는 만료된 클라이언트 토큰이나 시크릿을 자동으로 폐기할 수 있게 해주므로 중요합니다. 또한 Vault는 write-ahead 로깅과 롤백 관리자(rollback manager)로 특정 부분 실패 사례를 처리합니다. 이것은 core 내에서 투명하게 관리되며 사용자에게 보이지 않습니다.
리소스 (Resources)
- Vault 안의 각 구성 요소와 하위 시스템에 대해 더 알아보려면 왼쪽 탐색 메뉴에서 주제를 선택하세요.
- 자세한 내용은 코드를 참고하세요.
- Vault를 시작하려면 Getting Started 튜토리얼을 사용해 보세요.