마이그레이션 전략 및 고려 사항 가이드

마이그레이션 전략 및 고려 사항 가이드

자체 관리 Vault 클러스터를 HashiCorp Cloud Platform (HCP)에서 실행되는 Vault로 옮기려면 고려할 마이그레이션 전략과 사항이 있어요. 이 문서는 자체 관리 클러스터에서 호스팅 플랫폼으로 전환을 준비하는 데 도움이 되는 예시 마이그레이션 시나리오와 예제를 다뤄요.

출처: 문서

본문

자체 관리 Vault 클러스터를 HCP에서 실행되는 Vault로 옮기려면 마이그레이션 전략과 고려 사항을 염두에 둬야 해요. 이 문서는 자체 관리 클러스터에서 호스팅 플랫폼으로 전환을 준비하는 데 도움이 되는 예시 마이그레이션 시나리오와 예제를 다뤄요.

자체 관리 클러스터를 HCP Vault Dedicated로 옮기는 데 사용할 수 있는 마이그레이션 도구는 없어요.

마이그레이션 계획

기존 Vault 클러스터에서 다른 클러스터로 데이터를 마이그레이션하려면 신중하게 고안된 계획이 필요해요.

하지만 자체 호스팅 배포에서 HCP Vault Dedicated로 옮기는 이점은 상당해요. 이점은 다음과 같아요.

• 다운타임이 거의 없거나 없는 메이저·마이너 버전 업그레이드
• 재해 복구와 성능 복제 배포 단순화
• 워크로드 요구에 맞춰 클러스터를 확장·축소
• 운영 체제 유지 관리에 대한 운영 오버헤드 절감

계획 과정은 개발자가 Vault에서 경험할 수 있는 마찰점이나 경합 지점을 이해하고 해결할 기회도 제공해요.

원활한 마이그레이션을 보장하려면 권장 단계를 따르세요.

발견 (Discovery)

발견 단계에서는 핵심 이해 관계자를 식별해 그들이 Vault를 어떻게 사용하는지 파악해요. 워크숍, 인터뷰, 섀도잉(shadowing)을 통해 마이그레이션 중 해결해야 할 과제를 발견할 수 있어요. 보안 팀과 함께 초기 위협 모델링을 수행해 주세요.

플랫폼 설계

플랫폼 설계 단계에서는 발견 단계에서 수집한 정보를 사용해 패턴과 공통 요구 사항을 정의해요. 예:

• IAM 정의
• 시크릿 엔진 요구 사항
• 공통 역할과 정책
• 네임스페이스 요구 사항

수집한 정보로 올바른 설계를 만들면 조직에 최적의 적합성을 보장하는 Vault 구현을 설계할 수 있어요. 마이그레이션 과정 내내 피드백을 계속 수집하고 필요에 따라 설계를 반복해 주세요.

파이프라인 설계

발견 단계에서 설명한 정보 수집 작업을 완료하고 플랫폼 설계를 만들었다면, Vault 구성을 저장·배포하기 위한 파이프라인을 설계해야 해요. Vault 구성을 버전 관리 시스템에 저장하고, 보안 전략을 왼쪽으로 이동(shift-left)하며, 다음과 같은 좋은 사례를 따르세요.

• 브랜칭 (Branching)
• 환경 승격 (Environment promotion)
• 품질 게이트 (Quality gates)
• 테스팅 (Testing)
• 파이프라인 소유권 (Pipeline ownership)
• 코드 무결성 게이트 (Code integrity gates)
• 시크릿 스캐닝 (Secret scanning)

구현 (Implementation)

구현 단계는 다음을 포함해요.

• Vault를 테스트·배포·업데이트하기 위한 인프라스트럭처를 코드로 작성하고 관련 모듈을 만들기
• 역할 기반 접근 제어를 관리할 정책 작성
• 코드의 격차를 식별하고 발견된 버그를 해결하기 위한 품질 테스트 구현

온보딩 (Onboarding)

프로덕션 애플리케이션을 온보딩하기 전에 애플리케이션 팀과 파일럿 프로그램을 시작해 주세요.

