Ssoon

HashiCorp Vault - Jenkins + Vault (AppRole) - CI 본문

CICD Study [1기]

HashiCorp Vault - Jenkins + Vault (AppRole) - CI

구구달스 2025. 11. 27. 20:38

 

 

출처 : https://blog.naver.com/wideeyed/222104895021

◆ AppRole 개념 요약

  • AppRole은 머신 또는 자동화 워크로드를 위해 설계된 Vault 인증 method입니다.
    AppRole은 RoleID와 SecretID라는 두 요소로 구성되며, 이 둘의 조합으로 인증해 token을 발급받습니다.
    Role는 정책(Policy)과 연계되어 있으며 Role에 매핑된 policy가 발급된 token의 권한을 결정합니다.
    SecretID는 여러 모드(예: 생성 시 반환, pull 방식, wrapped token 방식 등)로 발급·전달될 수 있으며, 생애주기(lifecycle)를 갖습니다.
    • "AppRole은 머신 신원증명(identity)과 권한(policy)을 분리해 안전한 자동화 인증을 제공한다."

◆ Jenkins에서 AppRole을 사용하는 이유

  • Jenkins는 CI 서버로서 많은 자동화 작업을 수행하며, 그 과정에서 민감한 시크릿을 필요로 합니다.
    Jenkins에 장기 비밀(예: 고정된 Vault token)을 저장하면 유출 시 위험도가 크기 때문에 AppRole 같은 머신 전용 인증을 권장합니다.
    HashiCorp는 자동화 서버용으로 AppRole을 권장하며, 가능한 한 Vault Agent를 사용해 토큰을 관리하지 않도록 권고합니다. 
    • "AppRole을 사용하면 Jenkins가 자체적으로 장기 비밀을 보유하지 않고도 안전하게 Vault로부터 시크릿을 얻을 수 있다." 

◆ 통합 아키텍처 — 핵심 컴포넌트와 흐름

  • Jenkins Controller와 Agent(worker) 구조에서, 빌드 실행 주체(일반적으로 Agent)가 Vault에 인증하여 필요한 시크릿을 얻는 방식이 일반적입니다.
    통합 핵심 요소는 다음과 같습니다: Vault 서버(및 auth backend로 AppRole), Jenkins Controller, Jenkins Agent, 시크릿 전달·보관 메커니즘(예: Jenkins Credentials, ephemeral 환경변수, 파일).
    인증 흐름은 일반적으로 다음과 같이 진행됩니다: Jenkins가 Vault에 AppRole 인증 요청 → Vault가 token 발급 → Jenkins가 해당 token으로 secret path를 조회 → build에 시크릿 주입.
    • "핵심은 Jenkins의 실행주체가 AppRole로 인증해 임시 token을 받고, 그 token으로 필요한 시크릿을 조회하는 것이다."

◆ AppRole 인증 전달 방식의 유형과 장단점

  • Static SecretID (비권장 — dev only)
    • SecretID를 장기적으로 고정해 Jenkins에 보관하는 방식입니다.
    • 구현이 간단하지만 SecretID 유출 시 재발급·회수해야 하며 운영상 위험도가 높습니다.
      • "Static SecretID는 운영 환경에서는 보안상 권장되지 않는다." 
  • Short-lived SecretID / One-time SecretID (권장)
    • SecretID를 짧은 수명으로 발급하거나 한 번만 사용하도록 구성합니다.
    • SecretID를 발급하는 주체(예: 운영자가 매일 발급하거나 자동화된 매커니즘이 발급)를 통해 노출 위험을 줄입니다.
      • "Short-lived 또는 one-time SecretID는 공격 표면을 줄이기 위해 권장되는 패턴이다." 
  • Pull-mode AppRole (SecretID를 외부에서 'pull'하도록 구성)
    • Vault에서 SecretID를 직접 노출하지 않고, 안전한 전달 채널을 통해 Jenkins에 제공하거나, 필요 시 Vault Agent가 SecretID를 안전하게 가져오도록 설계합니다.
      • "SecretID의 안전한 전달 전략을 갖추는 것이 핵심 보안 패턴이다." 
  • Wrapped SecretID / Response Wrapping
    • SecretID나 token을 한 번만 풀 수 있는 wrapping token 형태로 전달해 중간자 노출을 방지합니다.
      • "response wrapping을 사용하면 전달 과정에서의 유출 위험을 추가로 완화할 수 있다." 

