devops/ETC

Hashcorp Vault with a simple demo

gepp 2024. 6. 23. 17:21

Vault Overview

HashiCorp Vault는 API 기반의 클라우드에 종속되지 않는 비밀 관리 시스템입니다.

하이브리드 클라우드 환경에서 민감한 데이터를 안전하게 저장하고 관리할 수 있습니다.

또한 Vault를 사용하여 동적 단기 자격 증명 (credentials)을 생성하거나 애플리케이션 데이터를 즉석에서 암호화할 수 있습니다.

Vault는 SaaS (HCP)와 설치 모델 두가지를 제공합니다.



Vault License

Vault 라이센스 종류는 OSS와 Enterprise 로 나누어져 있습니다.

 

엔터프라이즈 라이센스의 주요 기능

엔터프라이즈 라이센스의 주요 기능은 다음과 같습니다.

네임스페이스

  • 하나의 Vault 시스템에 또 다른 Vault 시스템을 구성하여, 서로 격리된 정책, ID&PW, 보안데이터를 관리
  • 보안, 규정 준수를 위한 멀티 테넌트 환경
  • 격리된 Vault 시스템 별 규정 준수 시행
 

MFA

  • Vault는 다양한 인증 유형을 사용하여 MFA를 지원하며, TOTP (Time-based one-time password)를 제공
  • Vault TOTP 암호화 토큰을 조합하여 유사한 TOTP 유틸리티를 활용
  • Okta, Duo, PingID 인증 유형 사용
 

DR

  • 주센터와 DR센터에 Vault 시스템을 구성하여, 통합된 보안데이터를 복제
  • 센터간의 복제는 네트워크로 수행
  • Async 방식으로 복제되며, 주기적으로 데이터 동기화 진행
 

성능 복제 (Performance Replication)

  • Vault는 보안 데이터의 고도화된 이중화 환경을 위해 멀티 데이터 센터 복제 방식을 제공
  • 다중 데이터센터 복제 - 1 : N 제공
  • 복제되는 모든 Vault 시스템은 중앙에서 통합하여 관리
 

복제 필터

  • 서로 다른 클러스터 간 복제 대상과, 복제가 되지 않아야 하는 대상을 설정하여, 복제 성능을 향상
  • 복제 대상을 Path를 등록하여 설정
  • 복제를 하지 않는 대상을 Path로 등록하여 설정
 

리드 리플리카 (Read Replicas)

  • Vault 클러스터의 Active 서버는 Read/Write를 수행하고, 나머지 서버에서 Read 수행
  • Read I/O 분산 처리로 고성능 제공
  • Vault 서버 장애 시에도 남은 서버로 서비스가 되는 무중단 운영 환경
 

Sentinel Integration

  • 비밀 정보는 Path로 구성되며, Path 마다 RBAC를 설정하여, 고도화된 보안 환경 구축
  • 비밀 정보 Path 마다, create, read, write, update, delete중 필요한  정책 적용
  • 세밀한 보안 정책 적용 가능
 

임대 카운트 쿼터 (Lease Count Quotas)

  • 시스템 안정성 및 대규모 스토리지 성능을 보호하기 위해 생성 된 키들의 수를 제한
  • 비밀 정보 Path 마다 생성될 수 있는 키의 수를 제안 (Quota)
  • 필요 이상으로 생성된 불필요한 키 관리
 

Vault 를 사용하면 좋은 점

  • 하드코딩된 자격증명 보안 이슈 및 수동관리의 어려움을 대체할 수 있다.
    • 네트워크 경계 전반에 걸쳐 보안을 확장할 수 있는 ID 기반 규칙출처를 유지하기 위한 개별 계정
    • 쉽게 무효화될 수 있는 자격 증명 (credentials) 및 엔터티(Entities)
    • 자주 교체되는 동적 단기 자격 증명
  • 많은 시스템에 대해 사용자와 응용 프로그램을 인증할 수 있도록 지원한다.

 

 

 


