Vault 튜토리얼 시작하기

Vault 서버를 시작하면 Unseal Key 및 Root Token 값이 표시됩니다. 개발 서버는 모든 데이터를 메로리에 저장하고(여전히 암호화됨) TLS 없이 로컬호스트에서 수신하여 자동으로 봉인을 해제하고 봉인 해제 키와 루트 액세스 키를 표시합니다.

vault server -dev

export VAULT_ADDR='http://127.0.0.1:8200'
Unseal Key: W5UW/XHwg26bGO8h8H5lgNCE7KUfP9SQ5q2PzSVrWio=
Root Token: hvs.s9ETk2Eu2DbKarORfD9owLyf

TLS가 활성화된 Vault 개발 서버를 실핼하려면 -dev 대신 -dev-tls 플래그 사용

vault server -dev-tls

127.0.0.1:8200 이동

Vault 서버 상태 확인, export VAULT_ADDR을 해야 서버 상태를 확인할 수 있습니다.

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

vault status

개발 모드에서 Vault를 실행할 때 key/value v2 secrets 엔진이 secret/path에서 활성화됩니다. 키/값 Secret Engine은 Vault용으로 구성된 물리적 스토리지 내에 임의의 비밀을 저장하는 데 사용되는 일반 키-값 저장소이며 Vault에 기록된 secret은 암호화된 다음 백엔드 스토리지에 기록됩니다. 따라서 백엔드 스토리지 메커니즘은 암호화되지 않은 값을 볼 수 없으며 Vault 없이는 해독하는 데 필요한 수단이 없습니다.

Key/Value Secret Engine인 secret의 hello 하위 폴더에 key, vaule 값 저장

vault kv put -mount=secret hello foo=world
vault kv put -mount=[씨크릿 엔진명] [하위 폴더 구조] [키]=[값]

secret의 hello 하위 폴더에 key 값 foo와 excited 저장

vault kv put -mount=secret hello foo=world excited=yes
vault kv put -mount=[씨크릿 엔진명] [하위 폴더 구조] [키1]=[값1] [키2]=[값2]

======= Metadata =======
Key                Value
---                -----
created_time       2022-01-15T01:40:09.888293Z
custom_metadata    <nil>
deletion_time      2022-01-15T01:40:41.786995Z
destroyed          false
version            2        --> 버전 변경 확인

secret/hello 정보 조회

vault kv get -mount=secret hello

특정 필드 값 조회

vault kv get -mount=[씨크릿 엔진명] -field=[키] [하위 폴더]
vault kv get -mount=secret -field=excited hello
vault kv get -mount=secret -format=json hello | jq -r .data.data.excited

secret 삭제

vault kv delete -mount=secret hello

deletion_time 확인

vault kv get -mount=secret hello

출력에는 삭제 시간이 포함된 메타데이터만 표시되며 일단 삭제되면 데이터 자체를 표시하지 않습니다.

데이터 복구

vault kv undelete -mount=secret -versions=2 hello
vault kv undelete -mount=[씨크릿 엔진명] -versions=[버전] [복구하려는 하위 폴더]

데이터 복구 확인

vault kv get -mount=secret hello

Secret Engine은 secret을 저장, 생성 또는 암호화하는 Vault 구성 요소입니다. 위 실습에서는 키/값 v2 Secret Engine을 사용하여 데이터를 저장했습니다. 키/값 Secret Engine과 같은 일부 Secret Engine은 단순히 데이터를 저장하고 읽습니다. 다른 Secret Engine은 다른 서비스에 연결하고 요청 시 동적 자격 증명을 생성합니다. 다른 Secret Engine은 암호화를 서비스로 제공합니다.

Vault는 가상 파일 시스템과 유사하게 동작하며 읽기/쓰기/삭제/목록 작업은 해당 Secret Engine으로 전달되고 Secret Engine은 이러한 작업에 반응하는 방법을 결정합니다.

Token Authentication

토큰 인증이 자동으로 활성화됩니다. 개발 서버를 시작했을 때 출력에 루트 토큰이 표시되었습니다. Vault CLI는 $VAULT_TOKEN 환경 변수에서 루트 토큰을 읽습니다. 이 루트 토큰은 루트 정책이 할당되기 때문에 Vault 내에서 모든 작업을 수행할 수 있습니다. 한 가지 기능은 새 토큰을 만드는 것입니다.