파일럿 프로그램은 성공적인 도입 전략을 보장하고 다른 팀과의 신뢰를 구축하는 데 도움이 돼요. 파일럿 프로그램은 개발 버전에서 구현을 로컬로 테스트해요. 파일럿 프로그램의 피드백을 통해 식별된 문제에 기반해 설계와 구현을 조정할 수 있어요. 안정되면 애플리케이션 팀과 Vault 팀의 지원을 받아 애플리케이션을 하나씩 점진적으로 온보딩해 주세요.

위협 모델링 (Threat modeling)

애플리케이션 팀이 파일럿 프로그램을 진행하는 동안 보안 팀과 함께 위협 모델링을 수행해 주세요.

통제(controls)에는 다음이 포함돼요.

• 탐지적 (Detective)
• 예방적 (Preventive)
• 교정적 (Corrective)

이 작업은 최종 구현 전에 통제와 프로세스가 보안 요구 사항을 준수하는지 보장해요.

목표 운영 모델 (Target operating model)

팀이 확장됨에 따라 기존 설계를 재평가해야 할 수 있어요. 검토 중에도 워크플로를 조정하고 Vault를 비즈니스 성장에 맞추기 위해 동일한 단계적 접근 방식을 사용해 주세요.

마이그레이션 사전 요구 사항

기존 자체 관리 Vault 클러스터를 HCP Vault Dedicated로 마이그레이션하기 시작하기 전에 다음을 고려해 주세요.

• Vault Enterprise 버전: HCP Vault Dedicated의 버전은 자체 호스팅 Vault Enterprise 버전보다 크거나 같아야 해요.
• 클라우드 제공자 옵션: HCP Vault Dedicated를 HashiCorp 관리 AWS 또는 Azure 계정에 배포해요. 워크로드 요구 사항을 충족하는 클라우드 제공자, 또는 워크로드와의 연결을 가능하게 하는 클라우드 제공자를 선택해 주세요.
• 연결 옵션: 선택한 클라우드 제공자에 따라 워크로드를 HCP Vault Dedicated에 연결하는 여러 옵션이 있어요. 그 내용은 다음과 같아요.

공개 클러스터: 공개적으로 접근 가능한 엔드포인트로 클러스터를 만들어요. 이 옵션은 대부분의 클라우드 제공자 시크릿 관리 서비스가 동작하는 방식과 같아요. 피어링이나 전송 게이트웨이 연결(AWS 전용)을 지원하는 AWS·Azure 계정을 관리하지 않는다면 유용해요.IP 허용 목록이 있는 공개 클러스터: 공개 클러스터를 만들고 IP 허용 목록을 구성해 특정 IP 주소 또는 CIDR 범위로 접근을 제한해요. 정적 공개 IP 주소가 있거나 특정 공개 CIDR에서만 접근을 허용하려는 경우 유용해요.HVN 연결이 있는 비공개 클러스터: 비공개 클러스터를 만들고 HVN에 연결해요. HVN을 AWS 또는 Azure 가상 네트워크에 피어링하거나, AWS 전송 게이트웨이에 연결할 수 있어요. 모든 트래픽을 비공개로 유지하고 클라이언트가 클라우드 제공자의 가상 네트워크에 있는 경우 유용해요.중간 클라우드 제공자를 통한 VPN이 있는 비공개 클러스터: 비공개 클러스터를 만들고 HVN에 피어링한 뒤 HVN에 VPN 연결을 만들어요. 모든 트래픽을 비공개로 유지하고 클라이언트가 온프레미스에 있거나, HVN을 클라우드 제공자의 가상 네트워크에 피어링할 수 없는 위치에 있는 경우 유용해요.

• 기능 패리티: HCP Vault Dedicated로 마이그레이션하기 전에 제약 및 제한 사항을 검토해 주세요. 일부 기능은 특정 티어의 HCP Vault Dedicated가 필요해요.
• 클러스터 티어와 크기: 자체 관리 클러스터의 리소스 사용률과 클라이언트 수를 검토하고, 필요한 기능을 활성화하는 티어를 선택해 워크로드 요구에 맞게 크기를 조정해 주세요.

마이그레이션할 Vault 리소스

다음은 마이그레이션을 고려해야 할 리소스 목록이에요. 이 목록은 포괄적인 리소스 목록이 아니며 특정 Vault 구현에 크게 의존해요.

