어떤 인증 메소드를 사용해야 할까?

Vault는 다양한 인증 메소드를 제공하여 서로 다른 사용자, 애플리케이션, 인프라 환경에서 안전하게 시크릿에 접근할 수 있도록 합니다. 적절한 인증 방식을 선택하는 것은 보안성과 운영 효율성을 모두 고려해야 하는 중요한 결정입니다.

1. 인증 대상별 분류

1.1 휴먼 사용자 인증 (Human Authentication)

대상: 개발자, 운영자, 관리자 등 실제 사용자
특징: 대화형 인증, 일시적 접근, 개인별 권한 관리

휴먼 사용자 인증은 실제 사람이 직접 Vault에 접근해 시크릿을 조회하거나 관리할 때 주로 사용됩니다. 기업 환경에서는 개발자나 운영자가 로컬 PC에서 애플리케이션, 쉪스크립트 등 다양한 쉘을 통해 클라우드 크리덴셜, 데이터베이스 비밀번호, API 키 등을 환경변수나 특정 파일로 손쉽게 받아와야 하는 경우가 많습니다. 이때 Vault의 휴먼 인증 방식을 활용하면, 사용자는 본인의 계정으로 안전하게 인증을 거쳐 필요한 시크릿만 받아올 수 있습니다. SSO, OIDC, LDAP 등과 연동하면 기존 사내 인증 체계를 그대로 활용할 수 있어 관리가 편리하고, 권한을 세분화해 최소 권한 원칙을 적용할 수 있습니다. 또한, 누가 언제 어떤 시크릿을 조회했는지 감사 추적이 가능해 보안 사고 대응이 용이합니다. 휴먼 인증 방식은 일시적 접근, 개인별 권한 관리, 접근 이력 추적 등 기업 보안 정책을 효과적으로 준수할 수 있게 해주며, 자동화 스크립트와 연계해 반복적인 작업도 안전하게 처리할 수 있다는 장점이 있습니다.

적합한 인증 메소드

• OIDC (OpenID Connect)

  • 기업 내 SSO(Single Sign-On)와 연동
  • Google, Azure AD, Okta 등 외부 IdP 활용
  • 다중 인증 요소(MFA) 지원
  • 사용 예: 개발자가 웹 UI를 통해 Vault 접근

• LDAP

  • Active Directory와 연동
  • 기존 디렉터리 서비스 활용
  • 사용 예: 기업 내 AD 계정으로 Vault CLI 사용

• Userpass

  • 간단한 사용자명/비밀번호 인증
  • 소규모 환경이나 테스트 환경에 적합
  • 사용 예: 개발 환경에서 간단한 인증

인증 플로우

사용자 → 인증 제공자(IdP) → Vault 토큰 발급 → 시크릿 접근

1.2 머신 인증 (Machine Authentication)

대상: 서버, 컨테이너, 가상 머신 등 시스템 레벨 인증
특징: 무인 인증, 시스템 ID 기반, 자동화된 인증

머신 인증은 사람이 직접 개입하지 않고 서버, 컨테이너, 가상 머신 등 시스템이 자동으로 Vault에 접근해야 할 때 필요합니다. 예를 들어, 웹 애플리케이션 서버가 배포 시점마다 데이터베이스 비밀번호를 동적으로 받아오거나, CI/CD 파이프라인에서 빌드 및 배포 작업 중 민감한 API 키를 안전하게 획득해야 하는 경우가 대표적입니다. 또한, 쿠버네티스 환경에서는 각 Pod가 자체적으로 Vault에서 시크릿을 받아와야 하며, 클라우드 인프라에서는 EC2, GCE 등 인스턴스가 자체 메타데이터를 활용해 인증을 수행할 수 있습니다. 머신 인증을 통해 운영 자동화, 보안성 강화, 시크릿 노출 최소화가 가능하며, 사람이 직접 관리하지 않아도 시스템 간 신뢰성 있는 인증과 접근 제어가 이루어집니다.

적합한 인증 메소드

• AppRole

  • 범용적인 머신 인증 방식
  • Role ID + Secret ID 조합
  • 다양한 환경에서 활용 가능
  • 사용 예: 애플리케이션 서버가 데이터베이스 자격 증명 획득

• AWS IAM

  • AWS 인스턴스 메타데이터 기반 인증
  • IAM Role 또는 IAM User 활용
  • AWS 환경에서 가장 안전한 방식
  • 사용 예: EC2 인스턴스에서 RDS 자격 증명 획득