토큰 생성

vault token create

Key                  Value
---                  -----
token                hvs.HnzG9WVSKWYhNn4cYAkiAhD9
token_accessor       tsambgaXKXUofc1Zjw6fd1TY
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

토큰 삭제

vault token revoke hvs.HnzG9WVSKWYhNn4cYAkiAhD9
vault token revoke [삭제하려는 토큰]

Success! Revoked token (if it existed)

Vault의 정책은 사용자가 액세스할 수 있는 항목을 제어합니다. 인증을 위해 Vault에는 활성화 및 사용할 수 있는 여러 옵션 또는 방법이 있습니다. Vault는 승인 및 정책 모두에 항상 동일한 형식을 사용합니다. 모든 인증 방법은 ID를 Vault로 구성된 핵심 정책에 다시 매핑합니다.

정책은 HCL로 작성되지만 JSON과 호환됩니다.

path "secret/data/*" {
  capabilities = ["create", "update"]
}

path "secret/data/foo" {
  capabilities = ["read"]
}

이 정책을 통해 사용자는 읽기 액세스만 허용되는 secret/data/foo를 제외하고 모든 secret을 secret/data/에 쓸 수 있습니다. 정책은 기본적으로 거부하므로 지정되지 않은 경로에 대한 액세스는 허용되지 않습니다.

정책 형식은 API 경로에서 접두사 일치 시스템을 사용하여 액세스 제어를 결정합니다. 가장 구체적으로 정의된 정책(정확한 일치 또는 가장 긴 접두사 glob 일치)이 사용됩니다. Vault의 모든 것은 API를 통해 액세스해야 하므로 Secret Engine 활성화, 인증 방법 활성화, 인증 및 비밀 액세스를 포함하여 Vault의 모든 측면을 엄격하게 제어할 수 있습니다.

제거할 수 없는 몇 가지 기본 제공 정책이 있습니다. 예를 들어 루트 및 기본 정책은 필수 정책이며 삭제할 수 없습니다. 기본 정책은 공통 권한 집합을 제공하며 기본적으로 모든 토큰에 포함됩니다. 루트 정책은 Linux 시스템의 루트 사용자와 유사한 토큰에 슈퍼 관리자 권한을 부여합니다.

기본 정책 살펴보기

vault policy read default

# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
    capabilities = ["read"]
}

# Allow tokens to renew themselves
path "auth/token/renew-self" {
    capabilities = ["update"]
}

# Allow tokens to revoke themselves
path "auth/token/revoke-self" {
    capabilities = ["update"]
}

# Allow a token to look up its own capabilities on a path
path "sys/capabilities-self" {
    capabilities = ["update"]
}

# Allow a token to look up its own entity by id or name
path "identity/entity/id/{{identity.entity.id}}" {
  capabilities = ["read"]
}
path "identity/entity/name/{{identity.entity.name}}" {
  capabilities = ["read"]
}


# Allow a token to look up its resultant ACL from all policies. This is useful
# for UIs. It is an internal path because the format may change at any time
# based on how the internal ACL features and capabilities change.
path "sys/internal/ui/resultant-acl" {
    capabilities = ["read"]
}

# Allow a token to renew a lease via lease_id in the request body; old path for
# old clients, new path for newer
path "sys/renew" {
    capabilities = ["update"]
}
path "sys/leases/renew" {
    capabilities = ["update"]
}

# Allow looking up lease properties. This requires knowing the lease ID ahead
# of time and does not divulge any sensitive information.
path "sys/leases/lookup" {
    capabilities = ["update"]
}

# Allow a token to manage its own cubbyhole
path "cubbyhole/*" {
    capabilities = ["create", "read", "update", "delete", "list"]
}

# Allow a token to wrap arbitrary values in a response-wrapping token
path "sys/wrapping/wrap" {
    capabilities = ["update"]
}

# Allow a token to look up the creation time and TTL of a given
# response-wrapping token
path "sys/wrapping/lookup" {
    capabilities = ["update"]
}

# Allow a token to unwrap a response-wrapping token. This is a convenience to
# avoid client token swapping since this is also part of the response wrapping
# policy.
path "sys/wrapping/unwrap" {
    capabilities = ["update"]
}

# Allow general purpose tools
path "sys/tools/hash" {
    capabilities = ["update"]
}
path "sys/tools/hash/*" {
    capabilities = ["update"]
}