사용법

  • Vault 는 CLI 를 제공하며 보안 읽기, 쓰기 등 수행할 수 있습니다.
  • Vault 서버는 두 가지 모드로 실행할 수 있습니다.
    • "Dev" mode : 개발 목적으로 만 사용
      • 유의할 점: 볼트의 데브 모드는 안전하지 않습니다.Vault는 자동으로 봉인 해제됩니다."Dev" 모드에서 실행되는 서버에 실제 비밀을 저장하지 마십시오.
      • 루트 토큰은 시작하기 전에 지정할 수 있습니다.
      • 메모리에 모든 것을 저장합니다.
    • "Prod" mode : QA와 운영 목적으로 사용
      • "Prod" 모드에서 Vault 서버를 실행하려면 여러 단계를 거쳐야 합니다.
        1. Config file에서 구성을 지정합니다.
        2. 서버를 시작합니다.
        3. Unseal keys와 initial root token을 얻기 위해 서버를 초기화합니다.
        4. Unseal keys로 Vault 서버의 봉인을 해제합니다.
  • Vault 는 Vault UI 가 지원됩니다.
    • UI를 사용하려면 처음에 로그인을 해야합니다.
    • 새 Vault 서버는 처음에 토큰 인증 방법만 활성화됩니다.
    • 토큰 인증 방법을 사용하고 ”root"를 토큰으로 지정하는 방법이 있습니다.
  • Vault 는 Vault API를 제공합니다.
    • JSON 출력 형식을 지정하기 위해 jq가 뒤에 오는 간단한 curl 명령어를 사용하여 Vault의 상태를 확인할 수 있습니다.
    • Command 예: curl http://localhost:8200/v1/sys/health | jq
# Result
{
  "initialized": true,
  "sealed": false,
  "standby": false,
  "performance_standby": false,
  "replication_performance_mode": "disabled",
  "replication_dr_mode": "disabled",
  "server_time_utc": 1655600004,
  "version": "1.10.4+ent",
  "cluster_name": "vault-cluster-92ffexxx",
  "cluster_id": "3522f7f4-a977-9547-2cf2-xxxxxxxxxx",
  "last_wal": 61334,
  "license": {
    "state": "autoloaded",
    "expiry_time": "2023-06-10T23:59:59Z",
    "terminated": false
  }
}

 

 

Vault API 인증은 X-Vault-Token 헤더와 함께 Vault 토큰으로 수행됩니다.

 

 

  • 볼트 컨피그를 구성하고 프로덕션 서버 시작하기
    • "Prod" 모드에서 Vault 서버를 실행하려면 여러 단계를 거쳐야 합니다.
      • Vault configuration files 은 HCL 또는 JSON으로 지정할 수 있습니다.
      • listener
      • seal
      • uicluster_addr
      • api_addr
      • log_level
      • storage
    •  일반적인 구성 설정은 다음과 같습니다.
      • 서버를 시작합니다.
      • Unseal keys와 initial root token을 얻기 위해 서버를 초기화합니다.
      • Unseal keys로 Vault 서버의 봉인을 해제합니다.
      • -dev 옵션 없이 vault server 명령어로 Production 서버를 시작합니다.
    • Config file에서 구성을 지정합니다.
  • 볼트 클러스터 초기화하기
    • Vault 클러스터는 여러 Vault 서버를 실행하여 구성합니다.이는 Vault의 vault operator init 으로 수행됩니다.이 명령은 클러스터에 대한 unseal keys와 initial root token을 반환합니다.
    • 키 공유 수와 키 임계값은 –key-shares 및 key-threshold 옵션을 사용하여 지정할 수 있습니다.
    • 각 Vault 클러스터는 한 번 초기화해야 합니다.
    • 각 Vault 서버는 시작할 때마다 봉인(Seal)을 해제해야 합니다.이는 클러스터를 초기화할 때 반환된 unseal keys를 사용하여
      vault operator unseal 명령어로 수행됩니다.
    • 봉인을 해제할 때까지 서버를 사용할 수 없습니다.
    • vault status 명령어로 상태 확인 가능하며 봉인 되었는지 아닌지 확인 가능합니다.