• 네임스페이스
• 인증 방법
• 역할/권한
• 시크릿 엔진
• 정적 시크릿
• 정책
• 암호화 키
• Terraform 프로바이더 마이그레이션

네임스페이스 마이그레이션

자체 관리 클러스터에 HVD 내에서 복제하고 싶은 네임스페이스 레이아웃이 있을 수 있어요. HVD를 사용할 때 모든 고객 데이터와 모든 하위 네임스페이스 구조는 admin 네임스페이스 안에 있어요.

이 스크립트는 원본 자체 관리 Vault와 동일한 네임스페이스 구조(모든 네임스페이스와 중첩 네임스페이스 포함)를 만들어요. 스크립트는 대상 HCP Vault Dedicated 클러스터의 admin 네임스페이스 아래에 네임스페이스를 만들어요.

네임스페이스 마이그레이션 예제 bash 스크립트:

#!/bin/bash
 
function namespace_loop() {
  local CURRENT="${1:-}"  # Empty = root
  local TOP_LEVEL
 
  TOP_LEVEL=$(vault namespace list ${CURRENT:+-namespace="$CURRENT"} -format=json 2>/dev/null | jq -r '.[]' | sed 's:/$::')
 
  for namespace in $TOP_LEVEL; do
    local FULL_SRC_PATH="${CURRENT:+$CURRENT/}$namespace"
    local DST_PARENT_PATH="admin${CURRENT:+/$CURRENT}"
 
    # Check if namespace already exists in HDV
    if VAULT_TOKEN=$HCP_VAULT_TOKEN vault namespace lookup \
        -address="$HCP_VAULT_ADDR" \
        -namespace="$DST_PARENT_PATH" "$namespace" &>/dev/null; then
    echo "Namespace already exists: $DST_PARENT_PATH/$namespace"
    else
    echo "Creating: $DST_PARENT_PATH/$namespace"
    VAULT_TOKEN=$HCP_VAULT_TOKEN vault namespace create \
        -address="$HCP_VAULT_ADDR" \
        -namespace="$DST_PARENT_PATH" "$namespace"
    fi
 
    # Recurse
    namespace_loop "$FULL_SRC_PATH"
  done
}
 
namespace_loop "$1"

인증 방법 (Auth methods)

특정 인증 방법 구성은 사용하는 방법에 따라 달라져요. 예를 들어 userpass 인증 방법은 OIDC 인증 방법보다 구성이 덜 필요해요. 자체 호스팅 클러스터를 관리할 때 사용하는 것과 동일한 도구로 HCP Vault Dedicated 구성을 관리할 수 있어요.

• Vault Terraform provider
• Vault CLI
• Vault API
• Vault UI

최신 정보는 HCP Vault Dedicated 제약 및 제한 사항을 참고해 주세요.

자체 관리 클러스터에서 활성화된 인증 방법을 관찰할 때, 인증 방법의 구성을 반환하는 사용 가능한 읽기 API 엔드포인트(AWS, Kubernetes, Okta가 예시)를 활용하는 것이 유용할 수 있어요.

Vault는 비밀번호, API 키, 인증서 같은 민감한 값을 반환하지 않아요. 읽기 API에서 가져온 구성과 원본 소스의 민감한 값으로 HCP Vault Dedicated에 인증 방법을 만들어야 해요.

다음 인증 방법은 HCP Vault Dedicated에서 검증됐어요.

시크릿 엔진

HCP Vault Dedicated에서 시크릿 엔진을 구현할 때 고려해야 할 몇 가지 사항이 있어요. 인증 방법과 마찬가지로 HCP Vault Dedicated 내에서 시크릿 엔진을 활성화하고 구성해야 해요. 시크릿 엔진은 /admin 네임스페이스에서 시작해요. HCP Vault Dedicated가 시크릿 엔진을 지원하는지 확인해 주세요.

자체 관리 클러스터에서 활성화된 시크릿 엔진을 나열하고 각각의 구성을 읽을 수 있어요(AWS, KV2, Databases). 시크릿 엔진 구성은 민감한 값이나 시크릿을 반환하지 않아요.

정적 시크릿 (Static secrets)

