[CI/CD Study] 7주차 - HashiCorp Vault

안녕하세요, CICD 학습을 위해 CloudNetaStudy 스터디 모임을 통해 진행한 내용을 정리하였습니다.

 

7주차 : [Vault] 에 대해 중점적으로 학습합니다. 

 

 

1. Vault 개요 및 시크릿 관리의 필요성

 

1.1. Vault란?

HashiCorp Vault는 신원 기반(Identity-based)의 시크릿 및 암호화 관리 시스템입니다. Vault는 다음 세 가지 핵심 기능을 하나의 인터페이스로 통합하여 제공합니다.

1. Encryption (암호화)
2. Secrets (시크릿 관리): 토큰, API 키, 비밀번호 등 모든 기밀 정보를 중앙에서 다룹니다.
3. Authentication & Authorization (인증 및 인가): 제한된 접근을 보장합니다.

 

1.2. 보안의 3요소 (CIA Triad)와 Vault

Vault는 정보보호의 3요소인 기밀성(Confidentiality), 무결성(Integrity), 가용성(Availability)을 모두 구현합니다.

• 기밀성: Secrets Engine을 통해 데이터를 암호화하여 저장하며, 접근 토큰 없이는 읽을 수 없습니다.
• 무결성: Hashing 기능을 통해 데이터가 임의로 변경되지 않았음을 검증합니다.
• 가용성: HA (High Availability) 구성을 통해 서버 장애 시에도 서비스가 중단 없이 지속되도록 합니다.

 

1.3. 시크릿 분산 (Secret Sprawl) 문제와 Vault의 해결책

현대 클라우드/MSA (Microservice Architecture) 환경에서 시크릿이 코드나 설정 파일 등 여러 곳에 하드 코딩되거나 분산되는 현상(Secret Sprawl)은 보안에 심각한 위협이 됩니다.

환경 문제	Vault의 해결책
동적 환경 (VM/컨테이너 수시 생성/삭제)	동적 시크릿 (Dynamic Secrets) 기능으로 임시 자격 증명을 발급/회수합니다.
시크릿 분산 (Secret Sprawl)	모든 시크릿을 중앙 집중식으로 관리합니다.
복잡한 접근 통제	신원 기반 접근 제어(Identity-Based Access)를 통해 명확히 통제합니다.

 

 

2. Vault의 동작 방식 및 AAA 모델

2.1. AAA 모델 (인증, 인가, 감사)

Vault는 접근 통제를 AAA 모델 (Authentication, Authorization, Accounting)을 기반으로 수행합니다.

• 인증 (Authentication - Who are you?):
  • 대상: 사람 (LDAP, Okta 등) 또는 애플리케이션/시스템 (AWS IAM, Kubernetes, AppRole 등)
  • 결과: 신원 확인 후 토큰(Token) 발급
• 인가 (Authorization - What can you do?):
  • 메커니즘: 정책 (Policy)을 통해 인증된 사용자에게 권한(읽기/쓰기 등)을 부여합니다.
• 감사 (Accounting/Auditing - What did you do?):
  • 기록: 사용자가 수행한 모든 활동을 Audit Logs (로그 파일)로 상세히 기록합니다.

 

2.2. Vault 설치 (Dev Mode) 예시

학습 환경(Kubernetes with Helm)에서 Vault를 배포할 때 사용하는 vault-values-dev.yaml 설정은 Dev Mode의 특징을 명확히 보여줍니다.

설정	설명
dev: enabled: true	개발 모드 활성화
datastorage: enabled: false	In-Memory Storage 사용 (재시작 시 데이터 초기화)
devRootToken: "root"	Root Token을 root로 고정 (학습 편의성)

 

YAML

# vault-values-dev.yaml 파일 예시
server:
  dev:
    enabled: true
    devRootToken: "root" # 학습 편의를 위해 Root Token을 'root'로 고정
  datastorage:
    enabled: false # Dev모드는 메모리 사용
ui:
  type: "NodePort"
  nodeport: 30000 
  enabled: true

 

3. 제로 트러스트 보안 모델

3.1. 과거 모델과의 차이

구분	과거 (성벽과 해자)	현재 (제로 트러스트)
신뢰	내부망 진입 시 무조건 신뢰	모든 접근 요청을 의심하고 검증 (Never Trust, Always Verify)
접근	해커 침입 시 수평 이동(Lateral Movement) 용이	신원 기반 인증 후 최소 권한만 부여

 

3.2. 제로 트러스트의 핵심 원칙

• "절대 신뢰하지 말고, 항상 검증하라 (Never Trust, Always Verify)"
• 신원 기반 검증: 네트워크 위치(내부망 여부)가 아닌 신원(Identity)을 기준으로 검증합니다.
• 최소 권한의 원칙 (Principle of Least Privilege): 작업에 필요한 최소한의 권한만 최소한의 시간 동안 부여합니다.

3.3. Vault와 제로 트러스트의 연관성

Vault는 제로 트러스트 환경을 구현하는 데 핵심적인 역할을 합니다.