$ vault status
WARNING! VAULT_ADDR and -address unset. Defaulting to https://127.0.0.1:8200.
Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": http: server gave HTTP response to HTTPS client
$ export VAULT_ADDR='http://127.0.0.1:8200' # no tls for this test demo
$ vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.17.0
Build Date      2024-06-10T10:11:34Z
Storage Type    inmem
Cluster Name    vault-cluster-445bxxxx
Cluster ID      6748b197-b91c-89a2-36f3-a78cxxxxxxxx
HA Enabled      false

 

 

  • 볼트 시크릿 엔진
    • 대부분의 Vault 비밀 엔진은 명시적으로 활성화해야 합니다.각 비밀 엔진에는 기본 경로가 있습니다.그러면 CLI 명령 및 API 호출에서 사용자 지정 경로를 지정해야 합니다.
      vault write aws/config/root  대신 vault write aws-east/config/root
    • 여러 인스턴스를 활성화하기 위해 대체 경로(path)를 지정할 수 있습니다.
      vault secrets enable -path=aws-east aws
    • vault secrets enable 명령어로 수행됩니다.
    • 볼트 엔진 버전은 현재 두가지가 있습니다.
      • KV v1(버전 관리 없음)
      • KV v2(버전 관리 포함)
      • Dev mode는 Vault 서버에 대해 KV v2 엔진의 인스턴스가 자동으로 활성화됩니다.
      • Vault는 "Prod" mode 서버에서 KV 시크릿 엔진의 인스턴스를 자동으로 활성화하지 않습니다. 따라서 직접 활성화해야 합니다.
      • 기본 경로 kv에 KV v2 secrets 엔진의 인스턴스를 마운트하는 방법
        vault secrets enable -version=2 kv
        • vault kv list는 지정된 경로에 있는 보안 비밀을 나열합니다.vault kv get은 지정된 경로에서 보안 비밀을 읽습니다.
        • vault kv delete는 지정된 경로에서 보안 비밀을 삭제합니다.
        • vault kv put은 지정된 경로에 보안 비밀을 작성합니다.
 

볼트 인증

  • 볼트 인증 방법은 유저, 어플리케이션 대상 두가지로 나눠져 있습니다.
    • Methods for UsersGitHubJWT/OIDC
    • Okta
    • LDAP
    • Userpass
    • Methods for ApplicationsAWSGoogle Cloud
    • Kubernetes
    • Azure
    • AppRole
  • 대부분의 Vault 인증 방법은 명시적으로 활성화해야 합니다.각 인증 방법에는 기본 경로가 있습니다.CLI 명령 및 API 호출에서 사용자 지정 경로를 지정해야 합니다.
    vault write aws/config/root 대신 vault write aws-east/config/root
  • 여러 인스턴스를 활성화하기 위해 대체 경로를 지정할 수 있습니다.
    vault auth enable -path=aws-east aws
  • 이는 vault auth enable 명령어로 수행됩니다.

볼트 정책(Policy)

  • Vault Policies는 사용자와 애플리케이션이 액세스할 수 있는 secrets (비밀) 을 제한합니다.
  • Vault는 기본적으로 액세스를 거부하는 최소 권한 관행을 따릅니다.
  • Vault 관리자는 정책 설명을 사용하여 특정 경로에 대한 사용자 및 애플리케이션 액세스 권한을 명시적으로 부여해야 합니다.
  • 경로를 지정하는 것 외에도 정책은 해당 경로에 대한 기능 집합도 지정합니다.
  • Policies 는 HashiCorpConfiguration Language (HCL)로 작성됩니다.
    • 예시:
# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
capabilities = ["read"]
}

 

정책 경로는 Vault API 경로에 매핑됩니다.

Vault의 CLI, UI 또는 API를 사용하여 Vault 서버에 Vault 정책을 추가할 수 있습니다.

CLI로 정책을 추가하는 명령어는 vault policy write 입니다

정책을 생성하고 사용자와 연결하는 예시:

 

vault policy write lob-A-dept-1 lob-A- dept-1-policy.hcl
vault write auth/userpass/users/joe/policies Policies=lob-A-dept-1

사용법