정적 시크릿을 Vault key/value (KV) 시크릿 엔진에 저장할 수 있어요. 자체 호스팅 Vault와 마찬가지로 HCP Vault Dedicated는 KV 시크릿 엔진의 버전 1과 버전 2를 모두 지원해요.

이 스크립트는 자체 관리 Vault에서 HCP Vault Dedicated로 kv 시크릿을 마이그레이션해요. 중첩 네임스페이스의 경우 모든 네임스페이스를 반복한 다음 적절한 네임스페이스 아래에서 migrate_kv_secrets_in_namespace 함수를 호출해요. KV 버전 1과 버전 2를 모두 지원해요.

정적 시크릿 마이그레이션 예제 bash 스크립트:

#!/bin/bash

# Required variables to be set in your terminal:
# export VAULT_TOKEN=<source>
# export HCP_VAULT_TOKEN=<destination>
# export HCP_VAULT_ADDR=https://vault.<region>.hcp.hashicorp.cloud:8200
 
# Migrates KV secrets from one namespace to HDV
function migrate_kv_secrets_in_namespace() {
  SRC_NAMESPACE="$1"
  DST_NAMESPACE="admin${SRC_NAMESPACE:+/$SRC_NAMESPACE}"
 
  echo "Migrating namespace: $SRC_NAMESPACE → $DST_NAMESPACE"
 
  # Check if destination namespace exists
  if [[ -n "$SRC_NAMESPACE" ]]; then
    DST_PARENT_PATH=$(dirname "$DST_NAMESPACE")
    DST_LEAF=$(basename "$DST_NAMESPACE")
 
    VAULT_TOKEN="$HCP_VAULT_TOKEN" vault namespace lookup \
    -address="$HCP_VAULT_ADDR" \
    -namespace="$DST_PARENT_PATH" "$DST_LEAF" &>/dev/null
 
    if [[ $? -ne 0 ]]; then
    echo "ERROR: Destination namespace $DST_NAMESPACE does not exist in HDV."
    return
    fi
  fi
 
  # Get KV mounts in this namespace
  kv_secrets=$(vault secrets list -namespace="$SRC_NAMESPACE" -format=json |
    jq -r 'to_entries[] | select(.value.type=="kv") | .key' | sed 's:/$::')
 
  for kv_mount in $kv_secrets; do
    echo "Mount: $kv_mount"
 
    # Detect KV version (default to 1)
    kv_version=$(vault secrets list -namespace="$SRC_NAMESPACE" -format=json |
    jq -r --arg path "$kv_mount/" '.[$path].options.version // "1"')
 
    # Check if mount already enabled on destination
    mount_exists=$(VAULT_TOKEN="$HCP_VAULT_TOKEN" vault secrets list -address="$HCP_VAULT_ADDR" -namespace="$DST_NAMESPACE" -format=json |
    jq -r --arg path "$kv_mount/" 'has($path)')
 
    if [[ "$mount_exists" == "true" ]]; then
    echo "Mount $kv_mount already enabled in destination. Skipping."
    else
    VAULT_TOKEN="$HCP_VAULT_TOKEN" vault secrets enable -address="$HCP_VAULT_ADDR" \
        -namespace="$DST_NAMESPACE" -version="$kv_version" -path="$kv_mount" kv
    fi
 
    # List secrets in mount
    keys=$(vault kv list -namespace="$SRC_NAMESPACE" -mount="$kv_mount" -format=json 2>/dev/null | jq -r '.[]' || true)
 
    # Set path for parsing kv data
    key_path=$([[ "$kv_version" == "2" ]] && echo ".data.data" || echo ".data")
 
    for key in $keys; do
    echo "Secret: $key"
 
    # Read the secret
    secret_json=$(vault kv get -namespace="$SRC_NAMESPACE" -mount="$kv_mount" -format=json "$key" 2>/dev/null)
 
    # Extract key-value pairs
    kv_pairs=""
    keys_inner=$(echo "$secret_json" | jq -r "$key_path | keys[]" || true)
 
    for inner_key in $keys_inner; do
        value=$(echo "$secret_json" | jq -r --arg k "$inner_key" "$key_path[\$k]")
        kv_pairs="$kv_pairs $inner_key=$value"
    done
 
    # Write to destination
    [[ -n "$kv_pairs" ]] && VAULT_TOKEN="$HCP_VAULT_TOKEN" vault kv put \
        -address="$HCP_VAULT_ADDR" \
        -namespace="$DST_NAMESPACE" \
        -mount="$kv_mount" \
        $key $kv_pairs && echo "Migrated $key"
    done
  done
}
 