◆ 실제 운영 권장 패턴 (보안·운영 관점)

  • Vault는 가능한 한 Jenkins가 장기 토큰을 보유하지 않도록 설계하라고 권고합니다.
    Vault Agent를 사용해 token 생명주기 관리를 위임하거나, SecretID를 매우 짧게 발급하고 배포 주기를 자동화하는 방식이 권장됩니다. 
    AppRole에는 적절한 정책(policy)을 연결해 최소 권한 원칙(least privilege)을 적용해야 합니다.
    SecretID 발급과 사용에 대해 audit logging을 활성화해 누가 언제 어떤 시크릿을 요청했는지 추적 가능하게 해야 합니다.
    • "운영에서는 Vault Agent 위임, 최소 권한 정책, 짧은 SecretID 수명, 감사 활성화를 기본 원칙으로 삼아야 한다." 

◆ Jenkins 통합 방식

  • Jenkins HashiCorp Vault Plugin 사용(Controller에 설정)
    • Jenkins용 공식/커뮤니티 플러그인을 통해 AppRole 인증을 설정할 수 있습니다.
    • Plugin은 RoleID/SecretID를 Credential로 관리하고, Pipeline 단계에서 Vault secrets를 가져오는 기능을 제공합니다.
    • 플러그인은 편의성이 크지만, Credential 저장소(SecretID 관리 방식)에 따른 보안 고려가 필요합니다.
      • "Jenkins 플러그인은 편리하지만 SecretID의 저장·갱신·회수 전략을 명확히 해야 한다."
  • Vault Agent 또는 외부 스크립트를 이용한 Pull 방식
    • Jenkins 빌드 실행 전 Agent(또는 init step)가 Vault로 AppRole 인증을 수행해 token을 얻고 시크릿을 가져와 빌드 환경에 주입합니다.
    • Vault Agent를 쓰면 token/renewal 관리를 Vault Agent에 위임할 수 있어 Jenkins 쪽에서 민감 정보 관리를 줄일 수 있습니다. 
      • "Vault Agent는 토큰 수명과 갱신을 관리하므로 Jenkins 쪽의 비밀 노출 위험을 낮춘다." 
  • External Secret Broker / Short-lived Credential Broker 패턴
    • 별도의 credential broker(예: 자동화 스크립트, CI 매니저)에서 SecretID를 안전히 발급·유통하고 Jenkins가 broker로부터 일회성 SecretID를 받는 패턴입니다.
      • "브로커 패턴은 SecretID 발급·감사·회수 제어를 중앙화할 때 유리하다."

✅ Jenkins + KV 시크릿

0️⃣ Jenkins 사전구성

  • Jenkins 컨테이너 기동
⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ cat <<EOT > docker-compose.yaml
services:

  jenkins:
    container_name: jenkins
    image: jenkins/jenkins
    restart: unless-stopped
    networks:
      - cicd-network
    ports:
      - "8080:8080"
      - "50000:50000"                      # Jenkins Agent - Controller : JNLP
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - jenkins_home:/var/jenkins_home

volumes:
  jenkins_home:

networks:
  cicd-network:
    driver: bridge
EOT
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ docker compose up -d
[+] Running 13/13
 ✔ jenkins Pulled                                                                                 19.9s
   ✔ 13cc39f8244a Pull complete                                                                    8.1s
   ...                                                                16.5s
[+] Running 3/3
 ✔ Network ssoon_cicd-network  Created                                                             0.1s
 ✔ Volume ssoon_jenkins_home   Created                                                             0.0s
 ✔ Container jenkins           Started                                                             1.7s
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ docker compose ps
NAME      IMAGE             COMMAND                  SERVICE   CREATED         STATUS         PORTS
jenkins   jenkins/jenkins   "/usr/bin/tini -- /u…"   jenkins   5 seconds ago   Up 3 seconds   0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp, 0.0.0.0:50000->50000/tcp, [::]:50000->50000/tcp
  • Jenkins 컨테이너 초기 설정 
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ docker compose exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword
01bc4e6918a540abbc0021840dc03c3d

  • 사용자 계정생성
    • Username: admin
    • Password: qwe123
  • Jenkins URL 설정

1️⃣ Jenkins에서 Vault Plugin 설치