먼저 볼트를 ec2 linux 에 설치해 봅니다.

sudo yum install -y yum-utils
# Add repo
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
# Install Vault
sudo yum -y install vault
Installed:
  vault-1.17.0-1.aarch64                                                                                                                             

Complete!
$ vault version
Vault v1.17.0 (72850df1bc10581b74ba5f0f7b373xxxxxxx), built 2024-06-10T10:11:34Z

간단한 테스트를 위해, dev mode를 활성화하여 볼트를 시작합니다.

$ vault server -dev
==> Vault server configuration:

Administrative Namespace: 
             Api Address: http://127.0.0.1:8200
                     Cgo: disabled
         Cluster Address: https://127.0.0.1:8201
   Environment Variables: BASH_FUNC_which%%, DBUS_SESSION_BUS_ADDRESS, GOTRACEBACK, HISTCONTROL, HISTSIZE, HOME, HOSTNAME, LANG, LESSOPEN, LOGNAME, LS_COLORS, MAIL, MOTD_SHOWN, NVM_BIN, NVM_CD_FLAGS, NVM_DIR, NVM_INC, NVM_RC_VERSION, OLDPWD, PATH, PWD, SELINUX_LEVEL_REQUESTED, SELINUX_ROLE_REQUESTED, SELINUX_USE_CURRENT_RANGE, SHELL, SHLVL, SSH_CLIENT, SSH_CONNECTION, SSH_TTY, SYSTEMD_COLORS, S_COLORS, TERM, USER, XDG_RUNTIME_DIR, XDG_SESSION_CLASS, XDG_SESSION_ID, XDG_SESSION_TYPE, _, which_declare
              Go Version: go1.22.4
              Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", disable_request_limiter: "false", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
               Log Level: 
                   Mlock: supported: true, enabled: false
           Recovery Mode: false
                 Storage: inmem
                 Version: Vault v1.17.0, built 2024-06-10T10:11:34Z
             Version Sha: 72850df1bc10581b74ba5f0f7b3xxxxxxxx

==> Vault server started! Log data will stream in below:
...
WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.

You may need to set the following environment variables:

    $ export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.

Unseal Key: lS0Xa99RlRkP/g2reElBKYhnJggXcOtxxxxxxxxx
Root Token: hvs.EI1TksGnXihdxxxxxxxx

Development mode should NOT be used in production installations!

 

 

볼트 서버 상태를 확인합니다.

$ export VAULT_ADDR='http://127.0.0.1:8200'
$ vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.17.0
Build Date      2024-06-10T10:11:34Z
Storage Type    inmem
Cluster Name    vault-cluster-44xxxxx
Cluster ID      6748b197-b91c-89a2-36f3-axxxxxxxx
HA Enabled      false

 

 

key value 로 시크릿을 생성하기 위해 kv 명령어를 실행합니다.

$ vault kv put -mount=secret hello team=banana
== Secret Path ==
secret/data/hello

======= Metadata =======
Key                Value
---                -----
created_time       2024-06-23T06:53:49.203123729Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

 

 

dev 모드로 볼트 서버를 시작한 경우, 기본 Mount path은 자동으로 생성됩니다.

data hello가 secret/data/hello 로 key value 로 마운트 되었습니다.

kv put으로 여러 key value를 입력할 수 있습니다.

$ vault kv put -mount=secret hello team=banana homework=yes
== Secret Path ==
secret/data/hello

======= Metadata =======
Key                Value
---                -----
created_time       2024-06-23T06:57:10.424550787Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            2

이제 시크릿을 get 으로 읽어봅니다.

$ vault kv get -mount=secret hello
== Secret Path ==
secret/data/hello

======= Metadata =======
Key                Value
---                -----
created_time       2024-06-23T06:57:10.424550787Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            2

====== Data ======
Key         Value
---         -----
homework    yes
team        banana

특정 키의 value 값만 읽습니다. 옵션과 명령어 넣을때 순서를 인식합니다.

$ vault kv get -mount=secret hello -field=homework
Command flags must be provided before positional arguments. The following arguments will not be parsed as flags: [-field=homework]
Too many arguments (expected 1, got 2)
$ vault kv get -mount=secret -field=homework hello
yes

 

 