• Kubernetes

  • 쿠버네티스 Service Account 기반 인증
  • JWT 토큰을 이용한 인증
  • 컨테이너 환경에 최적화
  • 사용 예: Pod에서 외부 API 키 획득

• TLS Certificate

  • X.509 인증서 기반 인증
  • PKI 인프라 활용
  • 높은 보안 수준 요구 시 사용
  • 사용 예: 중요 시스템 간 통신 및 인증서 기반 mTLS 인증

인증 플로우

머신 → 시스템 인증 정보 → Vault 토큰 발급 → 시크릿 접근

1.3 네트워크 기반 인증 (Network-Based Authentication)

대상: 특정 네트워크 세그먼트나 지역에서의 접근
특징: 위치 기반 인증, 네트워크 정책 적용

네트워크 기반 인증은 내부망, DMZ, 특정 지점 등 네트워크 경계에서 접근 제어가 필요할 때 필수적입니다. 예를 들어, 외부에서 직접 Vault에 접근할 수 없고, 반드시 프록시나 게이트웨이를 거쳐야 하는 환경에서는 네트워크 기반 인증이 효과적입니다. 머신 인증에 비해 네트워크 기반 인증은 개별 시스템의 신원 확인이 어렵고, 네트워크 침해 시 인증 우회 위험이 존재하는 단점이 있습니다. 반면, 중앙 집중적으로 네트워크 경계에서 인증을 처리하므로 관리가 단순해지고, 내부 시스템에 인증 로직을 별도로 구현하지 않아도 되어 운영 효율성이 높아집니다. 또한, 네트워크 정책과 연계해 접근을 제한할 수 있어 대규모 환경에서 유용합니다. 하지만 머신 인증은 각 시스템의 고유한 신원 정보를 활용해 더 세밀한 권한 제어와 보안성을 제공한다는 점에서 차이가 있습니다.

적합한 인증 메소드

• Vault Proxy
  • 네트워크 경계에서 인증 처리
  • 내부 네트워크에서는 사전 인증된 상태
  • 중앙 집중식 인증 관리
  • 사용 예: DMZ 영역에서 내부 시스템 접근

참고: Vault Agent는 인증 메소드가 아니라 인증을 자동화하거나 프록시 역할을 하는 도구입니다. 실제 인증은 AppRole, TLS Certificate 등과 조합하여 사용합니다.

인증 플로우

클라이언트 → 네트워크 프록시 → 사전 인증된 요청 → 시크릿 접근

1.4 CI/CD 도구 기반 인증 (CI/CD Tool Authentication)

대상: Jenkins, GitLab CI, GitHub Actions 등 자동화 도구
특징: 파이프라인 기반 인증, 임시 자격 증명 필요

CI/CD 도구가 Vault 인증 및 시크릿 전달을 처리하는 방식은 크게 두 가지 패턴으로 나눌 수 있습니다.

배포되는 App이 사용할 인증 요소를 전달하는 방식 (권장)

• 동작 방식:
  Jenkins와 같은 CI/CD 도구가 Vault에 인증(Cert, AppRole, Userpass 등)하여 앱이 필요한 인증 요소, 예를들어 AppRole의 secret_id만을 받아옵니다.
  이후 애플리케이션이나 스크립트가 실행될 때, Jenkins가 전달한 secret_id를 이용해 직접 인증하고 필요한 시크릿을 받아와서 실행에 활용합니다.

• 장점:

  • 시크릿(민감 정보)이 CI/CD 도구(Jenkins) 내부에 남지 않고, 실제 실행 주체(애플리케이션, 스크립트 등)가 직접 Vault에서 받아오기 때문에 최소 권한 원칙과 시크릿 노출 최소화를 실현할 수 있습니다.
  • 시크릿 접근 이력(감사 로그)이 실제 사용 주체별로 남아 보안 및 추적성이 높아집니다.
  • 시크릿이 환경변수나 로그 등 외부에 노출될 위험이 줄어듭니다.

• 단점:

  • 앱이 재시작되어야하는 경우 인증 요소를 다시 받아와야 합니다.

• 예시 플로우:

  Jenkins → Vault(AppRole 인증) → secret_id 획득 → 애플리케이션 실행 → Vault(AppRole 인증) → 시크릿 획득 → 작업 실행
  

시크릿 직접 전달 방식