2️⃣ Vault AppRole 정보 확인

  • role_id 확인 / secret_id 확인
    • role_id
      → AppRole을 식별하는 ID (고정값).
      Jenkins나 애플리케이션이 Vault에 인증할 때 필요.
    • secret_id
      → AppRole 인증의 두 번째 요소 (일종의 비밀번호).
      TTL과 사용 횟수 제한을 가질 수 있음.
      여기서는 secret_id_ttl = 1h로 설정되어 있어 1시간 후 만료됩니다.
    • role_id.txt → 59bcf2b3-5ab2-58f8-a631-055b2039ea30
    • secret_id.txt → 1e13ce12-f596-4050-307f-6525bc3ed51d (이전 발급)
    • 새로 발급한 secret_id → 7730d591-df60-fee3-1ad1-04835c5d85c3
      TTL: 1시간, 사용 횟수 제한 없음 (secret_id_num_uses = 0)
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ cd approle-creds
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~/approle-creds$ cat role_id.txt
59bcf2b3-5ab2-58f8-a631-055b2039ea30
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~/approle-creds$ cat secret_id.txt
1e13ce12-f596-4050-307f-6525bc3ed51d
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~/approle-creds$ vault read auth/approle/role/sampleapp-role/role-id
Key        Value
---        -----
role_id    59bcf2b3-5ab2-58f8-a631-055b2039ea30
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~/approle-creds$ vault write -f auth/approle/role/sampleapp-role/secret-id
Key                   Value
---                   -----
secret_id             7730d591-df60-fee3-1ad1-04835c5d85c3
secret_id_accessor    6627c053-8abd-c604-96c5-9c03bb26a84c
secret_id_num_uses    0
secret_id_ttl         1h

3️⃣ Jenkins에서 Vault 설정 및 Credentials 추가

  • Jenkins UI(admin/qwe123) → Manage Jenkins → Configure System

4️⃣ Jenkins Pipeline Job 생성

  • Jenkinsfile
pipeline {
  agent any

  environment {
    VAULT_ADDR = 'http://172.18.234.111:30000' // 실제 Vault 주소로 변경!!! 파드 경우 http://vault.vault.svc:8200
  }

  stages {
    stage('Read Vault Secret') {
      steps {
        withVault([
          vaultSecrets: [
            [
              path: 'secret/sampleapp/config',
              engineVersion: 2,
              secretValues: [
                [envVar: 'USERNAME', vaultKey: 'username'],
                [envVar: 'PASSWORD', vaultKey: 'password']
              ]
            ]
          ],
          configuration: [
            vaultUrl: "${VAULT_ADDR}",
            vaultCredentialId: 'vault-approle-creds'
          ]
        ]) {
          sh '''
            echo "Username from Vault: $USERNAME"
            echo "Password from Vault: $PASSWORD"
          '''
          script {
            echo "Username (env): ${env.USERNAME}"
            echo "Password (env): ${env.PASSWORD}"
          }
        }
      }
    }
  }
}
  • Jenkins 실행결과 → 보안상 취약하므로 마스킹처리

✅ Jenkins + 동적(Dynamic) DB 시크릿

1️⃣ 인프라 구성 (PostgreSQL on K8s)

  • Vault가 계정을 생성해 줄 타겟 DB를 K8s에 배포
  • Jenkins가 외부에서 접속 테스트를 위한 NodePort 30001 오픈
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~/approle-creds$ cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
  namespace: default
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:13
          env:
            - name: POSTGRES_PASSWORD
              value: "rootpassword"
            - name: POSTGRES_DB
              value: "mydb"
          ports:
            - containerPort: 5432
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
  namespace: default
spec:
  type: NodePort
  ports:
    - port: 5432
      targetPort: 5432
      nodePort: 30002  # [External] Jenkins 접속용
  selector:
    app: postgres
EOF
deployment.apps/postgres created
service/postgres created