# Allow checking the status of a Control Group request if the user has the
# accessor
path "sys/control-group/request" {
    capabilities = ["update"]
}

# Allow a token to make requests to the Authorization Endpoint for OIDC providers.
path "identity/oidc/provider/+/authorize" {
	capabilities = ["read", "update"]
}

my-policy 정책 생성

vault policy write my-policy - << EOF
# Dev servers have version 2 of KV secrets engine mounted by default, so will
# need these paths to grant permissions:
path "secret/data/*" {
  capabilities = ["create", "update"]
}

path "secret/data/foo" {
  capabilities = ["read"]
}
EOF

정책 리스트 확인

vault policy list

정책 읽기

vault policy read my-policy

my-policy 정책 권한을 갖는 토큰을 생성 후 환경 변수에 적용

export VAULT_TOKEN="$(vault token create -field token -policy=my-policy)"

토큰 정책 확인

vault token lookup | grep policies
vault kv put -mount=secret creds password="my-long-password"

vault kv CLI 명령을 사용하여 KV v2 Secret Engine에 액세스할 때 -mount 플래그 구문(예: vault kv get -mount=secret foo)을 사용하여 KV v2 Secret Engine에 대한 경로를 참조하는 것이 좋습니다. KV v1과 유사한 경로 접두어 구문(예: vault kv get secret/foo)을 사용하는 경우 /data가 secret 경로에 자동으로 추가되어 혼동을 일으킬 수 있습니다.

현재 토큰 정책은 foo에 대하여 읽기 권한 밖에 없으므로 403 응답코드 반환

vault kv put -mount=secret foo robot=beepboop

Error writing data to secret/data/foo: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/secret/data/foo
Code: 403. Errors:

* 1 error occurred:
	* permission denied

이 정책은 제한된 경로 및 기능 집합을 정의합니다. sys에 대한 액세스 권한이 없으면 vault policy list or vault secrets list와 같은 명령이 작동하지 않습니다.

Associate Policies to Auth Methods

Vault 자체는 여러 인증 방법을 사용할 수 있는 인증과 달리 단일 정책 기관입니다. 특정 인증 방법으로 인증하여 생성된 토큰에 일련의 정책을 자동으로 할당하도록 인증 방법을 구성할 수 있습니다. 이를 수행하는 방법은 관련 인증 방법에 따라 다르지만 일반적으로 역할을 정책에 매핑하거나 ID 또는 그룹을 정책에 매핑하는 것과 관련됩니다.

예를 들어 AppRole 인증 방법에 대한 역할을 구성할 때 token_policies 매개변수를 사용할 수 있습니다.

export VAULT_TOKEN=root
vault auth list | grep 'approle/'

vault auth enable approle
Success! Enabled approle auth method at: approle/

"my-role"이라는 AppRole 역할을 활성화하여 몇 가지 기본 토큰 옵션을 구성하고 이전에 정의된 "my-policy" 정책을 애플리케이션이 역할로 인증할 때 생성되는 모든 토큰에 연결합니다.

vault write auth/approle/role/my-role \
> secret_id_ttl=10m \
> token_num_uses=10 \
> token_ttl=20m \
> token_max_ttl=30m \
> secret_id_num_uses=40 \
> token_policies=my-policy

Success! Data written to: auth/approle/role/my-role

AppRole로 인증하려면 먼저 역할 ID를 가져오고 ROLE_ID 환경 변수에서 해당 값을 입력합니다.

export ROLE_ID="$(vault read -field=role_id auth/approle/role/my-role/role-id)"

다음으로 비밀 ID(AppRole 인증에 사용하는 애플리케이션의 암호와 유사)를 가져오고 SECRET_ID 환경 변수에서 해당 값을 입력합니다.

export SECRET_ID="$(vault write -f -field=secret_id auth/approle/role/my-role/secret-id)"

마지막으로 역할 경로를 지정하고 해당 옵션과 함께 역할 ID 및 Secret ID 값을 전달하여 저장소 쓰기로 AppRole에 인증합니다.

vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"

