1. 개요
HashiCorp Vault는 시작 시 Sealed(봉인된) 상태로 시작합니다. 이 상태에서는 물리적 스토리지에 접근할 수 있지만, 저장된 데이터를 복호화할 수 없습니다. Unsealing(봉인해제)은 Vault가 데이터를 복호화하기 위해 필요한 root key에 접근하는 과정입니다.
2. 암호화 계층 구조
Vault는 3단계 암호화 계층 구조를 사용하여 데이터를 보호합니다:
HashiCorp Vault는 시작 시 Sealed(봉인된) 상태로 시작합니다. 이 상태에서는 물리적 스토리지에 접근할 수 있지만, 저장된 데이터를 복호화할 수 없습니다. Unsealing(봉인해제)은 Vault가 데이터를 복호화하기 위해 필요한 root key에 접근하는 과정입니다.
Vault는 3단계 암호화 계층 구조를 사용하여 데이터를 보호합니다:
요즘같이 사내에 많은 Open Source, Enterprise Soulition이 사용되는 시기에 각 Solution별로 ID/Password를 관리하는 것은 쉽지 않습니다.
거기다 만약 Dev, Stage, Production등의 환경별로 구축이 되어 있다면 이미 ID/Password를 저장하고 관리하는 것만 으로도 굉장히 반복적이고 귀찮은 작업이 될 것 입니다.
우리는 이러한 상황을 해결하기 위해 IDP(Identity Provider) Solution을 사용합니다.
다양한 IDP가 있겠으나 제가 속한 회사에서는 Keycloak을 사용하고 있고 그 Keycloak을 통해
gitlab, grafana, nomad, vault의 사용자 인증 및 권한관리를 하고 있습니다.
이 중 Terraform code로 구현이 완벽히 된 Nomad와 Vault의 Code에 대해 설명드리겠습니다.

기본 설정시 1,209,600초(2주)의 유효 기간을 갖게 되며, 설정에 따라 긴 유효시간의 적용이 가능합니다. (옵션 : deault_tls_client_ttl)
설정은 상기 도식화한 절차 중 "2. kmip 기본 config" 단계에 적용 가능하며. 이는 KMIP 적용 흐름도의 "4. kmip scope, role 정의" 단계에서 override 할 수 있습니다.
https://learn.hashicorp.com/tutorials/vault/reference-architecture#network-connectivity
127.0.0.1:8200127.0.0.1:8201이 문서는 HashiCorp Vault의 각 컴포넌트와 Secret Engine의 역할 및 지원 환경(OS)을 정리합니다.
Vault Server는 중앙 집중식 비밀 관리 시스템으로, 비밀번호, API 키, 인증서 등 민감한 데이터를 안전하게 저장하고 접근을 제어합니다. 정책 기반의 접근 제어를 통해 비밀에 대한 접근을 관리하며, 다양한 인증 방법과 시크릿 엔진을 통해 다양한 환경과 통합됩니다.
| 지원 환경(OS) | CPU 아키텍처 | 비고 |
|---|---|---|
| Linux (Ubuntu, CentOS, RHEL, Debian, Amazon Linux 등) | 386, amd64, arm, arm64, s390x | 다양한 배포판에서 지원됩니다. |
| Windows (Windows Server 및 데스크톱 버전) | 386, amd64 | Windows 플랫폼에서도 설치 및 실행이 가능합니다. |
| macOS (Intel 및 Apple Silicon) | amd64, arm64 | 개발 및 테스트 목적으로 실행할 수 있습니다. |
| FreeBSD | 386, amd64, arm | - |
| NetBSD | 386, amd64, arm | - |
| OpenBSD | 386, amd64, arm | - |
| Solaris | amd64 | - |
Vault Audit은 -path를 달리하여 여러 Audit 메커니즘을 중복해서 구성 가능
$ vault audit enable file file_path=/var/log/vault/vault_audit.log
$ vault audit enable -path=file2 file file_path=/var/log/vault/vault_audit2.log
볼트 개발 모드 서버를 시작하는 기초적인 커맨드와 실행 후 안내 메시지는 다음과 같다.
$ vault server -dev
==> Vault server configuration:
Api Address: http://127.0.0.1:8200
Cgo: disabled
Cluster Address: https://127.0.0.1:8201
Environment Variables: HOME, ITERM_PROFILE, ...
Go Version: go1.19.4
Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
Log Level: info
Mlock: supported: false, enabled: false
Recovery Mode: false
Storage: inmem
Version: Vault v1.12.3, built 2023-02-02T09:07:27Z
Version Sha: 209b3dd99fe8ca320340d08c70cff5f620261f9b
==> Vault server started! Log data will stream in below:
...
볼트 서버를 시작하는 기초적인 커맨드와 실행 후 안내 메시지는 다음과 같다.
$ vault server -dev
==> Vault server configuration:
Api Address: http://127.0.0.1:8200
Cgo: disabled
Cluster Address: https://127.0.0.1:8201
Environment Variables: HOME, ITERM_PROFILE, ...
Go Version: go1.19.4
Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
Log Level: info
Mlock: supported: false, enabled: false
Recovery Mode: false
Storage: inmem
Version: Vault v1.12.3, built 2023-02-02T09:07:27Z
Version Sha: 209b3dd99fe8ca320340d08c70cff5f620261f9b
==> Vault server started! Log data will stream in below:
...
https://learn.hashicorp.com/tutorials/vault/reference-architecture#deployment-system-requirements
Vault의 Backend-Storage 사용 여부에 따라 구성에 차이가 발생