# Recursively migrate all namespaces and their secrets
function recurse_and_migrate_namespaces() {
  local PARENT="$1"
  local CURRENT="${PARENT:-}"
 
  migrate_kv_secrets_in_namespace "$CURRENT"
 
  # List child namespaces
  namespaces=$(vault namespace list ${CURRENT:+-namespace="$CURRENT"} -format=json 2>/dev/null | jq -r '.[]' | sed 's:/$::')
 
  for ns in $namespaces; do
    recurse_and_migrate_namespaces "${CURRENT:+$CURRENT/}$ns"
  done
}

#  Start
recurse_and_migrate_namespaces

역할과 권한 (Roles and permissions)

HashiCorp Cloud Platform은 HCP 계정의 리소스 관리를 지원하기 위해 별도의 독립적인 아이덴티티 및 접근 관리 솔루션을 유지해요. HCP IAM 사용자와 역할은 Vault에서 관리되는 리소스에 대한 접근을 제공하지 않아요.

정책 (Policies)

자체 호스팅 Vault에 사용한 정책을 HCP Vault Dedicated로 마이그레이션할 수 있어요. 자체 호스팅 클러스터를 어떻게 구성했는지에 따라 기존 정책을 변경해야 할지가 달라져요.

root 네임스페이스에 정책을 만든 경우 admin 네임스페이스를 기준으로 새 네임스페이스 구조를 반영하도록 각 정책의 경로를 업데이트해야 해요.

같은 네임스페이스의 리소스에 대한 접근을 허용하는 정책을 하위 네임스페이스에 직접 만든 경우, 정책은 업데이트 없이도 동작해야 해요.

네임스페이스에서 정책을 관리하는 방법에 대한 자세한 내용은 Vault 네임스페이스로 테넌트 관리 튜토리얼을 참고해 주세요.

이 스크립트는 자체 호스팅 Vault 정책을 반복하며 HCP Vault Dedicated 내에서 만들어요. 중첩 네임스페이스의 경우 스크립트는 네임스페이스를 반복한 다음 적절한 네임스페이스 아래에서 migrate_policies_in_namespace 함수를 호출해요.

자체 관리 클러스터에서 실행할 예제 bash 스크립트:

#!/bin/bash

# Required variables to be set in your terminal:
# export VAULT_TOKEN=<source_vault_token>
# export HCP_VAULT_TOKEN=<destination_token>
# export HCP_VAULT_ADDR=https://vault.<region>.hcp.hashicorp.cloud:8200
 
# Migrate policies from one namespace to the mapped HCP namespace
function migrate_policies_in_namespace() {
  local SRC_NAMESPACE="$1"
  local DST_NAMESPACE="admin${SRC_NAMESPACE:+/$SRC_NAMESPACE}"
 
  echo "Migrating policies from: '${SRC_NAMESPACE:-root}' → '$DST_NAMESPACE'"
 
  # If not root, check that destination namespace exists in HCP
  if [[ -n "$SRC_NAMESPACE" ]]; then
    ns_check=$(VAULT_TOKEN="$HCP_VAULT_TOKEN" vault namespace list \
    -address="$HCP_VAULT_ADDR" \
    -namespace="$(dirname "$DST_NAMESPACE")" \
    -format=json 2>/dev/null)
 
    if ! echo "$ns_check" | jq -e --arg ns "$(basename "$DST_NAMESPACE")/" '.[] | select(. == $ns)' >/dev/null; then
    echo "Destination namespace '$DST_NAMESPACE' does not exist in HDV."
    echo "Exiting policy migration."
    exit 1
    fi
  fi
 
  local policy_names
  policy_names=$(vault policy list ${SRC_NAMESPACE:+-namespace="$SRC_NAMESPACE"} 2>/dev/null)
 
  for name in $policy_names; do
    # Skip the root policy (not allowed in HDV)
    if [ "$name" == "root" ]; then
    echo "Skipping 'root' policy (cannot be migrated)"
    continue
    fi
 
    echo "Migrating policy: $name"
 
    local policy_content
    policy_content=$(vault policy read ${SRC_NAMESPACE:+-namespace="$SRC_NAMESPACE"} "$name")
 
    VAULT_TOKEN="$HCP_VAULT_TOKEN" vault policy write \
    -address="$HCP_VAULT_ADDR" \
    -namespace="$DST_NAMESPACE" \
    "$name" - <<< "$policy_content"
 
    echo "Policy '$name' migrated to $DST_NAMESPACE"
  done
}
 