이제 AWS 엔진을 활성화 하고 동적 AWS 시크릿을 생성해 봅니다.

동적 비밀은 액세스할 때 생성됩니다. 동적 시크릿은 읽을 때까지 존재하지 않으므로 누군가가 이를 훔치거나 동일한 비밀을 사용하는 다른 클라이언트가 발생할 위험이 없습니다.

Vault에는 취소 메커니즘이 내장되어 있으므로 동적 시크릿은 사용 후 즉시 취소되어 비밀이 존재하는 시간을 최소화할 수 있습니다.

일단 aws 엔진을 다음 명령어로 활성화합니다.

$ vault secrets enable -path=aws aws
Success! Enabled the aws secrets engine at: aws/

 

 

이제 AWS 시크릿 엔진을 구성해봅니다.

참고로 STS 페더레이션 토큰을 사용하려는 경우 IAM 역할 자격 증명으로 볼트를 인증할 수 없습니다.

역할과 연결된 임시 보안 자격 증명에는 GetFederationToken을 사용할 권한이 없기 때문입니다.

대안으로 identity token audience 를 사용하는 방법이 있는데 무료 커뮤니티 버전은 지원이 안됩니다.

$ vault write aws/config/root \
    identity_token_audience="http://127.0.0.1:8200" \
    role_arn="arn:aws:iam::539666729110:role/gepp-demo01-ssm-assume-ec2-role"
Error writing data to aws/config/root: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/aws/config/root
Code: 400. Errors:

* failed to generate plugin identity token: plugin workload identity not supported in Vault community edition

 

 

export 한 access key value를 써서 구성해봅니다.

$ vault write aws/config/root \
    access_key=$AWS_ACCESS_KEY_ID \
    secret_key=$AWS_SECRET_ACCESS_KEY \
    region=ap-southeast-1
Success! Data written to: aws/config/root

이제 IAM Role을 생성해봅니다. 크레덴셜이 가리키는 유저가 수행할 역할이며 ec2 에 대한 권한을 주었습니다.

$ vault write aws/roles/gepp-vault-demo-test-role \
        credential_type=iam_user \
        policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
EOF
Success! Data written to: aws/roles/gepp-vault-demo-test-role

 

확인해 봅니다.

 

 

암호화된 access_key, secret_key 정보가 확인됩니다. (실제값과 다른 암호화된 값, 아래는 추가 보안을 위해 임의 스트링 집어넣음)

$ vault read aws/creds/gepp-vault-demo-test-role
Key                Value
---                -----
lease_id           aws/creds/gepp-vault-demo-test-role/mOw57QlxKdPeZvZAdlxxxxx
lease_duration     768h
lease_renewable    true
access_key         AKIXABCDABxxxxxxx
secret_key         ARABCDABCDABCDABxxxxxxxxx
session_token      <nil>

이제 액세스 및 비밀 키를 사용하여 AWS 내에서 EC2 작업을 수행할 수 있습니다.

이 키는 위에서 말했듯이 새로운 값이며 이전에 입력한 키가 아닙니다.

명령을 두 번째로 실행하면 또 달라진 새 액세스 키 쌍을 얻게 됩니다.

aws/creds/:name에서 읽을 때마다 Vault는 AWS에 연결하고 새로운 IAM 사용자 및 키 쌍을 생성합니다.

해당 access key로 다시 aws credential 을 export 하고 aws cli를 날리면 자원이 생성됩니다.

즉 실제 값이 아닌 시크릿 값으로 사용할 수 있습니다.

실제로 볼트 시크릿 값으로 명령을 실행해 봅니다.

