스토리지
스토리지 (Storage)
Vault의 스토리지 백엔드(Storage backend) 는 암호화된 정보를 보관하는 데만 사용되는 신뢰하지 않는(untrusted) 저장소입니다. Vault의 아키텍처 페이지에 설명된 대로, 스토리지 계층은 데이터를 해석하거나 해독할 필요가 없습니다.
출처: 문서
본문
지원되는 스토리지 백엔드
엔터프라이즈 고객을 위해 HashiCorp는 Vault의 통합 스토리지(Integrated Storage) 와 Consul 을 공식 지원 스토리지 백엔드로 제공합니다. Vault Enterprise 고객은 최상의 결과를 위해 이 지원 백엔드를 사용하는 것을 강력히 권장합니다. Vault Enterprise 1.12.0은 통합 스토리지나 Consul이 아닌 백엔드로 구성하면 시작되지 않았는데, 이는 트랜잭션 스토리지를 지원하지 않는 미지원 백엔드의 문제를 방지하기 위함이었습니다. 1.12.2부터는 이 동작이 바뀌어 미지원 백엔드를 쓰면 경고만 기록하고 Vault는 시작합니다.
그 외에도 커뮤니티 지원으로 사용할 수 있는 스토리지 옵션이 많습니다. 스토리지 구성 섹션에서 자세히 확인할 수 있으며, 어느 백엔드를 쓸지 결정하려면 설정 페이지의 "통합 스토리지 vs 외부 스토리지" 섹션을 참조하세요.
백업 (Backups)
Vault의 스토리지 구성은 매우 유연하므로, Vault 백업에 대한 정확한 지침을 제공하기는 어렵습니다. Vault를 백업할 때 고려할 두 가지가 있습니다.
- 스토리지 백엔드에 있는 Vault의 암호화된 데이터
- Vault 서버를 실행하기 위한 설정 파일과 관리 스크립트
또한 "백업으로 막으려는 오류 상황이 무엇인가"라는 큰 질문도 있습니다.
왜 백업을 하나요?
지속적인 백업·재해 복구 전략을 세울 때 "왜 백업을 하는가"를 고려하는 것이 중요합니다. Vault 스토리지는 다운그레이드가 항상 가능한 것은 아니므로, 업그레이드 전에 백업하는 것을 권장합니다. 일반적으로 클러스터에 주요 변경을 계획할 때마다 백업하는 것이 좋습니다.
구체적으로, /sys API에 쓰기 작업(업그레이드, 리키 등)을 하기 전에 백업하는 것을 권장합니다. 단, /sys/leases, /sys/namespaces, /sys/tools, /sys/wrapping, /sys/policies, /sys/pprof 엔드포인트는 제외합니다. 백업은 우발적인 데이터 삭제나 변경 복구에도 도움이 됩니다.
개별 머신의 고장 방지 목적으로는 백업을 권장하지 않습니다. Vault 서버는 클러스터로 실행할 수 있으므로 서버 고장에 대비하려면 Vault를 HA 모드로 실행하는 것을 권장합니다. Vault Enterprise는 복제된 클러스터와 데이터센터 고장에 대한 재해 복구를 지원합니다. 결론적으로 백업은 HA 실행이나 Vault Enterprise의 복제를 대체하지 않으며, 실패로부터 복구·방어하는 계획에서 백업과 HA를 모두 핵심 요소로 고려해야 합니다.
Vault 영속 데이터 백업
백업과 복원은 이상적으로 Vault가 오프라인일 때 수행합니다. 오프라인 백업이 불가능하다면 원자적 스냅샷(atomic snapshot)을 지원하는 스토리지 백엔드(Consul 또는 통합 스토리지)를 사용하는 것을 권장합니다.
- 통합 스토리지 스냅샷:
vault operator raft snapshot save등으로 수행 - Consul 스냅샷: Consul 스냅샷 도구로 수행
여러 클러스터를 백업할 때는 Vault Enterprise 성능 복제(Performance Replication)를 사용한다면 각 클러스터의 active 노드 백업을 계획해야 합니다.
설정(Configuration) 백업
암호화 데이터 백업 외에도 서버 설정 파일, Vault 서비스를 관리하는 스크립트를 저장하고, 사용자가 설치한 플러그인을 재설치할 수 있는지 확인하는 것이 좋습니다.
참고: 스토리지 백엔드의 Vault 데이터 백업·스냅샷은 암호화되어 있지만, 일부 설정은 민감할 수 있습니다(예: Transit 자동 봉인 해제용 Vault 토큰, 설정의 TLS 개인 키). 이런 정보가 백업에 포함되면 백업 자체를 신중히 보호해야 합니다.