HashiCorp Vault 알아보기
CloudNet@ Gasida님이 진행하는 CI/CD + ArgoCD + Vault Study를 진행하며 학습한 내용을 공유합니다.
서비스가 많아질수록 DB Password, API Token, TLS 인증서, Cloud Access Key 같은 시크릿은 Git Repository, CI/CD 변수, Kubernetes Secret, 개발자 로컬 환경 등 여러 곳으로 흩어지기 쉽습니다. 이렇게 분산된 시크릿은 누가 접근했는지 추적하기 어렵고, 유출 이후 회전하거나 폐기하는 작업도 느려집니다. 이번 포스팅에서는 HashiCorp Vault가 어떤 문제를 해결하는지, 핵심 구성요소가 어떻게 연결되는지, 운영 환경에서는 어떤 기준으로 설계해야 하는지 정리해보겠습니다.
TL;DR
Vault는 시크릿을 단순히 저장하는 도구가 아니라, 인증(Authentication), 인가(Authorization), 동적 발급(Dynamic Secrets), 암호화(Transit), 감사(Audit)를 하나의 흐름으로 묶어 시크릿 생명주기를 관리하는 플랫폼입니다.
1. Vault 개요
1.1. 정보보안의 3요소 (CIA Triad)
Vault는 비밀 관리 도구이지만, 설계와 운영의 기준은 여전히 정보보안 3요소(CIA)에서 출발합니다.
1.1.1. 기밀성 (Confidentiality)
- 핵심: 권한이 검증된 엔티티만 비밀과 키에 접근하도록 제어합니다.
- 대표 위협: 토큰 공유와 장기 토큰 방치, 백업 스냅샷 노출, 로그나 CI 산출물에 평문 비밀 노출.
- Vault 적용 포인트:
ACL Policy와 mount path를 기준으로 최소 권한을 강제하고, Enterprise/HCP 환경에서는 Namespace까지 함께 고려해 격리합니다.AppRole,Kubernetes Auth등 워크로드 인증 방식을 사용해 사람/머신 자격증명을 분리합니다.Transit Secrets Engine으로 애플리케이션 데이터를 암호화하고 서명하며, 응답 래핑(Response Wrapping)으로 비밀 전달 시 평문 노출을 줄입니다.- DB와 클라우드 동적 자격증명을 사용해 자동 폐기(lease + revoke)되도록 구성하면 유출 시 피해 범위를 최소화할 수 있습니다.
- 운영 체크: 감사 로그(audit device)를 활성화해 누가 언제 무엇을 읽었는지 추적합니다.
1.1.2. 무결성 (Integrity)
- 핵심: 저장하거나 교환된 데이터가 승인된 절차 없이 바뀌지 않았음을 증빙합니다.
- 대표 위협: 중간자 공격으로 데이터 교체, 실수로 인한 덮어쓰기, 비정상 저장소 수정.
- Vault 적용 포인트:
Transit서명/검증(sign/verify)으로 아티팩트나 메시지를 배포 전후에 검증합니다.KV v2버전 관리와check-and-set(CAS)기능으로 최신 버전 위에만 덮어쓰도록 강제해 의도치 않은 롤백을 막습니다.- 감사 로그를 통해 모든 API 호출을 남겨 변경 이벤트를 사후 추적 가능하게 합니다.
- 운영 체크: 빌드와 배포 파이프라인에 서명 검증 단계를 넣어 변조 탐지를 자동화합니다.
1.1.3. 가용성 (Availability)
- 핵심: 필요한 시점에 Vault가 응답하고, 장애 시에도 빠르게 복구됩니다.
- 대표 위협: 단일 노드 장애, 스토리지 손상, 수동 unseal 지연, 과도한 트래픽으로 인한 리소스 고갈.
- Vault 적용 포인트:
Integrated Storage (Raft)기반 HA로 리더 장애 시 자동 선출되도록 하고, 데이터는 복제본에 분산 저장합니다.- 클라우드 KMS와 연계한
Auto Unseal로 재기동 시 복구 시간을 단축합니다. /v1/sys/health헬스 체크를 L4/L7 앞단에 연결해 비정상 노드를 트래픽에서 격리합니다.- 정기
operator raft snapshot save백업과 복구 리허설로 DR 복원 시간을 점검합니다.
- 운영 체크: SLA에 맞춰 리더 선출 시간, 백업 주기, 읽기/쓰기 TPS 한도를 모니터링하고 경보 임계치를 설정합니다.
1.2. 액세스 제어의 3단계 (AAA)
Vault 접근 제어는 인증 -> 인가 -> 감사의 흐름을 따라야 실운영에서 누수 없이 동작합니다.
1.2.1. 인증 (Authentication) - “Who are you?”
- 핵심: 사용자가 누구인지, 어떤 워크로드인지 신원을 증명하는 단계입니다.
- 대표 위협: 공유된 루트 토큰, 무제한 TTL 토큰, CI 로그에 token 또는 wrapped token 노출.
- Vault 적용 포인트:
- 사람 사용자는 OIDC/SAML(예: GitHub, Google Workspace)으로 연동하고, 머신 워크로드는
Kubernetes Auth,AppRole등으로 분리합니다. - 토큰 TTL과 Max TTL을 짧게 두고, 필요한 경우에만 갱신(renew)하도록 파이프라인에 자동화를 넣습니다.
- 응답 래핑(Response Wrapping)으로 1회용 단기 토큰을 전달해 중간 유출 위험을 줄입니다.
- 사람 사용자는 OIDC/SAML(예: GitHub, Google Workspace)으로 연동하고, 머신 워크로드는
- 운영 체크: 불필요한 Auth Method 비활성화, 실패 시도/갱신 실패 알림, 장기 미사용 엔터티 정리.
1.2.2. 인가 (Authorization) - “What can you do?”
- 핵심: 인증된 주체가 수행할 수 있는 경로와 동작을 최소 권한으로 한정합니다.
- 대표 위협: 와일드카드 정책(
path "*") 남용, 운영/개발 권한 혼재, 동일 토큰의 다중 사용자 공유. - Vault 적용 포인트:
Policy로 경로 단위 권한을 분리하고, 환경과 팀별 mount path를 명확히 나눕니다.- 동적 자격증명(DB, 클라우드) 사용 시
lease와revoke를 통해 수명 종료를 강제합니다. - 감사 로그 필터링을 고려해 정책 이름과 토큰 메타데이터에 주체 식별자를 명확히 남깁니다.
- 운영 체크: 정책 변경은 코드 리뷰/PR로 관리하고, 광범위 권한 정책을 정기 점검해 제거합니다.
1.2.3. 감사/계정관리 (Accounting/Auditing) - “What did you do?”
- 핵심: 누가 언제 어떤 시크릿에 접근했는지 불변 로그를 남겨 사후 추적을 보장합니다.
- 대표 위협: 감사 장치 미구성, 단일 로그 저장소 장애, 감사 로그 접근권한 미분리.
- Vault 적용 포인트:
Audit Device를 파일+원격(SIEM/로그 수집기) 복수로 활성화해 단일 장애 지점을 없앱니다.- Vault 감사 로그는 민감 필드를 HMAC 처리하므로 원문 대신 접근 시도 여부만 남는 점을 이해하고, 추가 메타데이터(엔터티, 정책 이름)를 활용합니다.
- 로그 회전/보존 주기를 운영 환경에 맞게 설정하고, 보안팀/운영팀 권한을 분리합니다.
- 운영 체크: 감사 장치 활성화 상태 모니터링, 로그 수집 지연/실패 알림, 정기 샘플링으로 감사 이벤트가 SIEM에 적재되는지 확인합니다.
1.2.4. Vault가 액세스를 제어하는 4가지 핵심 요소
Vault가 권한을 부여할 때는 누가 요청하는지, 어떤 대상에 접근하는지, 권한이 얼마나 유지되는지, 수명주기를 어떻게 자동화할지 한 번에 설계해야 합니다.
- 1. 누가 (Who) : 인증 (Authentication)
- 대상: 사람(개발자, 관리자)뿐 아니라 애플리케이션, 시스템, 머신을 모두 포함합니다.
- 방식: ID/PW, GitHub 토큰, Kubernetes Service Account, AWS IAM 등으로 신원을 검증합니다.
- Vault 역할: 검증된 주체에게 토큰을 발급해 Vault를 사용할 수 있도록 합니다.
- 2. 무엇에 (What) : 대상 지정 (Target System)
- 대상 리소스: Database, Web Server, Object Storage(S3), Cloud Console 등 민감 자산 전반입니다.
- 기존 문제: 시스템마다 ID/PW가 파편화되어 관리가 어려웠습니다.
- Vault 역할: Secret Engine을 통해 다양한 시스템에 접근하는 단일 게이트웨이로 동작합니다.
- 3. 얼마 동안 (How Long) : 접근 시간 제어 (TTL)
- 핵심 개념: TTL(Time To Live, 유효 기간)을 통해 권한을 제한합니다.
- 동작: 예를 들어 DB 접속 권한을 1시간으로 제한하고, 시간이 지나면 자동 만료시킵니다.
- Vault 역할: 영구 키 대신 만료되는 임시 자격 증명(Lease)을 발급합니다.
- 4. 라이프 사이클 (Lifecycle) : 자동화 (Automation)
- 접근 키 관리: 생성(Create)부터 갱신(Renew), 폐기(Revoke)까지 자동화합니다.
- 동적 시크릿: 사용자가 요청할 때 계정을 즉시 생성하고 사용 종료 시 즉시 삭제하는 Just in Time(JIT) 방식입니다.
- Vault 역할: 관리자의 개입 없이 키의 생성과 갱신, 폐기를 자동으로 처리해 운영 부담과 보안 위험을 줄입니다.
1.3. 시크릿이란? 대표적인 시크릿 종류
Vault가 관리하는 시크릿은 비밀번호뿐 아니라 서비스 운영에 필요한 모든 민감 자산입니다. 유출 시 피해 규모가 다르므로, 종류별로 발급, 보관, 폐기 정책을 따로 가져가야 합니다.
1.3.1. A. 사용자 및 시스템 접근 자격 증명
| 종류 | 설명/특징 | 노출 시 위험 및 대응 |
|---|---|---|
| 비밀번호(Password) | 계정과 서버 접근에 사용, 평문 보관과 재사용이 잦음 | 계정 도용 -> 회전 주기와 복잡도 정책 적용, KV에 저장 시 ACL로 최소 권한 부여 |
| SSH 키 | VM과 베어메탈 접속용 개인키 | 서버 장악 -> 패스프레이즈와 짧은 TTL, 접속 로그 연동 |
| Database Credentials | DB 접속용 계정/비밀번호 | 전체 데이터 유출 -> Database Secrets Engine으로 동적 발급과 자동 회수(revoke) |
1.3.2. B. 서비스 연동 및 자동화 키
| 종류 | 설명/특징 | 노출 시 위험 및 대응 |
|---|---|---|
| Cloud Credentials (AWS Access Key, GCP SA Key 등) | 리소스 생성과 삭제까지 가능한 강한 권한 | 자원 장악과 과금 폭증 -> STS 등 단기 크리덴셜만 사용, Vault로 주기 회전 |
| API Key / Token (GitHub, Slack, OpenAI 등) | 외부 서비스 연동과 자동화에 사용 | 평문 노출 후 오남용 -> 응답 래핑으로 전달, 누출 시 즉시 폐기 자동화 |
1.3.3. C. 보안 통신 및 암호화 자산
| 종류 | 설명/특징 | 노출 시 위험 및 대응 |
|---|---|---|
| 인증서(PKI/TLS) | 서비스 신뢰와 트래픽 암호화 | MITM과 위장 -> PKI 엔진으로 짧은 TTL 발급과 자동 갱신, 발급 로그 감사 |
| 암호화 키 | 데이터 암호화 루트 자산 | 암호화 무력화 -> Transit 엔진으로 키 비공개, 앱은 암호화와 복호화 API만 호출 |
1.4. Vault를 활용한 시크릿 중앙 관리가 필요한 이유
1.4.1. 아키텍처 진화와 Secret Sprawl
- 메인프레임과 모놀리식 환경에서는 관리 대상 시크릿이 적고 변경 주기가 길어 수작업 관리로도 충분했습니다.
- 3-Tier를 거쳐 클라우드와 MSA로 확장되면서 서비스, 컨테이너, API 연동마다 고유한 자격증명이 생겨 관리 수량이 폭증했습니다.
- 시크릿이 Git, 설정 파일, 환경 변수, 개발자 PC 등으로 흩어지는 Secret Sprawl이 발생해 누락과 유출 위험이 커졌습니다.
1.4.2. Zero Trust 관점에서 본 시크릿 요구사항
- 경계 기반 신뢰 대신 신원 기반 검증이 필요합니다. 사람과 머신 모두 요청마다 인증하고, 최소 권한을 짧은 시간에만 부여해야 합니다.
- 모든 접근 이벤트는 감사 가능해야 하며, 누가 언제 무엇을 읽거나 썼는지 추적할 수 있어야 합니다.
- 정적 자격증명은 유출 시 피해가 크므로 자동 회전과 단기 수명 기반 발급이 기본이 되어야 합니다.
1.4.3. Vault가 제공하는 해법
- 중앙 저장소: KV, PKI, Transit 등으로 시크릿을 암호화해 한 곳에서 관리하고, 코드나 설정 파일에 하드코딩하지 않아도 됩니다.
- 동적 시크릿: DB나 클라우드 자격증명을 요청 시점에 발급하고 만료 시 자동 폐기해 노출 시 피해 범위를 줄입니다.
- 신원 기반 접근 제어: LDAP, OIDC, Kubernetes, AWS IAM 등과 연동해 사람과 워크로드 신원을 검증하고, 정책으로 최소 권한을 부여합니다.
- 감사와 가시성: Audit Device로 모든 접근을 기록해 규제 대응과 사고 분석에 필요한 추적성을 확보합니다.
1.4.4. 운영 측면의 이점
- 중앙화와 자동 회전 덕분에 시크릿 누락과 과권한 문제를 줄이고, 감사 로그로 보안 통제 증적을 쉽게 남길 수 있습니다.
- 재해복구와 변경 관리 관점에서도 일관된 프로세스를 적용할 수 있어 대규모 환경에서도 운영 복잡도를 낮춥니다.
1.5. Vault란? Docs
HashiCorp Vault는 신원 기반으로 시크릿과 암호화 키를 관리하는 플랫폼입니다. 인증과 인가를 거친 주체만 시크릿을 읽거나 만들 수 있으며, 모든 행위는 감사 로그에 남습니다.
1.5.1. Vault가 제공하는 핵심 기능
- 중앙 시크릿 저장소: KV, PKI, Transit 등으로 비밀번호, 인증서, 키를 암호화해 보관합니다.
- 신원 기반 인증: LDAP, OIDC, Kubernetes, AWS IAM 등 다양한 Auth Method로 사람과 워크로드의 신원을 검증합니다.
- 정책 기반 인가: 경로별 정책(ACL)으로 최소 권한을 정의하고 토큰에 부여합니다.
- 동적 시크릿: DB나 클라우드 자격증명을 요청 시 생성하고 만료 시 자동 폐기합니다.
- 암호화 서비스: Transit 엔진으로 키를 노출하지 않고 서명과 암복호를 제공합니다.
- 감사: Audit Device에 모든 요청을 기록해 규제 대응과 사고 분석을 지원합니다.
1.5.2. 동작 흐름 요약
- 인증: 클라이언트가 Auth Method로 로그인해 토큰을 발급받습니다.
- 검증: Vault가 외부 신뢰 소스(예: OIDC, IAM)와 연동해 신원을 확인합니다.
- 인가: 토큰에 연결된 정책으로 경로별 허용 작업을 결정합니다.
- 접근: 허용된 API로 시크릿을 조회하거나 발급하고, 암호화 연산을 수행합니다.
1.5.3. Vault가 해결하는 대표 과제
- 시크릿 분산과 하드코딩: 모든 시크릿을 Vault로 집중시켜 코드와 설정 파일에서 제거합니다.
- 장기 자격증명 노출: 짧은 TTL과 자동 회전, 동적 시크릿으로 유출 피해를 최소화합니다.
- 감사 추적 부재: 접근 주체와 시점, 경로를 로그로 남겨 추적성을 확보합니다.
2. Vault 주요 구성요소
Vault를 이해할 때는 Auth Method, Token, Policy, Secret Engine, Lease, Audit Device, Storage, Seal을 분리해서 보는 것이 좋습니다. 각각의 역할이 명확해야 운영 중 권한 문제나 장애 원인을 빠르게 좁힐 수 있습니다.
| 구성요소 | 역할 | 설계 포인트 |
|---|---|---|
| Auth Method | 사람/머신/워크로드의 신원을 검증 | 사용자용 OIDC/LDAP와 워크로드용 Kubernetes/AppRole/AWS IAM을 분리 |
| Token | 인증 이후 Vault API를 호출하기 위한 세션 자격 | 짧은 TTL, 주기적 갱신, root token 미사용 |
| Policy | 어떤 path에 어떤 capability를 허용할지 정의 | 최소 권한, 환경/팀/앱 단위 분리, path "*" 지양 |
| Secret Engine | 시크릿 저장, 동적 자격증명 발급, 암호화 기능 제공 | KV, Database, PKI, Transit 등 목적별 mount path 분리 |
| Lease | 동적 시크릿과 일부 토큰의 유효기간 관리 | TTL, renew, revoke 흐름을 애플리케이션과 운영 절차에 반영 |
| Audit Device | 요청/응답 이벤트를 감사 로그로 기록 | 운영 환경에서는 최소 1개 이상 활성화하고 로그 수집/보존 정책과 연동 |
| Storage | Vault의 암호화된 데이터를 영속 저장 | 운영 환경에서는 HA와 백업/복구가 가능한 스토리지 선택 |
| Seal | 저장소의 암호화 키를 보호하고 서버 기동 시 잠금 | 수동 unseal과 Auto Unseal의 운영 부담, 복구 절차, 키 관리 책임을 함께 검토 |
2.1. Auth Method와 Token
Vault는 요청자가 누구인지 먼저 확인합니다. 사람 사용자는 OIDC, LDAP, GitHub 같은 방식으로 인증할 수 있고, 애플리케이션은 Kubernetes Service Account, AWS IAM, AppRole 같은 방식으로 인증할 수 있습니다. 인증이 성공하면 Vault는 정책이 연결된 token을 발급하고, 이후 요청은 이 token의 권한 범위 안에서만 처리됩니다.
운영 환경에서는 인증 방식을 사용자와 워크로드 기준으로 분리해야 합니다. 예를 들어 운영자가 CLI로 접근하는 흐름과 Pod가 시크릿을 읽는 흐름을 같은 token으로 처리하면 감사 추적과 권한 회수가 어려워집니다. 또한 초기 root token은 모든 권한을 가지므로 초기 설정 이후에는 보관 절차를 분리하고 일반 운영에 사용하지 않는 것이 안전합니다.
2.2. Policy와 Path 기반 권한
Vault의 권한은 path 중심으로 동작합니다. Secret Engine을 secret/, database/, pki/, transit/ 같은 path에 mount하고, policy에서 해당 path에 대한 read, create, update, delete, list 등의 capability를 정의합니다.
1
2
3
4
5
6
7
path "secret/data/app/prod/*" {
capabilities = ["read"]
}
path "database/creds/app-readonly" {
capabilities = ["read"]
}
위 예시는 애플리케이션이 secret/data/app/prod/* 아래의 KV secret을 읽고, database/creds/app-readonly에서 동적 DB 계정을 발급받을 수 있도록 허용합니다. 반대로 policy에 없는 path는 기본적으로 거부됩니다. 이 특성 때문에 Vault 권한 설계는 “허용할 대상만 명시한다”는 기준으로 접근해야 합니다.
2.3. Secret Engine
Secret Engine은 Vault가 실제로 시크릿을 다루는 기능 단위입니다. 단순 저장소 역할을 하는 엔진도 있고, 외부 시스템과 연동해 임시 자격증명을 생성하는 엔진도 있습니다.
| Secret Engine | 용도 | 사용 예시 |
|---|---|---|
| KV | 정적 시크릿 저장 | API Key, App Config, 외부 서비스 Token |
| Database | DB 계정 동적 발급 | PostgreSQL/MySQL 계정을 요청 시점에 생성하고 TTL 후 폐기 |
| PKI | 인증서 발급과 수명 관리 | 내부 서비스 mTLS 인증서 발급, 짧은 TTL 인증서 자동 갱신 |
| Transit | 암호화/복호화/서명 API 제공 | 애플리케이션이 암호화 키를 직접 보관하지 않고 API로 암호화 |
| AWS | AWS IAM 자격증명 또는 STS 발급 | 임시 Access Key 발급, 작업 완료 후 revoke |
| Cubbyhole | token 단위 private storage 제공 | response wrapping, 1회성 시크릿 전달 |
정적 시크릿은 운영자가 값을 저장하고 애플리케이션이 읽는 방식입니다. 반면 동적 시크릿은 요청 시점에 Vault가 외부 시스템에 실제 계정이나 자격증명을 생성하고, lease가 만료되거나 revoke되면 해당 자격증명을 폐기합니다. 장기 자격증명을 줄이는 것이 목적이라면 가능하면 동적 시크릿을 우선 검토하는 것이 좋습니다.
2.4. Lease, Renew, Revoke
Vault의 강점은 시크릿을 발급한 뒤 수명주기를 추적한다는 점입니다. 동적 시크릿은 lease를 가지며, lease에는 TTL과 갱신 가능 여부가 포함됩니다. 애플리케이션은 TTL 안에 시크릿을 사용하고, 장기 실행 작업이라면 renew를 수행하거나 새 시크릿을 다시 발급받아야 합니다.
1
2
3
vault read database/creds/app-readonly
vault lease renew database/creds/app-readonly/<lease_id>
vault lease revoke database/creds/app-readonly/<lease_id>
이 흐름은 “유출된 자격증명이 얼마나 오래 유효한가?”라는 질문에 직접적인 답을 줍니다. 정적 password가 몇 달 동안 유효한 구조보다, 30분짜리 동적 계정이 자동 폐기되는 구조가 사고 반경을 훨씬 작게 만듭니다.
2.5. Seal, Unseal, Storage
Vault 서버는 시작 시 sealed 상태로 기동합니다. sealed 상태에서는 물리 저장소에 접근할 수 있더라도 데이터를 복호화할 수 없고, status 확인과 unseal 같은 제한된 작업만 가능합니다. 기본 구성에서는 Shamir’s Secret Sharing으로 unseal key를 여러 조각으로 나누고, 지정된 threshold만큼 key share를 입력해야 unseal됩니다.
운영 환경에서는 수동 unseal 절차가 장애 복구 시간을 늘릴 수 있습니다. 그래서 AWS KMS, GCP Cloud KMS, Azure Key Vault, HSM 같은 외부 KMS와 연계한 Auto Unseal을 검토합니다. 다만 Auto Unseal을 사용하면 KMS 접근 권한, KMS 장애, recovery key 보관 절차까지 함께 설계해야 합니다.
Storage는 Vault 데이터의 영속 계층입니다. file storage는 학습이나 단일 노드 테스트에는 단순하지만 HA를 제공하지 않습니다. 운영 환경에서는 Integrated Storage (Raft)처럼 HA, 백업/복구, 노드 간 복제를 고려할 수 있는 구성을 우선 검토해야 합니다.
3. 대표 사용 패턴
3.1. 정적 시크릿 중앙화
가장 먼저 적용하기 쉬운 방식은 Git, CI 변수, Kubernetes Secret 등에 흩어진 정적 시크릿을 Vault KV로 모으는 것입니다. 이 단계의 목표는 시크릿 저장 위치를 줄이고, 누가 어떤 값을 읽었는지 감사 로그로 추적할 수 있게 만드는 것입니다.
1
2
3
vault secrets enable -path=secret kv-v2
vault kv put secret/app/prod db_username="app" db_password="change-me"
vault kv get secret/app/prod
정적 시크릿 중앙화만으로도 하드코딩과 복사본 문제를 줄일 수 있지만, password 자체가 오래 살아있다는 문제는 남습니다. 따라서 DB, Cloud, PKI처럼 Vault가 동적으로 발급할 수 있는 대상은 다음 단계에서 동적 시크릿으로 전환하는 것이 좋습니다.
3.2. 동적 DB 계정 발급
Database Secrets Engine을 사용하면 애플리케이션이 DB 접속 계정을 직접 들고 있지 않아도 됩니다. 애플리케이션은 Vault에 인증한 뒤 database/creds/<role>을 읽고, Vault는 DB에 임시 계정을 생성해 반환합니다. TTL이 지나거나 lease가 revoke되면 Vault가 해당 계정을 정리합니다.
이 방식의 장점은 유출 대응이 명확하다는 점입니다. 특정 lease를 revoke하면 해당 DB 계정만 폐기할 수 있고, 감사 로그에서 어떤 entity가 언제 발급받았는지도 추적할 수 있습니다.
3.3. Transit을 이용한 Encryption as a Service
Transit Secrets Engine은 애플리케이션이 암호화 키를 직접 보관하지 않도록 도와줍니다. 애플리케이션은 평문을 Vault에 보내 암호문을 받고, 복호화가 필요할 때도 Vault API를 호출합니다. 키는 Vault 안에 남고 애플리케이션은 키를 직접 다루지 않습니다.
1
2
3
vault secrets enable transit
vault write -f transit/keys/payment
vault write transit/encrypt/payment plaintext="$(printf 'card-data' | base64)"
이 패턴은 애플리케이션 DB에 민감 데이터를 저장해야 하지만 키 관리 체계를 애플리케이션 코드와 분리하고 싶을 때 유용합니다. 또한 서명/검증 기능을 이용하면 배포 아티팩트나 메시지 무결성 검증에도 활용할 수 있습니다.
3.4. Kubernetes 워크로드와 연동
Kubernetes 환경에서는 Pod가 Service Account Token으로 Vault에 인증하고 필요한 시크릿을 읽는 패턴이 일반적입니다. Vault Agent Injector나 Vault Secrets Operator(VSO)를 사용하면 애플리케이션 코드 변경을 줄이면서 Pod에 파일 또는 Kubernetes Secret 형태로 값을 전달할 수 있습니다.
이때 중요한 점은 Kubernetes Secret을 최종 저장소로만 볼 것인지, Vault를 source of truth로 둘 것인지입니다. Vault를 source of truth로 두면 시크릿 회전, audit, revoke 흐름은 Vault 중심으로 관리하고, Kubernetes에는 필요한 범위의 값만 동기화하는 구조가 됩니다.
Kubernetes 환경에서 Vault를 설치하고 Vault Secrets Operator를 사용하는 실습은 HashiCorp Vault/VSO in Kubernetes에서 이어서 다룹니다.
4. 운영 설계 체크리스트
Vault는 보안 도구이기 때문에 설치보다 운영 설계가 더 중요합니다. 아래 항목은 운영 환경에 적용하기 전 최소한 확인해야 할 기준입니다.
4.1. 인증/인가
- 사용자 접근과 애플리케이션 접근을 서로 다른 Auth Method와 Policy로 분리합니다.
- 운영자는 OIDC/LDAP 같은 중앙 Identity Provider와 연동하고, 개인별 감사 추적이 가능하도록 합니다.
- 워크로드는 Kubernetes Auth, AWS IAM, AppRole 등 환경에 맞는 machine identity를 사용합니다.
root token은 초기 설정 이후 일반 작업에 사용하지 않고, 보관/사용 절차를 별도로 둡니다.- policy는 path 단위 최소 권한으로 작성하고, wildcard 권한은 정기적으로 점검합니다.
4.2. 시크릿 수명주기
- 정적 시크릿은 owner, rotation 주기, 사용처를 명확히 기록합니다.
- DB, Cloud, PKI처럼 가능한 대상은 동적 시크릿으로 전환합니다.
- TTL은 애플리케이션 처리 시간보다 길고, 유출 허용 시간보다 짧게 잡습니다.
- renew 실패, revoke 실패, secret rotation 실패를 모니터링 대상에 포함합니다.
- 시크릿을 CI 로그, 애플리케이션 로그, crash dump에 남기지 않도록 마스킹 정책을 적용합니다.
4.3. 가용성과 복구
- 운영 환경에서는 단일 노드
filestorage보다 HA 가능한 storage 구성을 검토합니다. Integrated Storage (Raft)사용 시 quorum, leader election, snapshot 백업/복구 절차를 점검합니다.- 수동 unseal을 사용할 경우 key share 보관자, threshold, 장애 대응 시간을 명확히 정합니다.
- Auto Unseal을 사용할 경우 KMS 권한, KMS 장애, recovery key 절차를 함께 테스트합니다.
/v1/sys/health기반 health check와 alert를 구성해 sealed, standby, active 상태를 구분합니다.
4.4. 감사와 모니터링
- Audit Device를 활성화하고 로그 수집 파이프라인까지 end-to-end로 검증합니다.
- authentication failure, permission denied, lease revoke failure, seal/unseal event를 alert 후보로 둡니다.
- 감사 로그 접근 권한은 Vault 운영 권한과 분리합니다.
- token accessor, entity, policy, path 정보를 기준으로 누가 어떤 secret에 접근했는지 추적할 수 있어야 합니다.
- 백업 파일, snapshot, audit log도 민감 데이터로 보고 보관 위치와 접근 권한을 제한합니다.
4.5. 피해야 할 안티패턴
| 안티패턴 | 문제점 | 대안 |
|---|---|---|
| 애플리케이션에 장기 root token 주입 | 모든 path 접근 가능, 유출 시 피해 범위 큼 | App 전용 Auth Method + 최소 권한 Policy + 짧은 TTL |
| Vault에 저장 후 rotation 미구성 | 중앙화만 되고 수명주기 관리는 그대로 수동 | owner/TTL/rotation/revoke 절차를 함께 설계 |
| Kubernetes Secret만 source of truth | 회전/감사/revoke 흐름이 분산됨 | Vault를 source of truth로 두고 필요한 값만 동기화 |
| Audit Device 미활성화 | 사고 후 접근 경로 추적 불가 | 파일/원격 로그 수집 체계와 연동 |
| 운영 Vault를 단일 노드로 구성 | 노드 장애와 unseal 지연이 서비스 장애로 확산 | HA storage, snapshot, restore rehearsal, Auto Unseal 검토 |
5. 마무리
Vault는 “시크릿 저장소”로 시작할 수 있지만, 실제 가치는 시크릿의 전체 생명주기를 통제하는 데 있습니다. 인증된 주체에게만 필요한 권한을 짧게 부여하고, 사용 기록을 감사 로그로 남기며, 만료와 폐기를 자동화하면 Secret Sprawl과 장기 자격증명 문제를 크게 줄일 수 있습니다.
운영 환경에서 중요한 것은 기능을 많이 켜는 것이 아니라 신원, 권한, 수명, 감사, 복구 절차를 하나의 흐름으로 설계하는 것입니다. 다음 글인 HashiCorp Vault/VSO in Kubernetes에서는 Kubernetes 위에 Vault를 설치하고, Vault Secrets Operator를 통해 애플리케이션에 시크릿을 전달하는 실습을 다뤄보겠습니다.
6. Reference
- HashiCorp Vault Docs - Overview
- HashiCorp Vault Docs - How Vault works
- HashiCorp Vault Docs - Authentication
- HashiCorp Vault Docs - Tokens
- HashiCorp Vault Docs - Lease, Renew, and Revoke
- HashiCorp Vault Docs - Seal/Unseal
- HashiCorp Vault Docs - Integrated Storage
- HashiCorp Vault Docs - Transit Secrets Engine
- HashiCorp Vault Docs - High Availability
- HashiCorp Vault Docs - Auth Methods
- HashiCorp Vault Docs - Policies
- HashiCorp Vault Docs - Audit
- HashiCorp Vault Docs - Database Secrets Engine
- HashiCorp Vault Docs - PKI Secrets Engine
- HashiCorp Blog - What is secret sprawl and why is it harmful?
- HashiCorp Blog - Solutions to secret sprawl
- NIST SP 800-207 - Zero Trust Architecture
궁금하신 점이나 추가해야 할 부분은 댓글이나 아래의 링크를 통해 문의해주세요.
Written with KKamJi