26J02b
Vault는 단순히 “Git에 Secret을 안 넣기 위한 저장소”라기보다, 운영 관점에서는 자격증명 발급기관 + 내부 CA + KMS/암호화 서비스 + 감사/통제 지점으로 많이 씁니다. 특히 Kubernetes/GitOps 환경에서는 “정적 Secret 보관”보다 짧은 수명의 동적 Secret 발급 쪽이 더 큰 가치가 있습니다.
1. 가장 많이 쓰는 용도: 동적 자격증명 발급
Vault의 대표적인 강점은 DB, LDAP, Cloud, Kubernetes 같은 외부 시스템에 대해 임시 계정/토큰을 발급하고 TTL이 지나면 자동 만료·회수하는 것입니다.
예를 들어 PostgreSQL, MySQL 같은 DB 접근 계정을 애플리케이션마다 미리 만들어두지 않고, Pod가 뜰 때 Vault에 요청해서 30분~몇 시간짜리 DB 계정을 발급받게 할 수 있습니다. Vault Database Secrets Engine은 설정된 role을 기준으로 DB credential을 동적으로 생성하고, lease가 만료되면 Vault의 revocation 체계로 해당 credential을 무효화할 수 있습니다. 또한 서비스 인스턴스별로 고유 DB 사용자를 쓰게 되므로 감사 추적도 쉬워집니다. (HashiCorp Developer)
귀하 환경에 대입하면 이런 식입니다.
| 대상 | Vault 활용 방식 |
|---|---|
| Airflow metadata DB | Airflow worker/scheduler가 장기 DB 패스워드 대신 Vault에서 임시 DB credential 발급 |
| Hive Metastore DB | metastore 서버가 Vault에서 DB credential 발급 |
| JupyterHub 사용자 세션 | 사용자 Pod 시작 시 제한된 TTL의 DB/API credential 발급 |
| 운영 자동화 Job | Jenkins/ArgoCD hook/Batch job이 작업 시간 동안만 credential 사용 |
| 장애 대응용 계정 | break-glass 계정을 상시 보관하지 않고 필요한 시점에 TTL 짧게 발급 |
핵심은 “Secret을 안전하게 저장한다”가 아니라 “장기 Secret 자체를 줄인다”입니다.
2. 내부 PKI/인증서 발급 기관
Vault는 내부 CA 역할로도 많이 씁니다. PKI Secrets Engine은 동적 X.509 인증서를 발급할 수 있고, 서비스가 수동으로 private key/CSR을 만들고 CA 승인을 기다리는 과정을 줄여줍니다. TTL을 짧게 잡으면 애플리케이션 인스턴스마다 고유 인증서를 발급하고, 종료 시 폐기하는 ephemeral certificate 구조도 가능합니다. (HashiCorp Developer)
Kubernetes 환경에서는 다음 용도로 유용합니다.
| 용도 | 설명 |
|---|---|
| 내부 mTLS 인증서 | 서비스 간 mTLS 인증서 발급 |
| Ingress/Gateway 내부 인증서 | 내부 도메인용 TLS 인증서 발급 |
| Webhook 인증서 | admission webhook, operator webhook 인증서 발급 |
| Air-gap 내부 CA | 외부 CA/Let’s Encrypt 없이 내부 서비스 인증서 자동화 |
| 짧은 TTL 인증서 | 인증서 유출 시 영향 범위 축소 |
이미 cert-manager를 쓰고 있다면 Vault를 cert-manager의 issuer 또는 backend CA로 두는 구조가 가능합니다. 이 경우 Git에는 Certificate, Issuer 같은 선언만 두고, 실제 private key와 인증서는 Vault/cert-manager가 런타임에 생성합니다.
3. Encryption as a Service / Transit Engine
Vault Transit Engine은 데이터를 Vault에 저장하는 것이 아니라, 애플리케이션이 보내는 데이터를 암호화·복호화·서명·검증·HMAC 처리해주는 암호화 API입니다. 공식 문서에서도 Transit Engine을 “cryptography as a service” 또는 “encryption as a service”로 설명하고, Vault가 실제 데이터를 저장하지 않는다고 명시합니다. (HashiCorp Developer)
이건 다음 상황에서 좋습니다.
| 용도 | 예시 |
|---|---|
| 애플리케이션 레벨 암호화 | 개인정보, 토큰, API key를 DB에 저장하기 전 암호화 |
| 중앙 키 관리 | 앱 개발자가 직접 AES key를 관리하지 않게 함 |
| HMAC/서명 | 요청 위변조 검증, 내부 토큰 서명 |
| 키 회전 | 암호화 키 버전을 Vault에서 중앙 관리 |
| KMS 대체/보조 | 내부망에서 cloud KMS 대신 사용 |
예를 들어 사용자 개인정보를 PostgreSQL/OpenSearch에 저장해야 하는데 DB 자체 암호화만으로 부족하다면, 애플리케이션이 Vault Transit으로 암호화한 뒤 DB에는 ciphertext만 저장하는 방식이 가능합니다.
4. AIStor/MinIO 계열에서는 KMS/HSM 연계 용도
귀하 환경에서는 이 부분도 중요합니다. AIStor에서 SSE-KMS를 쓰려면 KES 또는 MinIO KMS 같은 외부 키관리 체계가 필요하고, HashiCorp Vault가 그 외부 KMS 또는 HSM 보관 위치로 쓰일 수 있습니다.
MinIO AIStor 문서는 KES 기반 Server-Side Encryption 구성 시 외부 KMS 후보 중 하나로 HashiCorp Vault를 제시합니다. 또한 SSE를 활성화하면 AIStor backend data가 기본 암호화 키로 암호화되고, AIStor가 정상 기동하려면 KES와 외부 KMS 접근이 유지되어야 하며, 한 번 활성화한 backend encryption은 disable/reset할 수 없다고 설명합니다. (MinIO AIStor Documentation)
또 다른 형태로, MinIO KMS는 Root Encryption Key와 관련된 HSM key를 HashiCorp Vault에 저장할 수 있고, 이때 Vault Transit Engine을 사용합니다. 이 구조에서는 MinIO KMS 접근 권한이 있는 사용자가 곧바로 plaintext key에 접근하지 못하게 분리할 수 있습니다. (MinIO AIStor Documentation)
즉 AIStor 관점에서 Vault는 다음 역할을 할 수 있습니다.
| 구조 | Vault 역할 |
|---|---|
| AIStor + KES + Vault | AIStor SSE용 외부 key store |
| AIStor + MinIO KMS + Vault | MinIO KMS의 HSM/sealing key 보관 |
| Vault Transit | key encryption/decryption/HMAC API 제공 |
| 운영 통제 | key 사용 권한, 감사 로그, 접근 정책 통제 |
다만 이 영역은 신중해야 합니다. AIStor 암호화를 켠 뒤 Vault/KMS 접근 장애가 생기면 object store 기동과 복호화 경로에 직접 영향을 줄 수 있습니다. 그래서 Vault를 AIStor KMS 경로에 넣는다면 Vault HA, unseal/recovery 절차, DR, 백업, audit device까지 운영 등급으로 설계해야 합니다.
5. Kubernetes workload identity 연동
Kubernetes에서 Vault를 잘 쓰려면 Pod 안에 Vault token을 하드코딩하지 않고, Kubernetes ServiceAccount token으로 Vault에 로그인하게 하는 구조를 많이 씁니다. Vault Kubernetes Auth Method는 Kubernetes Service Account Token을 사용해 Vault에 인증하고, 이를 통해 Pod에 Vault token을 주입하는 방식입니다. (HashiCorp Developer)
예를 들면 다음과 같은 매핑을 만들 수 있습니다.
namespace: airflow-prod
serviceAccount: airflow-worker
↓
Vault role: airflow-worker
↓
Vault policy:
- database/creds/airflow-metadata-readwrite read
- kv/data/airflow/prod/* read
- pki/issue/internal-service update이 구조의 장점은 다음입니다.
| 장점 | 설명 |
|---|---|
| Pod별 최소 권한 | namespace/serviceAccount 기준으로 Vault policy 매핑 |
| 정적 Vault token 제거 | Pod spec이나 Git에 Vault token 저장 불필요 |
| TTL 기반 회수 | Pod가 받은 token과 secret에 만료시간 부여 |
| 감사 추적 | 어떤 workload가 어떤 secret을 읽었는지 추적 가능 |
| 멀티테넌트 분리 | 사용자/팀 namespace별 policy 분리 가능 |
귀하처럼 사용자 namespace가 많고 Airflow/Jupyter/Spark 런타임이 동적으로 뜨는 환경에서는 특히 유용합니다.
6. Kubernetes ServiceAccount token 자체를 동적으로 발급
조금 더 고급 용도로는 Vault가 Kubernetes ServiceAccount token, service account, role binding, role까지 동적으로 생성할 수도 있습니다. Vault Kubernetes Secrets Engine은 TTL이 있는 Kubernetes ServiceAccount token을 만들고, lease가 만료되면 생성된 객체를 자동 삭제할 수 있습니다. (HashiCorp Developer)
이건 예를 들어 다음 상황에서 쓸 수 있습니다.
| 상황 | 활용 |
|---|---|
| 임시 운영 Job | 특정 namespace에 30분짜리 권한만 부여 |
| 사용자별 분석 세션 | Jupyter 사용자 Pod에 제한된 SA token 발급 |
| 자동화 도구 | 배포/점검 시 필요한 권한을 짧게 부여 |
| break-glass | 장애 대응 시 승인된 시간 동안만 cluster 권한 발급 |
다만 Vault 문서도 Kubernetes Secrets Engine이 만든 token을 다시 Vault Kubernetes Auth Method 인증에 쓰는 것은 권장하지 않는다고 설명합니다. identity가 너무 많이 생겨 관리가 어려워질 수 있기 때문입니다. (HashiCorp Developer)
7. LDAP/AD 서비스 계정 패스워드 관리와 회전
Vault는 LDAP/AD 서비스 계정의 password checkout, 자동 rotation, dynamic LDAP credential, root credential rotation 같은 용도로도 쓰입니다. 공식 LDAP Secrets Engine 문서도 OpenLDAP/Active Directory 스키마 지원, 서비스 계정 checkout과 자동 패스워드 회전, static role과 LDAP credential 매핑, dynamic LDAP credential 등을 기능으로 설명합니다. (HashiCorp Developer)
귀하 환경에서는 다음에 해당합니다.
| 대상 | Vault 적용 |
|---|---|
| Keycloak ↔ LDAP bind 계정 | bind password 저장/회전 |
| MinIO/AIStor LDAP 연동 계정 | LDAP bind 계정 보호 |
| Jenkins LDAP bind 계정 | 장기 패스워드 노출 방지 |
| OpenSearch/Harbor/Nexus LDAP 연동 | 서비스 계정 패스워드 중앙관리 |
| 운영자 임시 LDAP 계정 | TTL 기반 계정 발급 또는 checkout |
AD/LDAP bind password는 여러 시스템에 널리 퍼지기 쉬워서, Vault로 중앙화하고 rotation 절차를 자동화하면 운영 리스크가 많이 줄어듭니다.
8. SSH 접근 통제
Vault는 SSH Secrets Engine으로 SSH signed certificate 또는 one-time password 방식의 접근을 지원합니다. 즉, 서버 접속용 개인키를 장기간 배포하지 않고, 사용자가 인증하면 일정 시간 동안만 유효한 SSH credential을 발급하는 구조를 만들 수 있습니다. (HashiCorp Developer)
대규모 운영 환경에서는 다음에 유용합니다.
| 기존 방식 | Vault 방식 |
|---|---|
| 운영자 SSH key를 서버에 배포 | Vault가 짧은 TTL의 SSH cert 발급 |
| 공용 계정 사용 | 사용자별 인증/감사 |
| 퇴사자 key 회수 어려움 | Vault/LDAP 권한 회수로 차단 |
| 장애 대응 계정 상시 존재 | 필요 시점에만 발급 |
다만 귀하 환경에서는 인프라팀이 sudo/root 권한을 엄격히 관리하는 상황이므로, SSH CA 방식까지 도입하려면 서버 담당팀과 PAM/SSHD/CA trust 체계를 같이 설계해야 합니다.
9. 중앙 권한 정책과 감사 로그
Vault는 모든 접근을 path 기반 policy로 통제합니다. Vault policy는 특정 path와 operation에 대해 허용/거부를 선언하고, 기본적으로 deny-by-default입니다. (HashiCorp Developer)
또한 Vault는 audit device를 통해 API request/response에 대한 audit log를 남깁니다. 공식 문서는 Vault가 활성화된 모든 audit device에 audit log를 쓰고, 적어도 하나의 audit device에 저장하지 못하면 요청을 처리하지 않는다고 설명합니다. 그래서 운영 환경에서는 audit device를 최소 두 개 이상 두는 것을 권장합니다. (HashiCorp Developer)
이 부분은 보안감사/내부통제 측면에서 매우 큽니다.
| 질문 | Vault로 추적 가능 |
|---|---|
| 누가 DB 패스워드를 발급받았나? | 가능 |
| 어떤 Pod가 어떤 Secret을 읽었나? | 가능 |
| 언제 인증서가 발급되었나? | 가능 |
| 어떤 운영자가 break-glass 권한을 받았나? | 가능 |
| 특정 credential이 언제 revoke 되었나? | 가능 |
10. 귀하 환경에서 우선순위를 매기면
Cloud Native Data Lakehouse, Air-gap, GitOps, AIStor, Keycloak/LDAP, Airflow/Jupyter/Spark 구조라면 저는 아래 순서로 봅니다.
| 우선순위 | Vault 용도 | 추천도 |
|---|---|---|
| 1 | Kubernetes Auth + workload별 Vault policy | 매우 높음 |
| 2 | DB dynamic credential | 매우 높음 |
| 3 | 내부 PKI/mTLS 인증서 발급 | 높음 |
| 4 | LDAP/AD bind 계정 및 서비스 계정 rotation | 높음 |
| 5 | Transit Engine 기반 app-level encryption | 중간~높음 |
| 6 | AIStor/MinIO KMS/HSM 연계 | 높지만 신중 |
| 7 | SSH signed certificate / break-glass 접근 | 중간 |
| 8 | 단순 KV Secret 저장소 | 기본 기능이지만 이것만 쓰면 아쉬움 |
11. 반대로 Vault에 굳이 넣지 않아도 되는 것
Vault를 도입하면 모든 Secret을 다 Vault에 넣고 싶어지는데, 다음은 조심하는 게 좋습니다.
| 대상 | 이유 |
|---|---|
| Git에 있어도 되는 비민감 설정 | ConfigMap/values.yaml로 충분 |
| 대용량 설정 파일/바이너리 | Vault는 object store나 artifact repo가 아님 |
| 매 요청마다 읽는 앱 설정 | Vault 부하 증가. 앱 시작 시 로딩/캐싱 권장 |
| Kubernetes Secret 전체의 무조건적 동기화 | etcd에 Secret이 다시 생기므로 “Secret 제거” 효과가 줄어듦 |
| AIStor object data 자체 | Vault는 데이터 백업 저장소가 아님 |
| 자주 변하는 런타임 상태 | Vault는 상태 DB 대체재가 아님 |
특히 Vault Secrets Operator나 External Secrets로 Vault 값을 Kubernetes Secret으로 동기화하면 운영 편의성은 좋아지지만, 결과적으로 Secret이 Kubernetes etcd에 저장됩니다. 따라서 정말 민감한 값은 Pod가 Vault Agent/CSI/SDK로 직접 가져오고 메모리 또는 임시 파일로만 사용하는 방식을 검토하는 게 좋습니다.
결론
Vault의 핵심 가치는 “Secret 보관”보다 “Secret 수명주기 관리”입니다.
귀하 환경에서는 다음 네 가지가 가장 실용적입니다.
- Pod가 Kubernetes ServiceAccount로 Vault에 로그인
- DB/LDAP/API credential을 장기 보관하지 않고 짧게 발급
- 내부 TLS/mTLS 인증서를 Vault PKI로 자동 발급
- AIStor/MinIO KMS 또는 app-level encryption의 key control point로 사용
즉, Git에서 Secret을 제거하는 것은 Vault 도입의 출발점이고, 실제 운영 가치는 동적 credential, 자동 rotation, 짧은 TTL, 중앙 감사, KMS/PKI 통제에서 나옵니다.