Key                     Value
---                     -----
token                   hvs.CAESIL1Si66o6zdrUd99k2HBXql-uyZO68_CUURCaAZdI0v-Gh4KHGh2cy5MS3Iwa0VzejJQVVdpQmtSZHVLOTZCZWI
token_accessor          TUAGAkMjyioHzO3cxdAmfJXC
token_duration          20m
token_renewable         true
token_policies          ["default" "my-policy"]
identity_policies       []
policies                ["default" "my-policy"]
token_meta_role_name    my-role

"my-policy" 정책은 policies 및 token_policies 필드에 포함되어 있습니다.

정책 필드 정보: 예제 출력에 표시된 대로 토큰에는 이름이 비슷한 세 개의 필드인 policies, identity_policies 및 token_policies가 있습니다. 이러한 필드의 차이점은 token_policies는 인증 방법에 의해 토큰에 연결된 모든 정책을 나타내고 identity_policies는 ID 비밀 엔진에 의해 토큰에 연결된 모든 정책을 나타냅니다. 정책 필드는 주어진 토큰에 대해 사용 가능한 모든 정책을 표시하는 identity_policies 및 token_policies의 상관 관계입니다.

Vault 배포

vi config.hcl

storage "raft" {
  path = "./vault/data"
  node_id = "node1"
}

listener "tcp" {
  address = "127.0.0.1:8200"
  tls_disable = "true"
}

api_addr = "http://127.0.0.1:8200"
cluster_addr = "https://127.0.0.1:8201"
ui = true

구성 파일에는 두 가지 기본 구성이 있습니다.

• storage: Vault가 스토리지에 사용하는 물리적 백엔드입니다. 지금까지 개발 서버는 "inmem" (메모리 내)을 사용했지만 위의 예에서는 훨씬 더 생산 준비가 완료된 백엔드인 통합 스토리지(raft)를 사용합니다.

• listener: 하나 이상의 수신기가 Vault에서 API 요청을 수신하는 방식을 결정합니다. 위의 예는 TLS 없이 localhost 포트 8200에서 수신 대기합니다. 사용자 환경에서 VAULT_ADDR=http://127.0.0.1:8200을 설정하면 Vault 클라이언트가 TLS 없이 연결됩니다.

• api_addr: 클라이언트 요청을 라우팅하기 위해 광고할 주소를 지정합니다.

• cluster_addr: 클러스터의 Vault 노드 간 통신에 사용할 주소와 포트를 나타냅니다.

서버 시작하기

raft 스토리지 백엔드가 사용하는 ./vault/data 디렉토리가 있어야 합니다.

mkdir -p ./vault/data

-config 플래그로 위의 구성을 저장한 경로를 선택하여 서버 시작

vault server -config=config.hcl

WARNING! mlock is not supported on this system! An mlockall(2)-like syscall to
prevent memory from being swapped to disk is not supported on this system. For
better security, only run Vault on systems where this call is supported. If
you are running Vault in a Docker container, provide the IPC_LOCK cap to the
container.
==> Vault server configuration:

             Api Address: http://127.0.0.1:8200
                     Cgo: disabled
         Cluster Address: https://127.0.0.1:8201
              Go Version: go1.19.3
              Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
               Log Level: info
                   Mlock: supported: false, enabled: false
           Recovery Mode: false
                 Storage: raft (HA available)
                 Version: Vault v1.12.2, built 2022-11-23T12:53:46Z
             Version Sha: 415e1fe3118eebd5df6cb60d13defdc01aa17b03

서버 구성 파일 수정

vi config.hcl

disable_mlock = true

초기화는 Vault를 구성하는 프로세스입니다. 이것은 이전에 Vault와 함께 사용된 적이 없는 새 백엔드에 대해 서버가 시작될 때 한 번만 발생합니다. HA 모드에서 실행할 때 이는 서버가 아닌 클러스터당 한 번 발생합니다. 초기화하는 동안 암호화 키가 생성되고 봉인 해제 키가 생성되며 초기 루트 토큰이 생성됩니다.

새 터미널 세션을 시작하고 VAULT_ADDR 환경 변수를 설정합니다.

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

Vault를 초기화하려면 Vault Operator init를 사용하세요. 인증되지 않은 요청이지만 기존 데이터가 없는 새로운 Vault에서만 작동합니다.

vault operator init

초기화는 매우 중요한 두 가지 정보인 봉인 해제 키와 초기 루트 토큰을 출력합니다.