• 신원 기반 접근 제어: Kubernetes Service Account, AWS IAM 등 시스템 신원을 기반으로 접근을 허용합니다.
• 동적 시크릿: 임시 자격 증명을 제공함으로써 최소 권한/최소 시간 원칙을 직접적으로 구현합니다.

 

4. 암호화 엔진 및 키 관리 (Transit Engine)

Vault는 단순한 시크릿 저장을 넘어, Encryption-as-a-Service (EaaS)를 제공하는 Transit Engine을 통해 암호화 서비스를 수행합니다.

4.1 핵심 암호화 방식 요약

구분	특징	용도
대칭키 (Symmetric)	암호화/복호화에 같은 키 사용.	대용량 데이터 처리, 빠른 속도.
비대칭키 (Asymmetric)	공개키/개인키 분리.	전자 서명, 신원 인증 (TLS, JWT), 키 교환.

 

| 해시 (Hash) | 고정 길이로 변환 (복호화 불가). | 데이터 무결성 검증, 비밀번호 저장 (Salt+Iteration). |

4.2. Vault Transit Engine (EaaS)

Vault의 Transit Engine은 애플리케이션 대신 암호화 및 복호화를 수행하여, 민감한 평문(Plaintext)이 Vault 외부에 노출되거나 저장되지 않도록 합니다.

• 특징: Vault는 평문 대신 암호화 결과(Ciphertext)만 반환합니다. 애플리케이션은 키를 관리할 필요가 없습니다. (키 외부 유출 방지).
• Transit 작동 구조:
• 애플리케이션이 Vault Transit API에 평문을 요청하면, Vault가 암호화 후 암호문을 반환하며, 이 암호문은 데이터베이스 등에 저장됩니다. 복호화 시에도 동일한 과정을 거칩니다.
• 클라우드 KMS와의 비교: Vault Transit은 특정 클라우드에 종속되지 않는 Cloud Agnostic 특징과 사용자 중심의 키 제어가 가능하다는 장점이 있습니다.

 

5. Vault Agent와 Sidecar 패턴 (애플리케이션 통합)

개발자가 복잡한 Vault 연동 로직(인증, 토큰 갱신, 에러 처리)을 직접 구현하는 비효율성 문제를 해결하기 위해 Vault Agent가 사용됩니다.

5.1. 해결책: Vault Agent (Sidecar 패턴)

Vault Agent는 Kubernetes 컨테이너 환경에서 Sidecar 컨테이너로 배포되어 애플리케이션을 대신하여 모든 Vault 작업을 자동 처리합니다.

기능	설명
자동 로그인 (Auto-Auth)	Agent가 K8s, AppRole 등 인증 방식으로 Vault 클라이언트 토큰을 대신 발급받습니다. 애플리케이션은 로그인 방식을 몰라도 됩니다.
토큰 자동 갱신 (Token Renewal)	토큰의 TTL을 체크하여 만료 전에 자동으로 갱신(Renew)합니다.
템플릿 렌더링	Vault에서 시크릿을 가져와 .env, config.json, tls.crt 등 애플리케이션이 읽기 쉬운 파일로 자동 생성/업데이트합니다.
Simplified Consumption	애플리케이션은 Vault API 호출 없이 Agent가 생성한 파일만 읽으면 됩니다.

 

5.2. Vault Agent Injector

Vault Agent Injector는 Kubernetes 클러스터에 배포되어 특정 주석(Annotation)이 있는 Pod에 Vault Agent Sidecar 컨테이너를 자동으로 주입하는 기능입니다.

• 주입 예시:
  YAML

  metadata:
    annotations:
      vault.hashicorp.com/agent-inject: "true"
      vault.hashicorp.com/role: "example-role"
  

 

6. Kubernetes 및 CI/CD 연동 도구

Vault는 Kubernetes 및 GitOps 기반 CI/CD 환경에 완벽하게 통합하기 위한 전문 도구들을 제공합니다.

 

6.1. Vault Secrets Operator (VSO)

VSO는 Kubernetes 환경에서 Vault의 시크릿을 Kubernetes Secrets으로 자동 동기화 및 관리하는 Operator입니다.

• 목적: 애플리케이션이 Vault API를 직접 호출할 필요 없이 K8s의 네이티브 시크릿을 통해 Vault 데이터에 접근할 수 있게 합니다.
• Dynamic Secrets 동기화: VSO는 동적 시크릿이 주기적으로 변경(갱신)될 때, K8s Secret에 반영하고 Deployment 등에 설정된 rolloutRestartTargets를 통해 Pod의 자동 롤아웃 재시작을 유도하여 갱신된 시크릿을 적용합니다.

6.2. CI/CD 보안 및 ArgoCD Vault Plugin (AVP)