# Recursively walk namespaces and migrate policies
function recurse_and_migrate_policies() {
  local PARENT="$1"
  local CURRENT="${PARENT:-}"
 
  migrate_policies_in_namespace "$CURRENT"
 
  local namespaces
  namespaces=$(vault namespace list ${CURRENT:+-namespace="$CURRENT"} -format=json 2>/dev/null | jq -r '.[]' | sed 's:/$::')
 
  for ns in $namespaces; do
    recurse_and_migrate_policies "${CURRENT:+$CURRENT/}$ns"
  done
}

# Start recursion from the root namespace
recurse_and_migrate_policies

암호화 transit 키 (Cryptographic transit keys)

export 기능을 사용해 대부분의 키를 마이그레이션할 수 있어요. 키를 내보낼 수 있게(exportable) 만든 뒤에는 원본 클러스터에서 그 작업을 되돌릴 수 없어요.

보안 고려 사항

보안 정책이 내보낼 수 있는 키를 금지한다면, 마이그레이션을 위해 키를 내보낼 수 있도록 표시하는 것을 고려해 주세요. 키를 HCP Vault Dedicated로 가져올 때 allow_rotation=true를 설정하되 exportable=true는 설정하지 마세요.

키에 의존하는 모든 애플리케이션을 온보딩하고 테스트한 후 키를 회전(rotate)해 주세요.

이 스크립트는 각 transit 키에 대해 실행돼요. 스크립트는 키를 내보낼 수 있게 만들고, 키를 백업하고, 새 transit 시크릿 엔진을 활성화하고, 키를 HCP Vault Dedicated에서 복원해요.

모든 키를 가져와 구성 업데이트 및 백업 저장용 예제 bash 스크립트:

#!/bin/bash
 
# Migrate all transit keys from a given source namespace to corresponding admin/<namespace> in HCP
function migrate_transit_keys_in_namespace() {
  local SRC_NAMESPACE="$1"
  local DST_NAMESPACE="admin${SRC_NAMESPACE:+/$SRC_NAMESPACE}"
 
  echo "Migrating transit keys from: '${SRC_NAMESPACE:-root}' → '$DST_NAMESPACE'"
 
  # List transit keys in this namespace
  local keys
  keys=$(vault list -format=json ${SRC_NAMESPACE:+-namespace="$SRC_NAMESPACE"} transit/keys 2>/dev/null | jq -r '.[]')
 
  for key in $keys; do
    echo "Processing key: $key"
 
    # Make the source key exportable
    vault write ${SRC_NAMESPACE:+-namespace="$SRC_NAMESPACE"} transit/keys/"$key"/config allow_plaintext_backup=true exportable=true
 
    # Read the backup from the source
    local backup
    backup=$(vault read -format=json ${SRC_NAMESPACE:+-namespace="$SRC_NAMESPACE"} transit/backup/"$key" 2>/dev/null | jq -r '.data.backup')
 
    if [ -z "$backup" ]; then
    echo "Skipping: Key '$key' not exportable or backup failed"
    continue
    fi
 
    # Enable transit engine on destination if not already enabled (suppress error)
    VAULT_TOKEN="$HCP_VAULT_TOKEN" vault secrets enable -address="$HCP_VAULT_ADDR" -namespace="$DST_NAMESPACE" transit 2>/dev/null || true
 
    # Restore the key to the destination Vault
    VAULT_TOKEN="$HCP_VAULT_TOKEN" vault write -address="$HCP_VAULT_ADDR" -namespace="$DST_NAMESPACE" transit/restore backup="$backup"
 
    echo "Migrated: $key → $DST_NAMESPACE"
  done
}
 