초기화된 모든 Vault 서버는 봉인된 상태에서 시작됩니다. 구성에서 Vault는 물리적 저장소에 액세스할 수 있지만 암호 해독 방법을 모르기 때문에 읽을 수 없습니다. Vault에 데이터 암호 해독 방법을 가르치는 과정을 Vault 봉인 해제라고 합니다.

봉인 해제는 Vault가 시작될 때마다 발생해야 합니다. API와 명령줄을 통해 수행할 수 있으며 볼트의 봉인을 해제하려면 임계값의 잠금 해제 키가 있어야 합니다. 위의 출력에서 "키 임계값"이 3임을 알 수 있습니다. 즉, Vault의 봉인을 해제하려면 생성된 5개의 키 중 3개가 필요합니다.

Vault는 봉인 해제 시 샤드를 저장하지 않습니다. Vault는 Shamir의 비밀 공유로 알려진 알고리즘을 사용하여 루트 키를 샤드로 분할합니다. 임계값 키 수를 통해서만 재구성하고 데이터에 최종적으로 액세스할 수 있습니다.

vault operator unseal

Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       5
Threshold          3
Unseal Progress    1/3
Unseal Nonce       43a57c9b-e0ba-a1ec-b98f-3c34386ffaad
Version            1.12.2
Build Date         2022-11-23T12:53:46Z
Storage Type       raft
HA Enabled         true

유효한 키를 붙여넣고 확인하면 Vault가 여전히 봉인되어 있지만 진행사항들이 진행되는 것을 볼 수 있습니다. Vault는 3개 중 1개의 키가 있음을 알고 있습니다. 알고리즘의 특성으로 인해 Vault는 임계값에 도달할 때까지 올바른 키가 있는지 알 수 없습니다.

또는 봉인 해제 프로세스는 상태를 저장합니다. 다른 컴퓨터로 이동하여 볼트 운영자가 봉인 해제를 사용할 수 있으며 동일한 서버를 가리키는 한 다른 컴퓨터가 봉인 해제 프로세스를 계속할 수 있습니다. 이는 봉인 해제 프로세스의 설계에 매우 중요합니다. Vault를 해제하려면 여러 키를 가진 여러 사람이 필요합니다. Vault는 여러 컴퓨터에서 봉인을 해제할 수 있으며 키가 함께 있어서는 안 됩니다. 단일 악의적인 운영자는 악의적일 만큼 키가 충분하지 않습니다.

Sealed 값이 false로 변경되면 Vault가 봉인되지 않은 것입니다. 봉인 해제 프로세스를 이해하기 위해 유효하지 않은 키, 다른 순서의 키 등을 입력하면서 자유롭게 사용해보세요.

마지막으로 초기 루트 토큰으로 인증합니다. (봉인 해제 키와 함께 출력에 포함)

vault login

Token (will be hidden):
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                hvs.lIyRiKWtkWLnRP3BpeOQO7bI
token_accessor       ZUzOIqhydpPwt91Mh9bInaDv
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

루트 사용자는 볼트 운영자 인감으로 볼트를 다시 봉인할 수 있으며 단일 운영자가 이 작업을 수행할 수 있습니다. 이를 통해 한 명의 운영자가 비상 시 다른 운영자와 상의하지 않고 Vault를 잠글 수 있습니다.

Vault가 다시 봉인되면 메모리에서 모든 상태(암호화 키 포함)가 지워집니다. Vault는 안전하고 액세스할 수 앖도록 잠겨 있습니다.

인증과 함께 HTTP API 사용 자습서를 계속 진행하기 전에 Ctrl + C를 눌러 서버를 중지합니다.

pgrep -f vault | xargs kill

암호화된 Vault 데이터를 저장하는 /vault/data 디렉터리를 삭제합니다.

rm -r ./vault/data

Vault의 모든 기능은 CLI 외에도 HTTP API를 통해 액세스할 수 있습니다. 실제로 CLI의 대부분의 호출은 HTTP API를 통해 호출됩니다. 경우에 따라 Vault 기능은 CLI를 통해 사용할 수 없으며 HTTP API를 통해서만 액세스할 수 있습니다.

Accessing Secrets via the REST APIs

Vault에 저장된 정보에 액세스해야 하는 시스템은 대부분 REST API를 통해 Vault에 액세스합니다. 예를 들어 머신이 인증을 위해 AppRole을 사용하는 경우 애플리케이션은 먼저 Vault API 토큰을 반환하는 Vault에 인증합니다. 애플리케이션은 나중에 Vault와 통신하기 위해 해당 토큰을 사용합니다.