• CI/CD 안티패턴 방지: 코드나 설정 파일에 db_pass = "admin123"와 같이 하드 코딩된 시크릿/인증 정보를 사용하는 행위(CWE-259, CWE-798)는 반드시 피해야 합니다.
• Vault를 통한 보안 연동 권장: CI/CD 파이프라인은 Vault와 연동하여 최소 권한, 최소 시간 원칙을 지켜야 합니다. AppRole 인증 방식이 권장됩니다.
• ArgoCD Vault Plugin (AVP): GitOps 툴인 ArgoCD가 배포 시 Vault에 접근하여 시크릿을 Kubernetes 리소스에 주입할 수 있도록 돕습니다.
  • AppRole Credential Secret 예시:
  • YAML

    # ArgoCD가 Vault에 인증하기 위한 AppRole 시크릿
    apiVersion: v1
    kind: Secret
    metadata:
      name: argocd-vault-plugin-credentials
      namespace: argocd
    type: Opaque
    stringData:
      VAULT_ADDR: "http://vault.svc:8200"
      AVP_TYPE: "approle"
      AVP_ROLE_ID: g2f3322e-3909-9786-d650-8ef5211aae00 # Vault에서 발급
      AVP_SECRET_ID: 52b3a1e9-c868-24d8-ce2b-e26ebd35239b # Vault에서 발급

     

7. Vault Secrets Operator (VSO)

VSO는 Vault의 시크릿을 Kubernetes 환경에서 Kubernetes Secrets으로 자동 동기화하고 관리하는 Operator입니다. 이 덕분에 애플리케이션은 Vault API를 직접 호출할 필요 없이 K8s의 네이티브 시크릿을 통해 안전하게 데이터에 접근합니다.

 

7.1. VSO의 작동 방식

• CRD 활용: VSO는 Kubernetes의 CRD (Custom Resource Definitions)를 사용하여 Vault의 시크릿 데이터를 K8s Secret 리소스에 매핑하고 동기화합니다.
• Operator 역할: 소스(Vault)의 시크릿 데이터 변경을 감시하고, 변경 사항이 발생할 경우 대상 K8s Secret에 지속적으로 반영(업데이트)합니다.
• 주요 기능: 다중 소스 동기화, 자동 시크릿 인젝션, Deployment/StatefulSet 등에 대한 자동 시크릿 교체 (시크릿 변경 시 Pod 재배포 유도), Prometheus 모니터링 지원.

7.2. Static Secrets과 Dynamic Secrets 동기화

시크릿 유형	개념	VSO의 역할 및 시나리오
Static Secrets	Vault의 KV Engine에 저장된 정적인 시크릿.	VSO가 KV 데이터를 읽어와 App Namespace의 Static Secret으로 생성합니다.
Dynamic Secrets	DB Credentials 등 주기적으로 변경/갱신되는 임시 시크릿.	VSO가 Dynamic Secret Engine을 사용하여 DB Credentials을 갱신하고, 갱신된 정보를 K8s Secret에 반영합니다. Spring 앱은 Secret을 참조하며, VSO는 rolloutRestartTargets를 통해 Pod 롤아웃 재시작을 유도하여 갱신된 시크릿을 적용합니다.

 

8. ArgoCD Vault Plugin (AVP)을 통한 CI/CD 연동

AVP는 GitOps 기반의 ArgoCD가 배포를 수행할 때, Vault의 시크릿 데이터를 Kubernetes 리소스에 주입(Inject)할 수 있도록 지원하는 핵심 도구입니다.

 

8.1. AVP의 역할 및 AppRole 인증

• GitOps 원칙 준수: ArgoCD가 Git에 정의된 리소스(Deployment, ConfigMap 등)를 배포할 때, Vault에 접근하여 필요한 시크릿 값을 안전하게 가져와 주입함으로써 GitOps 기반의 시크릿 관리 및 보안 규칙을 준수합니다.
• 권장 인증 방식: Vault와 ArgoCD 간의 접근 권한 부여를 위해 AppRole 인증 방식이 사용됩니다. ArgoCD의 Service Account에 기반하여 Vault에 접근할 수 있는 Role_ID와 Secret_ID를 설정합니다.

 

8.2. AppRole Credential 설정 (YAML 코드)

AVP가 Vault에 인증하는 데 사용되는 AppRole ID와 Secret ID는 다음과 같이 K8s Secret에 저장됩니다.

 

YAML

# AVP AppRole Credential 설정 예시 (K8s Secret)
apiVersion: v1
kind: Secret
metadata:
  name: argocd-vault-plugin-credentials
  namespace: argocd
type: Opaque
stringData:
  VAULT_ADDR: "http://vault.svc:8200" # Vault 서버 주소
  AVP_TYPE: "approle" # 인증 방식 지정
  AVP_ROLE_ID: g2f3322e-3909-9786-d650-8ef5211aae00 # Vault에서 발급받은 Role ID
  AVP_SECRET_ID: 52b3a1e9-c868-24d8-ce2b-e26ebd35239b # Secret ID

 

 

8.3. Plugin 설치 방식 (Sidecar 권장)

AVP는 argocd-cm ConfigMap을 통한 설치와 Sidecar 컨테이너를 통한 설치 방식이 있습니다. 보안성, 유지보수, 그리고 클러스터 환경의 격리 측면에서 Sidecar 컨테이너를 활용하는 것이 권장됩니다.

이러한 도구들은 개발자가 Vault API 호출이나 시크릿 갱신 로직에 신경 쓸 필요 없이, 플랫폼 표준(Kubernetes Secrets)을 통해 안전하고 효율적으로 기밀 정보를 사용할 수 있게 해줍니다.