2️⃣ Vault Database Engine 설정

  • Database Secret Engine 활성화
    • database/ → Database Secrets Engine (PostgreSQL 동적 크리덴셜 발급용)
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ vault secrets list
Path          Type         Accessor              Description
----          ----         --------              -----------
cubbyhole/    cubbyhole    cubbyhole_649880ef    per-token private secret storage
database/     database     database_a1043ab0     n/a
identity/     identity     identity_6f0e93c1     identity store
secret/       kv           kv_cc436ec6           key/value secret storage
sys/          system       system_4a77190f       system endpoints used for control, policy and debugging
  • Vault -> Postgres 연결 설정
    • plugin_name=postgresql-database-plugin
      → Vault가 PostgreSQL에 접속/사용자를 생성하기 위해 사용하는 플러그인.
    • allowed_roles="jenkins-role"
      → 이 DB 설정을 사용할 수 있는 Vault Database Role을 제한합니다.
      database/roles/jenkins-role만 이 설정을 통해 동적 크리덴셜을 발급 가능.
    • connection_url=...
      → Vault가 DB에 접속할 때 사용할 연결 문자열입니다.
      • {{username}}와 {{password}}는 아래에 제공한 관리자 계정(username, password) 값으로 동적으로 치환됩니다.
      • postgres.default.svc.cluster.local:5432는 Kubernetes 서비스 DNS와 포트(일반적으로 5432)를 사용.
      • mydb는 Vault가 사용자 생성/권한 부여를 수행할 대상 데이터베이스 이름.
      • sslmode=disable은 TLS를 끈 설정(개발/테스트에서 주로 사용). 운영에서는 require/verify-full 권장.
    • username / password
      • Vault가 DB에 접속하여 임시 계정을 만들 때 사용할 관리자 권한 계정입니다.
      • 여기서는 postgres / rootpassword를 사용
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ vault write database/config/my-postgresql-database \
    plugin_name=postgresql-database-plugin \
    allowed_roles="jenkins-role" \
    connection_url="postgresql://{{username}}:{{password}}@postgres.default.svc.cluster.local:5432/mydb?sslmode=disable" \
    username="postgres" \
    password="rootpassword"
Success! Data written to: database/config/my-postgresql-database
    • db_name=my-postgresql-database
      → Vault가 연결할 DB 설정 이름(사전에 vault write database/config/...로 등록한 DB 연결 정보)
    • creation_statements="..."
      → Vault가 임시 계정을 만들 때 실행할 SQL:
      • {{name}}, {{password}}, {{expiration}} → Vault가 동적으로 채워줌
      • 계정은 로그인 가능, 비밀번호 설정, 만료 시간 지정
      • 권한: public 스키마의 모든 테이블에 SELECT 권한 부여
      •  
        CREATE ROLE "{{name}}" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'
    • default_ttl="1h"
      → 발급된 DB 계정은 기본적으로 1시간 후 만료
    • max_ttl="24h"
      → 최대 연장 가능 시간은 24시간"1시간짜리 임시 계정" 생성 규칙 정의 (DB Role)
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ vault write database/roles/jenkins-role \
    db_name=my-postgresql-database \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"
Success! Data written to: database/roles/jenkins-role