이 실습 단게에서는 TLS를 비활성화하고 파일 기반 백엔드를 사용합니다. 여기서는 TLS가 비활성화되어 있지만 프로덕션 환경에서는 비활성화해서는 안됩니다.

서버 구성 파일 config.hcl을 만듭니다.

tee config.hcl <<EOF
storage "file" {
  path = "vault-data"
}

listener "tcp" {
  tls_disable = "true"
}
EOF

위에서 작성한 새 구성을 사용하여 Vault 인스턴스를 시작합니다.

vault server -config=config.hcl

이 시점에서 Vault에 HTTP API를 사용할 수 있습니다. 새 터미널 세션을 시작하고 curl을 사용하여 API로 Vault를 초기화합니다.

curl \
> --request POST \
> --data '{"secret_shares": 1, "secret_threshold": 1}' \
> http:/127.0.0.1:8200/v1/sys/init | jq

{
  "keys": [
    "b9e8523874833126603a66faebfbceb1d543d9f8faa3ece8ca268231606bc65b"
  ],
  "keys_base64": [
    "uehSOHSDMSZgOmb66/vOsdVD2fj6o+zoyiaCMWBrxls="
  ],
  "root_token": "hvs.DWBUavjMbaat2hHrIeEF7ZPi"
}

이 응답에는 봉인 해제 키와 초기 루트 토큰이 포함되어 있습니다. 봉인 해제 키를 사용하여 Vault의 봉인을 해제하고 루트 토큰을 사용하여 인증이 필요한 Vault에서 다른 요청을 수행할 수 있습니다. 이 실습에서는 쉽게 복사하여 붙여넣기 위해 $VAULT_TOKEN 환경 변수를 사용하여 루트 토큰을 저장합니다.

export VAULT_TOKEN="hvs.DWBUavjMbaat2hHrIeEF7ZPi"

위의 봉인 해제 키를 사용하여 HTTP API를 통해 Vault를 봉인 해제할 수 있습니다.

curl \
--request POST \
--data '{"key": "uehSOHSDMSZgOmb66/vOsdVD2fj6o+zoyiaCMWBrxls="}' \
> http://127.0.0.1:8200/v1/sys/unseal | jq

{
  "type": "shamir",
  "initialized": true,
  "sealed": false,
  "t": 1,
  "n": 1,
  "progress": 0,
  "nonce": "",
  "version": "1.12.2",
  "build_date": "2022-11-23T12:53:46Z",
  "migration": false,
  "cluster_name": "vault-cluster-836ff6c8",
  "cluster_id": "246bb2b7-07bd-8a84-b19e-67491ef77807",
  "recovery_seal": false,
  "storage_type": "file"
}

Vault API를 호출하여 초기화 상태를 확인할 수 있습니다.

curl http://127.0.0.1:8200/v1/sys/init

{"initialized":true}

이제 사용 가능한 모든 인증 방법을 활성화하고 구성할 수 있습니다.

AppRole 인증 방법을 활성화하는 CLI 명령에 해당하는 CURL을 보려면 -output-curl-string 플래그를 사용하세요.

vault auth enable -output-curl-string approle

Vault API를 호출하여 AppRole 인증 방법을 활성화합니다.

curl \
> --header "X-Vault-Token: $VAULT_TOKEN" \
> --request POST \
> --data '{"type": "approle"}' \
> http://127.0.0.1:8200/v1/sys/auth/approle

AppRole 엔드포인트를 활성화하는 요청에는 인증 토큰이 필요합니다. 이 경우 Vault 서버를 시작할 때 생성된 루트 토큰을 전달합니다. 다른 인증 메커니즘을 사용하여 토큰을 생성할 수도 있지만 단순화를 위해 루트 토큰을 사용합니다.

이제 원하는 ACL 정책 세트로 AppRole을 생성합니다. 이전 실습에서는 CLI를 사용하여 my-policy를 생성했습니다. 이번 실습에서는 /sys/policies/acl 엔드포인트를 사용하여 Vault API를 통해 동일한 정책을 생성합니다.

curl \
> --header "X-Vault-Token: $VAULT_TOKEN" \
> --request POST \
> --data '{"type": "approle"}' \
> http://127.0.0.1:8200/v1/sys/auth/approle