• 동작 방식:
  Jenkins가 Vault에 직접 인증(AppRole, Cert 등)하여 필요한 시크릿을 직접 획득합니다.
  이후 애플리케이션 설정 파일이나 실행 시 환경변수로 넘겨 직접 시크릿을 사용하도록 합니다.

• 장점:

  • 이미 주입된 시크릿을 사용하므로 앱이 재시작되어도 인증 요소를 다시 받아오지 않아도 됩니다.

• 단점:

  • 시크릿이 Jenkins 내부에 남거나, 환경변수/로그 등 외부로 노출될 위험이 있습니다.
  • 시크릿 접근 이력이 실제 사용 주체(애플리케이션, 스크립트 등)가 아닌 Jenkins에만 남아, 추적성이 떨어집니다.
  • 여러 작업에서 동일 시크릿을 공유할 경우, 권한 분리가 어렵습니다.

• 예시 플로우:

  Jenkins → Vault(시크릿 직접 획득) → 애플리케이션 실행(시크릿 전달) → 작업 실행
  

보안 측면에서는 1) AppRole Secret ID 전달 방식을 권장합니다.
이 방식은 시크릿 노출을 최소화하고, 실제 사용 주체별로 접근 권한과 이력을 분리할 수 있어 운영 및 보안 모두에 유리합니다.

적합한 인증 메소드

• JWT (JSON Web Token)

  • CI/CD 도구에서 발급한 JWT 토큰 활용
  • 파이프라인 컨텍스트 정보 포함
  • 사용 예: GitLab CI, GitHub Actions 등에서 배포 스크립트 실행

• AppRole (Indirect)

  • CI/CD 도구가 Secret ID를 동적으로 생성
  • 실제 애플리케이션은 별도로 인증
  • 보안성 향상
  • 사용 예: Jenkins가 배포 스크립트에 Secret ID 전달

인증 플로우

CI/CD 도구 → 임시 자격 증명 생성 → 애플리케이션 전달 → Vault 인증

1.5 에이전트 기반 인증 (Agent-Based Authentication)

대상: 지속적으로 실행되는 장기 프로세스 및 직접 Vault에 인증하기 어려운 경우
특징: 백그라운드 실행, 자동 토큰 갱신, 시크릿 변경 감지

레거시 Baremetal이나 Virtual machine 환경에서는 컨테이너 오케스트레이션(Kubernetes 등)이나 클라우드 네이티브 인증 방식(AWS IAM, GCP IAM 등)을 활용하기 어렵습니다. 이때 Vault Agent를 사용하면, 애플리케이션이 직접 Vault에 인증하지 않아도 자동으로 토큰을 갱신하고, 시크릿을 안전하게 주입할 수 있습니다. 예를 들어, 웹 서버가 실행되는 VM에서 Vault Agent가 백그라운드로 동작하며, 설정 파일을 동적으로 렌더링하거나 환경변수로 시크릿을 주입해줍니다. 이를 통해 운영 자동화와 보안성을 동시에 확보할 수 있습니다.

적합한 인증 메소드

• Vault Agent
  • 자동 인증 및 토큰 갱신
  • 시크릿 템플릿 렌더링
  • 로컬 캐싱 지원
  • 사용 예: 웹 애플리케이션 설정 파일 동적 생성

인증 플로우

Vault Agent → 인증 → 토큰 관리 → 시크릿 동기화 → 애플리케이션 재시작

2. 적용 대상별 권장 인증 방식

적용 대상	권장 인증 방식
일반 애플리케이션, 클라우드 환경	TLS Certificate, AppRole, AWS IAM, Azure Auth Method, GCP Auth Method, OCI Auth Method, Kubernetes Auth
사용자 직접 실행 환경	OIDC, LDAP, AppRole
테스트 환경, 개발자 도구	Userpass, AppRole, GitHub, JWT
머신 단위 인증	TLS Certificate, Userpass, GitHub, AppRole
Vault Proxy/Agent	AppRole, Userpass, Token

3. 결론

Vault의 인증 방식 선택은 보안 요구사항, 운영 환경, 사용 패턴을 종합적으로 고려해야 합니다. 단일 인증 방식보다는 환경과 사용 사례에 따라 여러 인증 메소드를 조합하여 사용하는 것이 일반적입니다.

가장 중요한 것은 최소 권한 원칙을 적용하여 각 인증 주체가 필요한 시크릿에만 접근할 수 있도록 정책을 구성하는 것입니다.