3️⃣ 기존 AppRole 권한 확장 (Policy Update)

  • 기존 KV 권한 + 새로운 DB 권한(database/creds/jenkins-role) 병합
    • KV v2 비밀 데이터 읽기
      • secret/data/sampleapp/* 경로에서 읽기(read) 권한을 줍니다.
      • sampleapp 관련 비밀 값을 가져올 수 있음.
    • KV v2 메타데이터 조회
      • secret/metadata/sampleapp/* 경로에서 목록(list)과 읽기(read) 권한을 줍니다.
      • Vault의 KV v2 플러그인에서 에러를 방지하려면 메타데이터 접근이 필요합니다.
    • DB 자격증명 발급
      • database/creds/jenkins-role 경로에서 읽기(read) 권한을 줍니다.
      • Vault가 DB 동적 크리덴셜을 생성할 때 이 역할을 사용할 수 있음.
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ vault policy write sampleapp-policy - <<EOF
# 1. KV v2 데이터 읽기
path "secret/data/sampleapp/*" {
  capabilities = ["read"]
}
# 2. KV v2 목록 조회 (플러그인 에러 방지용 필수!)
path "secret/metadata/sampleapp/*" {
  capabilities = ["list", "read"]
}
# 3. DB Creds 발급
path "database/creds/jenkins-role" {
  capabilities = ["read"]
}
EOF
Success! Uploaded policy: sampleapp-policy
  • 업데이트된 Policy 확인
    • sampleapp은 Vault에서 비밀 값 읽기, 목록 조회, 그리고 DB 크리덴셜 발급을 할 수 있는 권한을 갖게 됩니다.
    • 쓰기(write)나 삭제(delete)는 허용하지 않음 → 안전한 읽기 전용 정책.
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ vault policy read sampleapp-policy
# 1. KV v2 데이터 읽기
path "secret/data/sampleapp/*" {
  capabilities = ["read"]
}
# 2. KV v2 목록 조회 (플러그인 에러 방지용 필수!)
path "secret/metadata/sampleapp/*" {
  capabilities = ["list", "read"]
}
# 3. DB Creds 발급
path "database/creds/jenkins-role" {
  capabilities = ["read"]
}
  • 관리자 로그인 상태에서 실행. token polices에 default도 함께추가
    • token_policies="default,sampleapp-policy"
      • 이 AppRole로 발급되는 토큰은 default 정책과 sampleapp-policy 정책을 적용받습니다.
      • 앞에서 만든 sampleapp-policy 권한을 사용할 수 있음.
    • secret_id_ttl="0"
      • Secret ID는 만료되지 않습니다(무제한).
      • Secret ID는 AppRole 인증 시 필요한 두 번째 요소입니다.
    • token_ttl="1h"
      • 발급된 토큰은 기본적으로 1시간 동안 유효합니다.
    • token_max_ttl="4h"
      • 토큰은 최대 4시간까지 연장 가능합니다.
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ vault write auth/approle/role/sampleapp-role \
  token_policies="default,sampleapp-policy" \
  secret_id_ttl="0" \
  token_ttl="1h" \
  token_max_ttl="4h"
Success! Data written to: auth/approle/role/sampleapp-role
  • sampleapp 애플리케이션이 Vault에 접근할 때 AppRole 방식을 사용하도록 설정한 것.
  • 이 AppRole로 인증하면:
    • sampleapp-policy 권한을 가진 토큰을 발급받음.
    • 토큰은 1시간짜리, 최대 4시간까지 연장 가능.
    • Secret ID는 만료되지 않음.

4️⃣ Pipeline 작성 (Jenkinsfile)

  • 파이프라인에서 KV Secret과 DB Dynamic Secret을 동시에 사용하는 시나리오를 구현
  • Jenkinsfile
    • 환경변수 설정
      • VAULT_ADDR : Jenkins가 접근할 Vault 주소(NodePort)
      • DB_HOST, DB_PORT : Jenkins가 접근할 DB 주소(NodePort)
    • withVault 블록으로 Vault 연동
      • vaultCredentialId: 'vault-approle-creds' : Jenkins에 저장된 AppRole(ROLE_ID/SECRET_ID) 자격증명 사용
      • vaultSecrets:
        • KV v2 (정적 시크릿) → engineVersion: 2
          • 경로: secret/sampleapp/config
          • 키: username → 환경변수 STATIC_USER
        • Database 엔진 (동적 시크릿) → engineVersion: 1
          • 경로: database/creds/jenkins-role
          • 키: username, password → 환경변수 DB_USER, DB_PASS
    • 출력/검증
      • STATIC_USER, DB_USER 값을 sed로 공백 삽입해 마스킹을 느슨히 확인
      • DB 연결 문자열을 출력(실제 접속은 하지 않음 → 시뮬레이션)
    • post 블록
      • 성공 시: 발급된 DB 계정은 TTL에 따라 자동 만료됨을 안내
      • 실패 시: Vault 로그/네트워크 점검 권고
pipeline {
  agent any

  environment {
    // Jenkins(Docker) -> Vault(K8s NodePort)
    // 주의: http:// 가 포함된 전체 주소
    // Jenkins 파드 사용 시 : http://vault.vault.svc:8200
    VAULT_ADDR = 'http://172.18.234.111:30000' 
    
    // Jenkins(Docker) -> DB(K8s NodePort)
    // 주의: DB 접속에는 프로토콜(http://) 없이 IP만 필요합니다.
    // Jenkins 파드 사용 시 : DB_HOST = 'postgres.default.svc' , DB_PORT = '5432'
    DB_HOST = '172.18.234.111'
    DB_PORT = '30002'
  }

  stages {
    stage('Vault 통합 및 DB 접속 테스트') {
      steps {
        withVault([
          configuration: [
            vaultUrl: "${VAULT_ADDR}",
            vaultCredentialId: 'vault-approle-creds',
            // ⚠️ 중요: 여기서 전역 engineVersion 설정을 하지 않습니다.
            skipSslVerification: true
          ],
          vaultSecrets: [
            // 1. KV Secret (정적 시크릿)
            // KV v2 엔진을 사용하므로 engineVersion: 2를 명시합니다.
            [
              path: 'secret/sampleapp/config',
              engineVersion: 2,
              secretValues: [
                [envVar: 'STATIC_USER', vaultKey: 'username']
              ]
            ],
            // 2. Database Secret (동적 시크릿)
            // DB 엔진은 기본 방식(v1)으로 통신해야 경로 에러가 없습니다.
            [
              path: 'database/creds/jenkins-role',
              engineVersion: 1,
              secretValues: [
                [envVar: 'DB_USER', vaultKey: 'username'],
                [envVar: 'DB_PASS', vaultKey: 'password']
              ]
            ]
          ]
        ]) {
          script {
            echo "=================================================="
            echo "             Vault 연동 테스트 시작                "
            echo "=================================================="

            // 1. 정적 시크릿 확인
            // sed 명령어로 글자 사이에 공백을 넣어 마스킹(****)을 우회합니다.
            // 예: d e m o
            sh '''
              echo "[1] KV Secret (Static)"
              echo " - 원본 값은 보안상 **** 로 표시됩니다."
              echo " - 실제 값 확인: $(echo $STATIC_USER | sed "s/./& /g")"
            '''
            
            // 2. 동적 시크릿 확인 (핵심!)
            // Vault가 생성한 임시 DB 계정(v-token-...)을 확인합니다.
            sh '''
              echo "--------------------------------------------------"
              echo "[2] Database Secret (Dynamic)"
              echo " - Vault가 생성한 임시 계정 ID입니다."
              echo " - 실제 값 확인: $(echo $DB_USER | sed "s/./& /g")"
              echo "--------------------------------------------------"
            '''
            
            // 3. DB 접속 시뮬레이션
            // 실제 애플리케이션에서 DB 연결 문자열을 만드는 과정입니다.
            sh '''
              echo "[3] DB Connection Simulation"
              echo " - Connecting to: ${DB_HOST}:${DB_PORT}"
              echo " - User: ${DB_USER}"
              echo " - Password: (Hidden)"
              echo " >> ✅ DB 접속 테스트 성공! (가상)"
            '''
          }
        }
      }
    }
  }
  
  post {
    success {
      script {
        echo "🎉 Pipeline 성공!" 
        echo "   -> 확인된 DB 계정(${env.DB_USER})은 Vault의 TTL 설정에 따라 1시간 후 자동 삭제됩니다."
      }
    }
    failure {
      echo "💥 Pipeline 실패! Vault 로그나 네트워크 설정을 확인하세요."
    }
  }
}
  •  PostgreSQL 역할(Role) 목록
    • postgres
      • 기본 관리자 계정
    • v-approle-jenkins--WGfo8EqcVte9p96C2Oxa-1764428934
      • Vault Database Secrets Engine이 발급한 임시 계정
      • 특징:
        • 이름이 v-approle-jenkins--... 형태 → Vault가 동적으로 생성
        • Password valid until 2025-11-29 16:08:59+00 → TTL 기반, 만료 후 자동 삭제
        • 권한은 최소화(일반적으로 특정 DB에만 접근 가능)
  •  
(⎈|kind-myk8s:vault) ssoon@DESKTOP-72C919S:~$ kubectl exec -it -n default deploy/postgres -- psql -U postgres
psql (13.23 (Debian 13.23-1.pgdg13+1))
Type "help" for help.

postgres=# \du

 
저작자표시 (새창열림)

'CICD Study [1기]' 카테고리의 다른 글

HashiCorp Vault - Vault Secrets Operator  (0) 2025.12.07
HashiCorp Vault - 암호화(Encryption)와 Vault Transit 엔진  (0) 2025.11.27
HashiCorp Vault - Vault Agent와 Sidecar 패턴  (0) 2025.11.27
HashiCorp Vault - Vault on Kubernets 설치  (0) 2025.11.27
HashiCorp Vault - Vault 기본 구조와 동작 방식  (0) 2025.11.27
'CICD Study [1기]' Related Articles more
Comments