my-policy는 비밀/데이터 경로가 존재할 것으로 예상하므로 API를 사용하여 Secret에서 KV v2 Secret Engine을 활성화합니다.

curl \
> --header "X-Vault-Token: $VAULT_TOKEN" \
> --request POST \
> --data '{ "type": "kv-v2" }' \
> http://127.0.0.1:8200/v1/sys/mounts/secret

다음 명령은 AppRole my-role에서 발급된 토큰이 my-policy와 연결되어야 함을 지정합니다.

curl \
> --header "X-Vault-Token: $VAULT_TOKEN" \
> --request POST \
> --data '{"policies": ["my-policy"]}' \
> http://127.0.0.1:8200/v1/auth/approle/role/my-role

AppRole 인증 방법은 RoleID 및 SecretID를 입력으로 예상합니다. RoleID는 사용자 이름과 유사하며 SecretID는 RoleID의 암호로 생각할 수 있습니다.

다음 명령은 my-role이라는 역할의 RoleID를 가져옵니다.

curl \
> --header "X-Vault-Token: $VAULT_TOKEN" \
> http://127.0.0.1:8200/v1/auth/approle/role/my-role/role-id | jq -r ".data"

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   208  100   208    0     0  27987      0 --:--:-- --:--:-- --:--:--  203k
{
  "role_id": "266b0d37-ae0e-4295-e4e1-9b0fe843d41e"
}

이 명령은 my-role 아래에 새 SecretID를 생성합니다.

curl \
> --header "X-Vault-Token: $VAULT_TOKEN" \
> --request POST \
> http://127.0.0.1:8200/v1/auth/approle/role/my-role/secret-id | jq -r ".data"


  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   311  100   311    0     0  44453      0 --:--:-- --:--:-- --:--:--  303k
{
  "secret_id": "949a70a6-fca5-a7ab-910b-c09e034c09e1",
  "secret_id_accessor": "a6f3e705-96d2-787c-91c9-6826cfba59ef",
  "secret_id_num_uses": 0,
  "secret_id_ttl": 0
}

이 두 자격 증명을 로그인 엔드포인트에 제공하여 새 Vault 토큰을 가져올 수 있습니다.

curl --request POST \
> --data '{"role_id": "266b0d37-ae0e-4295-e4e1-9b0fe843d41e", "secret_id": "949a70a6-fca5-a7ab-910b-c09e034c09e1"}' \
> http://127.0.0.1:8200/v1/auth/approle/login | jq -r ".auth"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   691  100   587  100   104  59328  10511 --:--:-- --:--:-- --:--:--  224k
{
  "client_token": "hvs.CAESIKlXjfGdtaElx_xumVoHu6I4yvHFTuLLEt3wmLVEsfucGh4KHGh2cy5WbktQTnRGTURpckhlZjZhOHp1RDRuU3g",
  "accessor": "qzVf0CzXHPQnXlJX7pqcEonB",
  "policies": [
    "default",
    "my-policy"
  ],
  "token_policies": [
    "default",
    "my-policy"
  ],
  "metadata": {
    "role_name": "my-role"
  },
  "lease_duration": 2764800,
  "renewable": true,
  "entity_id": "9281db5c-4334-6723-fe05-468f629af7cd",
  "token_type": "service",
  "orphan": true,
  "mfa_requirement": null,
  "num_uses": 0
}

반환된 클라이언트 토큰은 Vault 인증에 사용할 수 있으며 이 토큰은 기본 my-policy 정책에 포함된 모든 리소스에 대한 특정 기능으로 승인됩니다.

새로 획득한 토큰은 VAULT_TOKEN 환경 변수 값으로 내보내고 후속 Vault 요청을 인증하는 데 사용할 수 있습니다.

curl \
> --header "X-Vault-Token: $VAULT_TOKEN" \
> --request POST \
> --data '{ "data": {"password": "my-long-password"} }' \


> http://127.0.0.1:8200/v1/secret/data/creds | jq -r ".data"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   320  100   276  100    44  37627   5998 --:--:-- --:--:-- --:--:--  312k
{
  "created_time": "2023-01-16T10:49:06.666814Z",
  "custom_metadata": null,
  "deletion_time": "",
  "destroyed": false,
  "version": 1
}