$ vault read aws/creds/gepp-vault-demo-test-role
Key                Value
---                -----
lease_id           aws/creds/gepp-vault-demo-test-role/HqC1JKt1F48xvzMrAxxxxxx
lease_duration     768h
lease_renewable    true
access_key         AKIAX3JVEZCXXXXXXX // <- 임의로 X 로 가림
secret_key         oBQHHrE+wfTd6LTQa+80UV7LiHHpdXXXXXXXXXX 
session_token      <nil>
$ export AWS_ACCESS_KEY_ID=AKIAX3JVEZCLXXXXXXX
$ export AWS_SECRET_ACCESS_KEY=oBQHHrE+wfTd6LTQa+80UV7LiHHpd7gXXXXXXXX
$ aws ec2 run-instances \
> --image-id ami-001f48902dxxxxx \
> --count 1 \
> --key-name gepp-demo01-key \
> --subnet-id subnet-0aedd5xxxxxxx \
> --security-group-ids sg-024ebxxxxxxxx \
> --instance-type t4g.nano
{
    "Groups": [],
    "Instances": [
        {
            "AmiLaunchIndex": 0,
            "ImageId": "ami-001f489xxxxxxxxx",
            "InstanceId": "i-0b00d5xxxxxxxxx",
            "InstanceType": "t4g.nano",
            "KeyName": "gepp-demo01-key",
            "LaunchTime": "2024-06-23T07:45:52+00:00",
            "Monitoring": {
                "State": "disabled"
            },
            "Placement": {
                "AvailabilityZone": "ap-southeast-1a",
                "GroupName": "",
                "Tenancy": "default"
            },
            "PrivateDnsName": "ip-192-168-0-xx.ap-southeast-1.compute.internal",
            "PrivateIpAddress": "192.168.0.xx",
            "ProductCodes": [],
            "PublicDnsName": "",
            "State": {
                "Code": 0,
                "Name": "pending"
            },
 

출력에 있는 이 Lease_id 값의 전체 경로를 복사해서 갱신, 해지 및 검사에 사용할 수 있습니다.

시크릿 철회(Revoke)하기

Vault는 768시간 후에 이 사용자 인증 정보를 자동으로 취소하지만(출력의 lease_duration 참조)

조기에 취소하고 싶은 경우,

시크릿을 취소하려면 실행 시 볼트 읽기에서 출력된 임대 ID와 함께 볼트 임대 취소를 수행하면 됩니다.

비밀이 취소되면 해당 시크릿의 액세스 키는 더 이상 유효하지 않습니다.

$ vault lease revoke aws/creds/gepp-vault-demo-test-role/mOw57QlxKdPeZvZAdlxxxxxx
All revocation operations queued successfully!

# 서버 로그
2024-06-23T16:33:59.115+0900 [INFO]  expiration: revoked lease: lease_id=aws/creds/gepp-vault-demo-test-role/mOw57QlxKdPeZvZAdlxxxxx

위의 취소했던 시크릿의 액세스키 값으로 export 하고 ec2를 다시 생성해봅니다.

임대 취소된 값:

Key                Value

---                -----

lease_id           aws/creds/cnp-soyip-vault-demo-test-role/mOw57QlxKdPeZvZxxxxx
lease_duration     768h
lease_renewable    true
access_key         AKIAX3JVEZCLNXXXX. // ← export
secret_key         ARVWzrUjYCIcnF/WZFnRAiWrOML+mh6vPXXXXXX
session_token      <nil>

$ export AWS_ACCESS_KEY_ID=AKIAX3JVEZCLNPU6XXXX
$ export AWS_SECRET_ACCESS_KEY=ARVWzrUjYCIcnF/WZFnRAiWrOML+mh6vPH7XXXXX
$ aws ec2 run-instances --image-id ami-001f48902dca0ecb9 --count 1 --key-name cnp-soyip-bastion01-key --subnet-id subnet-0aedd591757a7ea1f --security-group-ids sg-024eb29d41a2d037e --instance-type t4g.nano

An error occurred (AuthFailure) when calling the RunInstances operation: AWS was not able to validate the provided access credentials

// 임대 취소되어 해당값으로 생성 불가

이외 참고 문서

Vault pricing: https://www.hashicorp.com/products/vault/pricing

Vault Tutorial: https://developer.hashicorp.com/vault/tutorials/getting-started/getting-started-intro

Vault AWS cred: https://developer.hashicorp.com/vault/docs/secrets/aws#assumed_role