# Recursively walk through namespaces and migrate transit keys
function recurse_and_migrate_transit_keys() {
  local PARENT="$1"
  local CURRENT="${PARENT:-}"
 
  migrate_transit_keys_in_namespace "$CURRENT"
 
  local namespaces
  namespaces=$(vault namespace list ${CURRENT:+-namespace="$CURRENT"} -format=json 2>/dev/null | jq -r '.[]' | sed 's:/$::')
 
  for ns in $namespaces; do
    recurse_and_migrate_transit_keys "${CURRENT:+$CURRENT/}$ns"
  done
}
 
# Pre-requisites
# export VAULT_TOKEN=<source_vault_token>
# export HCP_VAULT_TOKEN=<destination_token>
# export HCP_VAULT_ADDR=https://vault.<region>.hcp.hashicorp.cloud:8200
 
# Start the recursion from root namespace
recurse_and_migrate_transit_keys

키를 내보낼 수 있게 만들고 싶지 않다면 HCP Vault Dedicated에서 새 키를 만들어 주세요.

Terraform 프로바이더 마이그레이션

Vault Terraform provider를 사용해 자체 관리 Vault 클러스터를 관리·배포한다면, 기존 구성을 HCP Vault Dedicated에서 동작하도록 업데이트할 수 있어요.

Terraform 구성 업데이트와 관련된 구성 변경량은 Vault 구성에 따라 달라져요.

HCP Vault Dedicated 클러스터 URL, 토큰, /admin 네임스페이스를 사용해 HCP Vault Dedicated 엔드포인트로 전환해 주세요.

Terraform은 HCP Vault Dedicated 클러스터에 연결할 수 있는 위치에서 실행해야 해요. HCP Vault Dedicated 클러스터가 공개(public)라면 공개 URL을 사용해 주세요. 클러스터가 비공개라면 활성 피어링, 전송 게이트웨이, 또는 VPN 연결이 있는 연결된 환경에서 Terraform을 실행해 주세요.

그런 다음 일반적인 Terraform 워크플로처럼 terraform init, terraform plan, terraform apply를 실행하면 돼요.

자세한 내용은 코드화된 구성으로 HCP Vault Dedicated 마이그레이션하기 튜토리얼을 참고해 주세요.

마이그레이션 후 (Post migration)

마이그레이션을 완료한 후에는 시크릿 엔진, 인증 방법 같은 Vault 리소스가 예상대로 동작하는지 검증해 주세요. 보고된 문제를 모니터링하고 핵심 이해 관계자로부터 피드백을 계속 수집하는 지속적 개선 프로그램 구현을 고려해 주세요. 새 문제가 발생하면 필요에 따라 Vault 구성을 업데이트해 주세요.

모든 워크로드를 HCP Vault Dedicated로 마이그레이션한 후에는 관련 문서, 구성 관리 데이터베이스(CMDB), 운영 런북을 업데이트해 Vault 아키텍처의 변경 사항을 반영해 주세요.

모니터링·알림 구성을 업데이트해 새 HCP Vault Dedicated 환경과 일치하는지 확인해 주세요.

요약

자체 관리 Vault 클러스터에서 HCP Vault Dedicated 같은 관리형 플랫폼으로 마이그레이션할 때 고려할 사항이 여러 가지 있어요. 대부분의 마이그레이션 전략은 마이그레이션 도구가 없는 상황에서 마이그레이션 단계를 수동으로 수행해야 해요. 또한 수동 마이그레이션은 마이그레이션해야 할 리소스를 복제하거나, 오버헤드가 다양한 리소스를 전환하는 작업을 포함해요.

HCP Vault Dedicated에 대한 자세한 내용은 Documentation과 Learn Tutorials를 확인해 주세요.

더 알아보기 (Learn more)

• 제약 및 제한 사항 문서에서 마이그레이션 전 확인할 사항을 살펴볼 수 있어요.
• 티어와 기능 비교 문서에서 적절한 티어·크기를 고르는 방법을 배워 보세요.
• HCP Vault Dedicated 권한 문서에서 HCP IAM과 Vault 권한의 차이를 확인해 보세요.