HashiCorp Vault 알아보기 (작성 중)

Posted Nov 30, 2025

By KKamJi

views 22 min read

CloudNet@ Gasida님이 진행하는 CI/CD + ArgoCD + Vault Study를 진행하며 학습한 내용을 공유합니다.

이번 포스팅에서는 HashiCorp Vault에 대해 알아보겠습니다.

1. Vault 개요

1.1. 정보보안의 3요소 (CIA Triad)

Vault는 비밀 관리 도구이지만, 설계와 운영의 기준은 여전히 정보보안 3요소(CIA)에서 출발합니다.

1.1.1. 기밀성 (Confidentiality)

핵심: 권한이 검증된 엔티티만 비밀과 키에 접근하도록 제어합니다.
대표 위협: 토큰 공유와 장기 토큰 방치, 백업 스냅샷 노출, 로그나 CI 산출물에 평문 비밀 노출.
Vault 적용 포인트:
- ACL Policy와 Namespace로 최소 권한을 강제하고, 토큰 TTL/수명 연장 정책으로 세션을 짧게 유지합니다.
- 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회용 단기 토큰을 전달해 중간 유출 위험을 줄입니다.
운영 체크: 불필요한 Auth Method 비활성화, 실패 시도/갱신 실패 알림, 장기 미사용 엔터티 정리.

1.2.2. 인가 (Authorization) - “What can you do?”

핵심: 인증된 주체가 수행할 수 있는 경로와 동작을 최소 권한으로 한정합니다.
대표 위협: 와일드카드 정책(path "*") 남용, 운영/개발 권한 혼재, 동일 토큰의 다중 사용자 공유.
Vault 적용 포인트:
- Policy로 경로 단위 권한을 분리하고, 환경과 팀별 네임스페이스로 격리합니다.
- 동적 자격증명(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. 실습 환경 구성 - Kind Cluster 배포

  
##############################################################
# kind k8s 배포
##############################################################
kind create cluster --name myk8s --image kindest/node:v1.32.8 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30000 # Vault UI
    hostPort: 30000
  - containerPort: 30001 # Jenkins UI
    hostPort: 30001
  - containerPort: 30002 # DB 배포(PostgreSQL 또는 MySQL)
    hostPort: 30002
  - containerPort: 30003 # Sample App
    hostPort: 30003
EOF

3. Reference

궁금하신 점이나 추가해야 할 부분은 댓글이나 아래의 링크를 통해 문의해주세요.
Written with KKamJi

DevOps

This post is licensed under CC BY 4.0 by the author.