이 실습은 Google Cloud의 파트너인 HashiCorp와 공동 개발한 것으로, 계정 프로필에서 제품 업데이트, 공지사항, 혜택 관련 정보를 수신하는 데 동의하신 경우 귀하의 개인 정보가 실습 스폰서인 HashiCorp에 공유될 수 있습니다.

GSP1004

개요

Vault는 정책을 사용하여 클라이언트의 동작을 제어하고, 액세스 권한을 지정(승인)하여 역할 기반 액세스 제어(RBAC)를 구현합니다. 정책은 특정 경로와 작업에 대한 액세스를 허용하거나 금지하는 선언적 방법을 제공합니다. 이 실무형 실습에서는 Vault 정책을 작성하고 사용하는 방법을 알아봅니다.

목표

이 실습에서 학습할 내용은 다음과 같습니다.

• Vault 정책 만들기
• Vault 정책 관리
• Vault 정책 연결
• Vault 정책 확인 및 테스트

설정 및 요건

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지를 표시합니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드(권장) 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학습자 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간(실습을 시작하고 나면 일시중지할 수 없음)

참고: 이 실습에는 학습자 계정만 사용하세요. 다른 Google Cloud 계정을 사용하는 경우 해당 계정에 비용이 청구될 수 있습니다.

실습을 시작하고 Google Cloud 콘솔에 로그인하는 방법

1. 실습 시작 버튼을 클릭합니다. 실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 대화상자가 열립니다. 오른쪽에는 다음과 같은 항목이 포함된 실습 설정 및 액세스 패널이 있습니다.

   • Google Cloud 콘솔 열기 버튼
   • 이 실습에 사용해야 하는 임시 사용자 인증 정보(사용자 이름 및 비밀번호)
   • 필요한 경우 실습 진행을 위한 기타 정보

   실습 타이머는 페이지 상단에 있으며 남은 시간을 표시합니다.

2. Google Cloud 콘솔 열기를 클릭합니다(Chrome 브라우저를 실행 중인 경우 마우스 오른쪽 버튼으로 클릭하고 시크릿 창에서 링크 열기를 선택합니다).

   실습에서 리소스가 가동되면 다른 탭이 열리고 로그인 페이지가 표시됩니다.

   팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.

   참고: 계정 선택 대화상자가 표시되면 다른 계정 사용을 클릭합니다.

3. 필요한 경우 아래의 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다.

   {{{user_0.username | "Username"}}}

   실습 설정 및 액세스 패널에서도 사용자 이름을 확인할 수 있습니다.

4. 다음을 클릭합니다.

5. 아래의 비밀번호를 복사하여 시작하기 대화상자에 붙여넣습니다.

   {{{user_0.password | "Password"}}}

   실습 설정 및 액세스 패널에서도 비밀번호를 확인할 수 있습니다.

6. 다음을 클릭합니다.

   중요: 실습에서 제공하는 사용자 인증 정보를 사용해야 합니다. Google Cloud 계정 사용자 인증 정보를 사용하지 마세요. 참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다.

7. 이후에 표시되는 페이지를 클릭하여 넘깁니다.

   • 이용약관에 동의하세요.
   • 임시 계정이므로 복구 옵션이나 2단계 인증을 추가하지 마세요.
   • 무료 체험판을 신청하지 마세요.

잠시 후 Google Cloud 콘솔이 이 탭에서 열립니다.

참고: Google Cloud 제품 및 서비스에 액세스하려면 탐색 메뉴를 클릭하거나 검색창에 제품 또는 서비스 이름을 입력합니다.

Cloud Shell 활성화

Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다. Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Google Cloud 콘솔 상단에서 Cloud Shell 활성화 를 클릭합니다.

2. 다음 창을 클릭합니다.

   • Cloud Shell 정보 창을 통해 계속 진행합니다.
   • 사용자 인증 정보를 사용하여 Google Cloud API를 호출할 수 있도록 Cloud Shell을 승인합니다.

연결되면 사용자 인증이 이미 처리된 것이며 프로젝트가 학습자의 PROJECT_ID, (으)로 설정됩니다. 출력에 이 세션의 PROJECT_ID를 선언하는 줄이 포함됩니다.

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

3. (선택사항) 다음 명령어를 사용하여 활성 계정 이름 목록을 표시할 수 있습니다.

gcloud auth list

4. 승인을 클릭합니다.

출력:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (선택사항) 다음 명령어를 사용하여 프로젝트 ID 목록을 표시할 수 있습니다.

gcloud config list project

출력:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 참고: gcloud 전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참고하세요.

작업 1. Vault 설치

1. Cloud Shell에서 HashiCorp GPG 키를 추가합니다.

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add - 참고: 경고가 표시되면 무시하세요.

2. 공식 HashiCorp Linux 저장소를 추가합니다.

sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"

3. Vault를 업데이트하고 설치합니다.

sudo apt-get update sudo apt-get install vault

설치 확인

Vault를 설치한 후, Vault 바이너리를 사용할 수 있는지 확인하여 설치가 제대로 되었는지 확인합니다.

• vault 명령어를 실행하여 설치를 확인합니다.

vault

다음과 비슷한 도움말 출력이 표시됩니다.

Usage: vault <command> [args] Common commands: read Read data and retrieves secrets write Write data, configuration, and secrets delete Delete secrets and configuration list List data or secrets login Authenticate locally agent Start a Vault agent server Start a Vault server status Print seal and HA status unwrap Unwrap a wrapped secret Other commands: audit Interact with audit devices auth Interact with auth methods debug Runs the debug command kv Interact with Vault's Key-Value storage lease Interact with leases monitor Stream log messages from a Vault server namespace Interact with namespaces operator Perform operator-specific tasks path-help Retrieve API help for paths plugin Interact with Vault plugins and catalog policy Interact with policies print Prints runtime configurations secrets Interact with secrets engines ssh Initiate an SSH session token Interact with tokens

작업 2. Vault 서버 시작

Vault가 설치된 후 다음 단계는 Vault 서버를 시작하는 것입니다.

Vault는 클라이언트/서버 애플리케이션으로 작동합니다. Vault 서버는 데이터 스토리지 및 백엔드와 상호작용하는 Vault 아키텍처의 유일한 구성요소입니다. Vault CLI를 통해 수행되는 모든 작업은 TLS 연결을 통해 서버와 상호작용합니다.

이 실습에서는 개발 모드로 실행되는 Vault 서버를 시작하고 이 서버와 상호작용합니다.

이 개발 모드 서버는 추가 설정이 필요하지 않으며, 로컬 Vault CLI가 이 서버와 통신하도록 인증됩니다. 따라서 손쉽게 Vault를 사용해 보거나 개발을 위한 Vault 인스턴스를 시작할 수 있습니다. Vault의 모든 기능은 'dev' 모드에서 사용할 수 있습니다. -dev 플래그를 사용하면 많은 설정이 안전하지 않은 기본값으로 간소화됩니다.

경고: 'dev' 모드 서버는 절대 프로덕션 환경에서 실행하지 마세요. 이렇게 하면 안전하지 않으며, 데이터를 인메모리에 저장하므로 서버를 다시 시작할 때마다 데이터가 손실됩니다. 이 모드는 개발 또는 실험 전용입니다.

dev 서버 시작

먼저 Vault dev 서버를 시작합니다. dev 서버는 기본 제공되는 사전 구성된 서버로, 보안 수준이 그다지 높지는 않지만 Vault를 로컬에서 사용해 보기에 유용합니다.

1. Vault dev 서버를 시작하려면 다음을 실행합니다.

vault server -dev

Vault 서버 구성과 관련된 출력이 표시됩니다. 해제 키 및 루트 토큰 값이 표시됩니다.

==> Vault server configuration: Api Address: http://127.0.0.1:8200 Cgo: disabled Cluster Address: https://127.0.0.1:8201 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: inmem Version: Vault v1.4.1 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 variable: $ 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: 1+yv+v5mz+aSCK67X6slL3ECxb4UDL8ujWZU/ONBpn0= Root Token: s.XmpNPoi9sRhYtdKHaQhkHP6x Development mode should NOT be used in production installations! 참고: dev 서버는 모든 데이터를 인메모리에 저장하고(여전히 암호화됨), TLS 없이 localhost에서 수신 대기하며, 자동으로 해제하고 해제 키와 루트 액세스 키를 표시합니다. 참고: 안전하지 않은 작업

Vault dev 서버를 프로덕션 환경에서 실행하지 마세요. 이 방식은 이 데모의 해제 프로세스를 간소화하기 위해서만 사용됩니다.

이제 Vault 개발 서버가 실행 중이므로 서버에 대한 액세스 설정을 계속할 수 있습니다.

2. 새 Cloud Shell 탭을 엽니다.

3. 터미널 출력에서 export VAULT_ADDR … 명령어를 복사하여 실행합니다. 이렇게 하면 Vault 클라이언트가 dev 서버와 통신하도록 구성됩니다.

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

Vault CLI는 VAULT_ADDR 환경 변수를 사용하여 요청을 보낼 Vault 서버를 결정합니다.

서버가 실행 중인지 확인

• vault status 명령어를 실행하여 서버가 실행 중인지 확인합니다.

vault status

성공적으로 실행되면 다음과 같은 출력이 표시됩니다.

$ vault status Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 1 Threshold 1 Version 1.13.2 Build Date 2023-04-25T13:02:50z Storage Type inmem Cluster Name vault-cluster-e2392b81 Cluster ID 48d7aba0-5416-a36b-2c27-0b256b222f57 HA Enabled false

좋습니다. 첫 번째 Vault 개발 서버를 시작했습니다. 이제 다음 섹션으로 넘어가서 Vault 정책을 작성하는 방법을 알아보겠습니다.

작업 3. Vault 정책

Vault는 초기화 중에 root 정책을 만듭니다. root 정책은 모든 경로에 대해 모든 작업을 수행할 수 있습니다. 이 정책은 초기화가 완료되면 표시되는 root 토큰에 할당됩니다. 이렇게 하면 보안 비밀 엔진을 사용 설정하고, 정책을 정의하고, 인증 방법을 구성할 수 있는 초기 수퍼유저가 제공됩니다.

Vault는 default 정책도 만듭니다. default 정책은 토큰이 스스로를 반영하고 관리할 수 있도록 하는 공통된 권한 집합을 정의합니다. 이 정책은 root 토큰에도 할당되며, 기본적으로 모든 토큰에 연결됩니다.

정책 문법

정책은 HCL 또는 JSON으로 작성되며, 사용자 또는 머신이 액세스할 수 있는 Vault의 경로를 설명합니다. 정책은 경로의 목록을 정의하며, 각 경로는 허용되는 권한을 나타냅니다. Vault는 보안 강화를 기본으로 설정하여 기본적으로 경로에 대한 권한을 거부하므로, 경로에 대한 권한을 부여해야 합니다.

정책의 기본 형식은 다음과 같습니다.

path "<path>" { capabilities = ["list of capabilities"] }

다음은 'secret/foo' 경로에 읽기 권한을 부여하는 매우 간단한 정책입니다.

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

이 정책이 토큰에 할당되면 토큰을 'secret/foo'에서 읽을 수 있습니다. 그러나 이 권한이 허용하지 않으므로 토큰이 'secret/foo'를 업데이트하거나 삭제할 수 없습니다. 정책이 기본적으로 거부이므로 토큰은 Vault에서 다른 액세스 권한이 없습니다. 즉, 빈 Vault 정책은 시스템에서 어떠한 권한도 부여하지 않습니다.

권한

정책은 하나 이상의 경로와 허용되는 권한의 목록을 정의합니다. 각 경로는 허용되거나 거부되는 작업을 세밀하게 제어할 수 있도록 하나 이상의 권한을 정의해야 합니다. 아래 예에서 볼 수 있듯이, 권한이 하나뿐인 경우에도 권한은 항상 문자열의 목록으로 지정됩니다. 이러한 권한은 대부분 Vault API에서 지원하는 HTTP 동사에 매핑됩니다. 권한의 목록은 다음과 같습니다.

정책 권한	연결된 HTTP 동사
create	POST/PUT
read	GET
update	POST/PUT
delete	DELETE
list	LIST
patch	PATCH
sudo	-
deny	-

sudo 권한은 루트로 보호되는 경로에 대한 액세스를 허용합니다(루트로 보호되는 엔드포인트 튜토리얼 섹션 참고). deny 권한은 경로에 대한 액세스를 사용 중지합니다. 다른 권한과 결합될 경우 항상 우선시됩니다.

정책 예시

"secret/*"에 대한 모든 액세스 권한을 부여하는 더 상세한 정책은 다음과 같이 정의할 수 있습니다.

path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] }

추가적인 제한을 정의하려면 다음과 같이 deny 권한을 추가하면 됩니다.

path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/super-secret" { capabilities = ["deny"] }

secret/*를 허용했어도 위의 추가 줄은 secret/super-secret를 명시적으로 거부합니다. 거부가 우선시됩니다.

정책에서 allowed, disallowed, required 파라미터를 지정할 수도 있습니다. 여기서 키 "secret/restricted"는 "foo"(모든 값)와 "bar"("zip" 또는 "zap" 중 하나)만 포함할 수 있습니다.

path "secret/restricted" { capabilities = ["create"] allowed_parameters = { "foo" = [] "bar" = ["zip", "zap"] } }

정책은 경로 기반 일치를 사용하여 요청에 대해 권한 집합을 테스트합니다. 정책 path에는 일치시킬 정확한 경로를 지정하거나, Vault에 프리픽스 일치를 사용하도록 지시하는 glob 패턴을 지정할 수 있습니다.

예를 들어 이 정책은 "secret/foo" 또는 "secret/foo/bar"에만 읽기를 허용합니다.

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

또한 이 정책은 "secret/bar" 아래의 모든 항목을 읽을 수 있도록 허용합니다. 연결된 토큰은 "secret/bar/zip", "secret/bar/zip/zap"을 읽을 수 있지만 "secret/bars/zip"은 읽을 수 없습니다.

path "secret/bar/*" { capabilities = ["read"] }

또한 이 정책은 프리픽스 "zip-"가 있는 모든 항목을 읽을 수 있도록 허용합니다. 연결된 토큰은 "secret/zip-zap" 또는 "secret/zip-zap/zong"을 읽을 수 있지만 "secret/zip/zap"은 읽을 수 없습니다.

path "secret/zip-*" { capabilities = ["read"] }

마지막으로 +는 단일 경로 세그먼트 내에 포함된 임의의 문자 수를 나타내는 데 사용할 수 있습니다. 다음은 secret/ 아래의 모든 최상위 경로에서 "teamb" 경로를 읽을 수 있도록 허용합니다.

path "secret/+/teamb" { capabilities = ["read"] }

이 정책은 secret/foo/bar/teamb, secret/bar/foo/teamb 등을 읽을 수 있도록 허용합니다.

path "secret/+/+/teamb" { capabilities = ["read"] }

보시다시피 Vault의 아키텍처는 파일 시스템과 유사합니다. Vault의 모든 작업에는 해당하는 경로와 권한이 있습니다. Vault의 내부 핵심 구성 엔드포인트도 "sys/" 경로 아래에 있습니다. 정책은 이러한 경로 및 권한에 대한 액세스를 정의하여 Vault의 사용자 인증 정보에 대한 토큰의 액세스를 제어합니다.

템플릿 기반 정책

정책 문법을 사용하면 토큰에 사용할 수 있는 값으로 일부 정책 문자열의 변수를 대체할 수 있습니다. 현재 identity 정보를 삽입할 수 있으며, 정책의 path 키를 통해 삽입할 수 있습니다. 지금은 항목이나 별칭에 대해 신경 쓸 필요가 없습니다. 나중에 참조할 수 있도록 포함한 것일 뿐입니다.

파라미터

이름	설명
identity.entity.id	항목의 ID
identity.entity.name	항목의 이름
identity.entity.metadata.<metadata key>	주어진 키에 대한 항목과 연결된 메타데이터
identity.entity.aliases.<mount accessor>.id	지정된 마운트의 항목 별칭 ID
identity.entity.aliases.<mount accessor>.name	지정된 마운트의 항목 별칭 이름
identity.entity.aliases.<mount accessor>.metadata.<metadata key>	지정된 마운트 및 메타데이터 키의 별칭과 연결된 메타데이터
identity.entity.aliases.<mount accessor>.custom_metadata.<custom_metadata key>	지정된 마운트 및 커스텀 메타데이터 키의 별칭과 연결된 커스텀 메타데이터
identity.groups.ids.<group id>.name	주어진 그룹 ID의 그룹 이름
identity.groups.names.<group name>.id	주어진 그룹 이름의 그룹 ID
identity.groups.ids.<group id>.metadata.<metadata key>	주어진 키에 대한 그룹과 연결된 메타데이터
identity.groups.names.<group name>.metadata.<metadata key>	주어진 키에 대한 그룹과 연결된 메타데이터

예시

다음 정책은 특정 사용자를 위한 KVv2 보안 비밀 엔진의 섹션을 생성합니다.

path "secret/data/{{identity.entity.id}}/*" { capabilities = ["create", "update", "read", "delete"] } path "secret/metadata/{{identity.entity.id}}/*" { capabilities = ["list"] }

템플릿 기반 정책에 대한 자세한 내용은 템플릿 기반 정책 문서를 확인하세요.

참고: 템플릿 기반 정책을 개발할 때는 가능한 한 ID를 사용하세요. 각 ID는 사용자마다 고유하지만, 이름은 시간이 지나면 변경될 수 있고 재사용될 수도 있습니다. 이렇게 하면 특정 사용자 또는 그룹 이름이 변경되더라도 정책이 의도한 항목 또는 그룹에 매핑됩니다.

기본 제공 정책 권한 확인

정책이 어떻게 작성되는지 살펴보았으니, 이제 root 및 default 정책의 권한을 간단히 살펴보겠습니다.

1. 열려 있는 Cloud Shell 탭에서 다음 명령어를 실행하여 루트 토큰으로 Vault에 로그인합니다.

vault login token=<your root token>

다음과 같은 출력이 표시됩니다.

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 s.mCWmZyVNi6ZDU7HSq7vQXwvj token_accessor nFDgTnm7FYCHNLSERwiVsbWf token_duration ∞ token_renewable false token_policies ["root"] identity_policies [] policies ["root"] 참고: 연결된 정책은 root 정책입니다.

2. root 정책은 Vault에서 모든 작업을 수행할 수 있도록 허용하므로, 이를 확인하기 위해 기본 명령어를 실행합니다.

vault secrets list

다음과 유사한 결과가 출력됩니다.

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_f0f2e28e per-token private secret storage identity/ identity identity_a554d41f identity store secret/ kv kv_ca28f047 key/value secret storage sys/ system system_1a7dcf93 system endpoints..

이제 default 정책만 연결된 사용자로 동일한 명령어를 실행해 보겠습니다.

3. 먼저 userpass 인증 방법을 사용 설정하고 새로운 사용자를 만듭니다.

vault auth enable userpass vault write auth/userpass/users/example-user password=password!

4. 그런 다음, 새로 만든 사용자로 Vault에 로그인합니다.

vault login -method=userpass username=example-user password=password!

다음과 같은 결과가 표시됩니다.

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 s.Ov9GkScxp5AYDjzmbdHNN4r0 token_accessor UewGCCotUMjccmD1EjssgHqf token_duration 768h token_renewable true token_policies ["default"] identity_policies [] policies ["default"] token_meta_username example-user 참고: 연결된 정책은 default 정책입니다.

5. 이전과 동일한 명령어를 실행하여 정책 권한을 확인합니다.

vault secrets list

다음 오류가 표시됩니다.

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

여기에서 볼 수 있듯이 Vault는 sys/mounts 경로에 GET API 요청을 보냅니다. 권한 거부 오류가 발생하므로 이 경로에 액세스하여 보안 비밀 엔진을 나열할 수 없습니다. 이제 이 경로에 액세스하여 보안 비밀 엔진을 나열할 수 있도록 첫 번째 정책을 작성해 보겠습니다.

작업 4. 정책 만들기

Vault는 분산된 인프라와 애플리케이션 전반에서 보안 비밀에 대한 액세스를 중앙에서 보호, 저장, 제어하므로 사용자나 머신이 액세스 권한을 얻기 전에 권한을 제어하는 것이 중요합니다.

이 문제의 해결책은 루트 정책의 사용을 제한하고 세분화된 정책을 작성하여 최소 권한을 적용하는 것입니다. 예를 들어 앱이 Vault에서 Google Cloud 사용자 인증 정보를 가져오는 경우, Google Cloud 보안 비밀 엔진에서 읽을 수는 있지만 삭제할 수는 없도록 권한을 부여하는 등의 정책을 작성합니다.

정책은 토큰과 역할에 연결되어 Vault에서 클라이언트 권한을 적용합니다. 정책이 문법적으로 어떻게 정의되는지 살펴보았으니 이제 첫 번째 Vault 정책을 작성해 보겠습니다.

Vault 웹 UI에 로그인

1. 먼저 Cloud Shell 툴바에서 웹 미리보기 아이콘을 클릭합니다.

2. 포트 변경을 클릭합니다.

3. 포트 번호를 8200으로 변경하고 변경 및 미리보기를 클릭합니다.

4. Vault 로그인 페이지로 리디렉션됩니다.

5. 실습에서 이전에 저장한 루트 토큰을 입력하고 로그인을 클릭합니다.

Vault 개발 서버가 다음과 같이 표시됩니다.

이제 개발 서버 웹 UI에 로그인했으므로 다음 섹션으로 진행할 수 있습니다.

새 정책 만들기

1. 홈페이지에서 액세스 제어를 클릭합니다. default 및 root ACL 정책이 표시됩니다.

2. ACL 정책 만들기를 클릭합니다.

3. 먼저 정책 이름을 demo-policy로 지정합니다.

이제 정책을 작성할 수 있습니다. 이전 섹션에서 보안 비밀 엔진을 읽기 위해 sys/mounts 경로에 액세스할 수 없었던 것을 기억해 보세요. 이제 해당 경로에 대한 액세스 권한을 추가합니다.

4. 정책 규칙에서 코드 편집기를 선택하고 다음과 같은 플레이스홀더 코드를 추가합니다.

path "path" { capabilities = [""] }

5. 이제 먼저 path를 앞서 액세스하려고 했던 sys/mounts 경로로 업데이트합니다.

path "sys/mounts" { capabilities = [""] }

6. 다음으로 권한을 추가합니다. Vault는 이 경로에서 GET API 호출을 시도하므로 read 권한이 필요합니다. 권한 목록에 read를 추가합니다.

path "sys/mounts" { capabilities = ["read"] }

정책이 다음과 같이 표시됩니다.

7. 정책 만들기를 클릭합니다.

이제 이 정책을 이전에 만든 example-user와 연결해야 합니다.

8. 기본 탐색으로 돌아가기를 클릭합니다.

9. 왼쪽 창에서 액세스 > 인증 방법을 클릭한 다음 userpass를 클릭합니다.

10. example-user 사용자 옆에 있는 점 3개를 클릭하고 사용자 수정을 선택합니다.

11. 비밀번호 필드 아래에서 토큰을 클릭하여 하위 메뉴를 엽니다.

12. 생성된 토큰의 정책 아래에서 방금 만든 정책(demo-policy)을 추가하고 추가를 클릭합니다.

13. 저장을 클릭합니다.

좋습니다. 새 정책을 만들고 example-user와 연결했습니다.

14. Cloud Shell로 돌아가서 다음 명령어를 다시 실행합니다.

vault secrets list

이전과 동일한 오류가 표시됩니다.

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

사용자에게 정책을 추가한 후에 오류가 발생한 이유는 무엇일까요? 그 이유는 새 정책을 사용자와 연결하면 해당 정책이 해당 사용자의 기존 토큰과 연결되지 않기 때문입니다. 이 문제를 해결하려면 해당 사용자에 대한 새 토큰을 생성하여 새 정책을 해당 토큰에 연결해야 합니다.

15. 다음 명령어를 실행하여 로그인하고 example-user의 새 토큰을 생성합니다.

vault login -method=userpass username=example-user password=password! 참고: 출력 시 새 토큰을 받게 됩니다. 이제 default 정책과 demo-policy가 연결되었습니다. 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 s.7AVelOPORi1zhjH5iLototw7 token_accessor H1ee2gTXzTXUU9ptpU3ailnJ token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username example-user

16. 이제 보안 비밀 엔진을 다시 한번 나열해 보세요.

vault secrets list

다음과 유사한 결과가 출력됩니다.

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_76cb59ae per-token private secret storage identity/ identity identity_7fa27e52 identity store secret/ kv kv_f6e83366 key/value secret storage sys/ system system_414d50aa system endpoints..

17. vault token capabilities 명령어를 사용하여 토큰의 권한을 확인할 수도 있습니다. 다음을 실행하여 sys/mounts 경로에서 정책을 확인합니다.

vault token capabilities <your token> sys/mounts

다음과 같은 결과가 출력됩니다.

read

18. 다음으로 sys/policies/acl 경로의 토큰 권한을 확인합니다.

vault token capabilities <your token> sys/policies/acl

다음과 같은 결과가 출력됩니다.

deny

19. 이를 확인하려면 다음 명령어를 실행하여 정책을 나열해 봅니다.

vault policy list

다음 오류가 표시됩니다.

Error listing policies: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/policies/acl?list=trueCode: 403. Errors: * 1 error occurred: * permission denied

여기에서 볼 수 있듯이 sys/policies/acl 경로에 대한 GET API 요청에 권한 거부 오류가 발생합니다. 또한 경로에 list=true가 추가되어 있습니다. 해당 권한도 추가해야 합니다. 기존 정책을 업데이트하여 이 문제를 해결해 보겠습니다.

20. Vault UI에서 만든 demo-policy로 다시 이동합니다.

21. 정책 수정을 클릭합니다.

22. 정책 상자에 작성한 기존 정책 아래에 다음 플레이스홀더 코드를 추가합니다.

path "path" { capabilities = [""] }

23. 먼저 path를 액세스하려고 했던 sys/policies/acl 경로로 다시 업데이트합니다.

path "sys/policies/acl" { capabilities = [""] }

24. 이제 권한을 추가합니다. Vault가 이 경로에서 GET API 호출을 시도하므로 read 권한을 다시 추가해야 합니다. 또한 요청에 따라 URL에 list=true가 전달되었으므로 이 권한도 추가해야 합니다.

path "sys/policies/acl" { capabilities = ["read", "list"] }

이제 업데이트된 정책은 다음과 유사합니다.

25. 저장을 클릭합니다.

26. Cloud Shell로 돌아가서 다음 명령어를 다시 실행합니다.

vault policy list

이제 다음과 비슷한 출력이 나타납니다.

default default-ceiling demo-policy root

27. 다음 명령어를 실행하여 정책 값을 텍스트 파일에 복사합니다.

vault policy list > policies.txt

28. 마지막으로 sys/policies/acl 경로에 대한 토큰 권한을 다시 확인합니다.

vault token capabilities <your token> sys/policies/acl

다음과 같은 결과가 출력됩니다.

list, read

29. 다음 명령어를 실행하여 정책 값을 텍스트 파일에 복사합니다. <your token>을 토큰 값으로 바꿔야 합니다.

vault token capabilities <your token> sys/policies/acl > token_capabilities.txt

30. 다음 명령어를 실행하여 policies 및 token_capabilities 텍스트 파일을 모두 사전 생성된 Cloud Storage 버킷에 복사해서 진행 상황을 추적합니다.

export PROJECT_ID=$(gcloud config get-value project) gcloud storage cp *.txt gs://$PROJECT_ID

보시다시피 사용자와 연결된 기존 정책을 수정하면 새 토큰을 생성하지 않아도 변경사항이 반영됩니다. 이는 토큰이 사용될 때마다 정책 내용이 실시간으로 파싱되기 때문입니다. 따라서 정책이 수정되면 해당 정책이 연결된 토큰을 사용하여 다음에 Vault를 호출할 때 수정된 규칙이 적용됩니다.

좋습니다. sys/mounts 경로에 대한 읽기 권한을 부여하는 정책을 만들고 이 정책을 사용자와 연결했습니다. 그런 다음 sys/policies 경로에 대한 read 및 list 액세스 권한을 부여하는 정책을 추가했습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 정책 만들기

작업 5. 정책 관리

정책은 원하는 편집기로 작성합니다. HCL 또는 JSON으로 작성할 수 있으며, 문법은 위에서 자세히 설명했습니다. 정책을 저장한 후에 사용하려면 먼저 Vault에 업로드해야 합니다.

이전 섹션에서는 UI를 사용하여 정책을 작성하고 관리했습니다. 이 섹션에서는 정책을 관리하기 위한 CLI 명령어를 설명합니다.

• 먼저 Cloud Shell에서 다음을 실행하여 루트 토큰으로 Vault에 로그인합니다.

vault login <your root token>

정책 나열

• 다음 명령어를 실행하여 Vault에 등록된 모든 정책을 나열합니다.

vault read sys/policy

다음과 같은 출력이 표시됩니다.

Key Value --- ----- keys [default demo-policy root] policies [default demo-policy root

정책 만들기

정책은 CLI, UI 또는 API를 통해 생성(업로드)할 수 있습니다. 이전 섹션에서는 단순히 UI를 사용하여 HCL 파일을 만들었습니다.

Vault에서 새 정책을 만들려면 다음 명령어를 사용합니다.

vault policy write policy-name policy-file.hcl

1. 먼저 다음 명령어로 기본 정책 파일을 만들어 테스트해 볼 수 있습니다.

tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } EOF

2. 파일이 올바르게 생성되었는지 확인합니다.

cat example-policy.hcl

3. 이제 vault policy write 명령어를 사용하여 example-policy라는 새 정책을 만듭니다.

vault policy write example-policy example-policy.hcl

성공하면 다음과 같은 출력이 표시됩니다.

Success! Uploaded policy: example-policy

이 예시에서 정책 이름은 'example-policy'입니다. 이 이름을 정책 ACL에 대한 포인터 또는 심볼릭 링크라고 생각할 수 있습니다. 토큰은 이름별로 정책에 연결된 다음, 각 이름에 해당하는 규칙 집합에 매핑됩니다.

정책 업데이트

CLI 또는 API를 통해 기존 정책을 업데이트하여 권한을 변경할 수 있습니다. Vault에서 기존 정책을 업데이트하려면 정책을 만들 때와 동일한 단계를 따르되 기존 정책 이름을 사용합니다.

1. 먼저 다음 명령어를 실행하여 인증 방법을 나열할 수 있도록 기존 정책 파일을 업데이트하고 덮어씁니다.

tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List auth methods path "sys/auth" { capabilities = ["read"] } EOF

2. 파일이 올바르게 생성되었는지 확인합니다.

cat example-policy.hcl

3. 정책을 업데이트합니다.

vault write sys/policy/example-policy policy=@example-policy.hcl

좋습니다. CLI를 사용하여 정책을 성공적으로 업데이트했습니다.

4. 다음 명령어를 실행하여 정책 파일을 사전 생성된 Cloud Storage 버킷에 복사하여 진행 상황을 추적합니다.

gcloud storage cp example-policy.hcl gs://$PROJECT_ID

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. CLI 명령어를 사용하여 정책 만들기 및 관리

정책 삭제

기존 정책은 CLI, UI 또는 API를 통해 삭제할 수 있습니다. 정책을 삭제하려면 다음을 실행합니다.

vault delete sys/policy/policy-name

1. 실제로 해보겠습니다. 다음 명령어를 실행하여 방금 만든 정책을 삭제합니다.

vault delete sys/policy/example-policy

성공하면 다음과 같은 출력이 표시됩니다.

Success! Data deleted (if it existed) at: sys/policy/example-policy

2. 다음 명령어를 사용하여 정책을 나열합니다.

vault policy list

다음과 같은 출력이 표시됩니다.

default default-ceiling demo-policy root

좋습니다. example-policy가 삭제되었습니다.

참고: 이 작업은 멱등적입니다. Vault는 존재하지 않는 정책을 삭제할 때 오류를 반환하지 않습니다.

작업 6. 정책 연결

Vault는 승인을 기반으로 토큰에 정책 집합을 자동으로 연결할 수 있습니다. 이 구성은 인증 백엔드에 따라 크게 다릅니다. 이 예시에서는 단순화를 위해 Vault의 기본 제공 userpass 인증 방법을 사용합니다.

1. 다음 명령어를 실행하여 Vault에 firstname-lastname 사용자를 만들고 연결할 정책 목록을 지정합니다.

vault write auth/userpass/users/firstname-lastname \ password="s3cr3t!" \ policies="default, demo-policy" Success! Data written to: auth/userpass/users/firstname-lastname

이렇게 하면 사용자가 Vault에 인증하는 데 성공할 경우, 해당 정책 목록이 연결된 토큰이 발급되도록 정책에 대한 인증 매핑이 생성됩니다.

2. 다음을 실행하여 Vault로 인증합니다.

vault login -method="userpass" username="firstname-lastname" password="s3cr3t!"

다음과 같은 출력이 표시됩니다.

Key Value --- ----- token s.XnRsinhsokVUiN7XbsnyCOEC token_accessor JFErk5Rgb7vtW47CJjY2OCsF token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username firstname-lastname

제공된 정보가 올바르므로 Vault는 토큰을 생성하고 구성된 정책 목록을 토큰에 할당한 다음 해당 토큰을 인증된 사용자에게 반환합니다.

토큰

토큰에는 두 가지 정책 집합이 있습니다. 첫째, ID 정책은 항목 및 해당 항목의 그룹을 기반으로 계산됩니다. 둘째, 토큰 정책은 로그인 방법을 기반으로 정의되거나, API를 통해 토큰을 명시적으로 생성하는 경우 토큰 생성을 위한 입력으로 사용됩니다. 아래의 내용은 토큰 정책에만 해당합니다. 토큰의 ID 정책은 기반이 되는 항목, 그룹, 그룹 멤버십을 수정하는 방법으로만 제어할 수 없습니다.

1. 먼저 루트 토큰으로 Vault에 다시 로그인합니다.

vault login <your root token>

2. 토큰은 생성 시 정책과 연결됩니다. 다음을 실행하여 dev-readonly 및 logs 정책이 포함된 토큰을 만듭니다.

vault token create -policy=dev-readonly -policy=logs

다음과 같은 출력이 표시됩니다.

Key Value --- ----- token s.gKRV6vzFmpdJ9iwvPfzNjAuI token_accessor S4jfdYvy8jQP7GGDa947CBlT token_duration 768h token_renewable true token_policies ["default" "dev-readonly" "logs"] identity_policies [] policies ["default" "dev-readonly" "logs"] 참고: 아직 정책을 만들지 않았으므로 정책이 존재하지 않는다는 경고는 무시해도 됩니다.

일반적으로 지정할 수 있는 정책은 현재 토큰(새 토큰의 상위 토큰)의 토큰 정책에 포함된 정책들뿐입니다. 하지만 루트 사용자는 모든 정책을 할당할 수 있습니다.

토큰이 발급된 후에는 토큰과 연결된 정책을 수정할 수 없습니다. 새 정책 세트를 받으려면 토큰을 취소하고 새로운 토큰을 발급받아야 합니다.

하지만 정책의 콘텐츠는 토큰이 사용될 때마다 실시간으로 파싱됩니다. 따라서 정책이 수정되면 해당 정책이 연결된 토큰을 사용하여 다음에 Vault를 호출할 때 수정된 규칙이 적용됩니다.

작업 7. 보안 비밀 정책

이 섹션에서는 Vault 내에서 사용자에게 다양한 수준의 액세스 권한을 부여하는 Vault 정책을 만들고 테스트합니다.

• 먼저 Cloud Shell에서 서로 다른 정책을 적용할 사용자 몇 명을 만듭니다.

vault write auth/userpass/users/admin \ password="admin123" \ policies="admin" vault write auth/userpass/users/app-dev \ password="appdev123" \ policies="appdev" vault write auth/userpass/users/security \ password="security123" \ policies="security"

새 사용자를 만들었으므로 이제 해당 사용자에게 연결할 정책을 만듭니다. 먼저 Vault의 모든 보안 비밀에 대한 전체 액세스 권한을 가질 수 있는 admin 정책부터 시작합니다.

관리자 정책 만들기

이 실습에서는 admin 사용자가 다음을 수행할 수 있어야 합니다.

• 시스템 상태 점검을 읽습니다.
• Vault 전반에서 ACL 정책을 광범위하게 생성 및 관리합니다.
• Vault 전반에서 인증 방법을 광범위하게 사용 설정 및 관리합니다.
• secret/ 경로에서 사용 설정된 키-값 보안 비밀 엔진을 관리합니다.

1. Vault UI의 왼쪽 창에서 ACL 정책으로 이동합니다. default, default-ceiling, demo-policy, root 정책이 표시됩니다.

2. ACL 정책 만들기를 클릭합니다.

3. 먼저 정책 이름을 admin으로 지정합니다.

4. 정책 규칙에서 코드 편집기를 선택하고 다음 정책 코드를 추가합니다.

# Read system health check path "sys/health" { capabilities = ["read", "sudo"] } # Create and manage ACL policies broadly across Vault # List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Enable and manage authentication methods broadly across Vault # Manage auth methods broadly across Vault path "auth/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, update, and delete auth methods path "sys/auth/*" { capabilities = ["create", "update", "delete", "sudo"] } # List auth methods path "sys/auth" { capabilities = ["read"] } # Enable and manage the key/value secrets engine at `secret/` path # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }

정책이 다음과 같이 표시됩니다.

5. 정책 만들기를 클릭합니다.

appdev 정책 만들기

이 실습에서는 appdev 사용자가 다음을 수행할 수 있어야 합니다.

• 보안 비밀 엔진을 만들고, 읽고, 업데이트합니다.
• secret/appdev/ 경로에서 사용 설정된 키-값 보안 비밀 엔진을 관리합니다.

1. ACL 정책 페이지로 돌아갑니다.

2. ACL 정책 만들기를 클릭합니다.

3. 먼저 정책 이름을 appdev로 지정합니다.

4. 정책 규칙에서 코드 편집기를 선택하고 다음 정책 코드를 추가합니다.

# List, create, update, and delete key/value secrets path "secret/+/appdev/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, read, and update secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }

5. 정책 만들기를 클릭합니다.

보안 정책 만들기

이 실습에서는 security 사용자가 다음과 같은 권한을 가져야 합니다.

• Vault 전반에서 ACL 정책을 광범위하게 생성 및 관리합니다.
• 보안 비밀 엔진을 관리합니다.
• secret/ 경로에서 사용 설정된 키-값 보안 비밀 엔진을 관리합니다.
• secret/admin 경로의 보안 비밀을 읽거나 나열할 수 없습니다.

1. ACL 정책 페이지로 돌아갑니다.

2. ACL 정책 만들기를 클릭합니다.

3. 먼저 정책 이름을 security로 지정합니다.

4. 정책 규칙에서 코드 편집기를 선택하고 다음 정책 코드를 추가합니다.

# List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Deny access to secret/admin path "secret/data/admin" { capabilities = ["deny"] } path "secret/data/admin/*" { capabilities = ["deny"] } # Deny list access to secret/admin path "secret/metadata/admin" { capabilities = ["deny"] } path "secret/metadata/admin/*" { capabilities = ["deny"] }

5. 정책 만들기를 클릭합니다.

보안 비밀 만들기

다양한 정책을 만들었으므로 이제 보안 비밀을 만들어 보겠습니다.

1. Cloud Shell로 돌아가서 다음 명령어를 실행하여 secret/security 경로에 보안 비밀을 만듭니다.

vault kv put secret/security/first username=password vault kv put secret/security/second username=password

2. secret/appdev 경로에 보안 비밀을 만듭니다.

vault kv put secret/appdev/first username=password vault kv put secret/appdev/beta-app/second username=password

3. secret/admin 경로에 보안 비밀을 만듭니다.

vault kv put secret/admin/first admin=password vault kv put secret/admin/supersecret/second admin=password

appdev의 보안 확인

보안 비밀을 만들었으니 이제 이러한 정책이 제대로 적용되는지 확인해 보겠습니다. 먼저 app-dev 사용자로 로그인하여 액세스할 수 있는 항목을 확인합니다.

1. 다음 명령어를 실행하여 app-dev 사용자로 로그인합니다.

vault login -method="userpass" username="app-dev" password="appdev123"

2. 이제 appdev/first 보안 비밀을 가져오려고 시도합니다.

vault kv get secret/appdev/first

다음과 같은 출력이 표시됩니다.

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

3. secret/appdev/beta-app/second에 있는 보안 비밀을 가져옵니다.

vault kv get secret/appdev/beta-app/second

다음과 같은 출력이 표시됩니다.

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. 새 보안 비밀을 만듭니다.

vault kv put secret/appdev/appcreds credentials=creds123

5. 보안 비밀을 폐기합니다.

vault kv destroy -versions=1 secret/appdev/appcreds

6. secret/security에서 보안 비밀을 가져오려고 시도합니다.

vault kv get secret/security/first

다음 오류가 표시됩니다.

Error reading secret/data/security/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/security/first Code: 403. Errors: * 1 error occurred: * permission denied

7. secret/에 있는 모든 보안 비밀을 나열하려고 시도합니다.

vault kv list secret/

다시 오류가 표시됩니다.

Error listing secret/metadata: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata?list=true Code: 403. Errors: * 1 error occurred: * permission denied

좋습니다. secret/appdev 경로에서 보안 비밀을 가져오고 만들 수 있었으며, 이 경로 외부의 보안 비밀에는 액세스할 수 없음을 확인했습니다.

보안 정책 확인

1. 다음 명령어를 실행하여 security 사용자로 로그인합니다.

vault login -method="userpass" username="security" password="security123"

2. 이제 security/first 보안 비밀을 가져오려고 시도합니다.

vault kv get secret/security/first

다음과 같은 출력이 표시됩니다.

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

3. secret/security/second에 있는 보안 비밀을 가져옵니다.

vault kv get secret/security/second

다음과 같은 출력이 표시됩니다.

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. secret/security/supersecure에서 새 보안 비밀을 만듭니다.

vault kv put secret/security/supersecure/bigsecret secret=idk

5. 보안 비밀을 폐기합니다.

vault kv destroy -versions=1 secret/security/supersecure/bigsecret

6. secret/appdev에서 보안 비밀을 읽으려고 시도합니다.

vault kv get secret/appdev/first

다음과 같은 출력이 표시됩니다.

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

7. secret/에 있는 모든 보안 비밀을 나열하려고 시도합니다.

vault kv list secret/

다음과 같은 출력이 표시됩니다.

Keys ---- admin/ appdev/ security/

8. 새 보안 비밀 엔진을 사용 설정합니다.

vault secrets enable -path=supersecret kv Success! Enabled the kv secrets engine at: supersecret/

9. secret/admin/first 보안 비밀을 확인하려고 시도합니다.

vault kv get secret/admin/first

다음 오류가 표시됩니다.

Error reading secret/data/admin/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/admin/first Code: 403. Errors: * 1 error occurred: * permission denied

10. secret/admin에 있는 보안 비밀을 나열하려고 시도합니다.

vault kv list secret/admin

다시 한번 오류가 표시됩니다.

Error listing secret/metadata/admin: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata/admin?list=true Code: 403. Errors: * 1 error occurred: * permission denied

좋습니다. secret/ 경로에서 보안 비밀을 가져오고 만들 수 있으며, 보안 비밀 엔진을 사용 설정할 수 있습니다. 또한 정책에 지정된 대로 secret/admin 경로에 대한 액세스가 거부되었습니다.

관리자 정책 확인

1. 다음 명령어를 실행하여 admin 사용자로 로그인합니다.

vault login -method="userpass" username="admin" password="admin123"

2. 이제 admin/first 보안 비밀을 가져오려고 시도합니다.

vault kv get secret/admin/first

다음과 같은 출력이 표시됩니다.

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:18.521925218Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ==== Data ==== Key Value --- ----- admin password

3. secret/security/first에 있는 보안 비밀을 가져옵니다.

vault kv get secret/security/first

다음과 같은 출력이 표시됩니다.

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. 새 보안 비밀을 만듭니다.

vault kv put secret/webserver/credentials web=awesome

5. 보안 비밀을 폐기합니다.

vault kv destroy -versions=1 secret/webserver/credentials

6. secret/appdev에서 보안 비밀을 가져오려고 시도합니다.

vault kv get secret/appdev/first

다음과 같은 출력이 표시됩니다.

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

7. secret/appdev에 있는 모든 보안 비밀을 나열하려고 시도합니다.

vault kv list secret/appdev/

다음과 같은 출력이 표시됩니다.

Keys ---- appcreds beta-app/ first

8. 모든 정책을 나열합니다.

vault policy list

다음과 같은 출력이 표시됩니다.

admin appdev default default-ceiling demo-policy security root

9. 다음 명령어를 실행하여 정책 값을 텍스트 파일에 복사하고 Cloud Storage 버킷에 업로드합니다.

vault policy list > policies-update.txt gcloud storage cp policies-update.txt gs://$PROJECT_ID

10. gcp 인증 메서드를 사용 설정합니다.

vault auth enable gcp

11. 마지막으로 사용 설정된 인증 방법을 나열합니다.

vault auth list Path Type Accessor Description ---- ---- -------- ----------- gcp/ gcp auth_gcp_faa3d15f n/a token/ token auth_token_066c5ebd token based credentials userpass/ userpass auth_userpass_929fe9bd n/a

좋습니다. 작성한 정책과 관련된 관리자 권한이 있는지 확인했습니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 보안 비밀 정책

경로

security 사용자에게 제공된 정책 코드에서 보셨듯이, 이전에 본 적이 없는 몇 가지 주제가 소개되었습니다. 바로 data/와 metadata/입니다.

metadata/ 경로 엔드포인트는 지정된 위치에 있는 키 이름의 목록을 반환합니다. 또한 이 명령어로는 값 자체에 액세스할 수 없습니다. 쓰기 및 읽기 버전에는 data/가 프리픽스로 붙습니다. 나열, 읽기, 폐기는 다음과 같습니다.

• 쓰기 및 읽기 버전 - data/
• 키 나열 - metadata/
• 읽기 버전 - metadata/
• 보안 비밀 버전 폐기 - destroy/
• 키의 모든 메타데이터 버전 폐기 - metadata/

예를 들어 secret/example에서 보안 비밀에 대한 액세스를 거부하려면 다음 data/를 사용하여 형식을 지정해야 합니다.

path "secret/data/example" { capabilities = ["deny"] }

secret/examples에 대한 목록 액세스를 거부하려면 다음 metadata/를 사용하여 형식을 지정해야 합니다.

path "secret/metadata/examples/*" { capabilities = ["deny"] }

작업 8. 세밀한 제어

Vault는 권한의 표준 모음 외에도 지정된 경로에서 권한을 더 세밀하게 제어할 수 있는 기능을 제공합니다. 경로와 연결된 권한이 파라미터에 대한 권한보다 우선합니다.

파라미터 제약 조건

Vault에서 데이터는 key=value 쌍으로 표현됩니다. Vault 정책은 경로에 대한 권한을 평가할 때 키와 해당 키의 데이터를 기반으로 경로를 추가로 제한할 수 있습니다. 선택적인 세분화된 제어 옵션은 다음과 같습니다.

• required_parameters - 지정해야 하는 파라미터의 목록입니다.
• allowed_parameters - 지정된 경로에서 허용되는 키와 값의 목록입니다.
• denied_parameters - 파라미터 및 값의 목록을 차단 목록에 추가합니다. 여기에 지정된 값은 allowed_parameters보다 우선합니다.

세분화된 제어에 대한 자세한 내용은 세분화된 제어 문서를 확인하세요.

수고하셨습니다

보시다시피 정책은 Vault의 중요한 부분입니다. 루트 토큰을 사용하는 것이 가장 쉽게 시작할 수 있는 방법이지만 Vault에 대한 액세스를 신속하게 제한해야 하며, 이렇게 하는 방법은 정책 시스템을 사용하는 것입니다.

정책의 문법과 기능은 이해하고 사용하기 쉬우며, 모든 인증 방법이 중앙 정책 시스템에 매핑되어야 하므로 이 정책 시스템만 알면 됩니다.

이 실습에서는 정책을 만들고 관리하고, 정책을 사용자와 토큰에 연결하고, 사용자와 토큰의 권한을 확인했습니다.

다음 단계/더 학습하기

Vault에 대한 자세한 내용은 다음 리소스를 확인하세요.

• Vault 시작하기 튜토리얼
• Vault 문서
• Vault 정책 문서
• Vault 정책 튜토리얼

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2026년 6월 4일

실습 최종 테스트: 2026년 6월 4일

Copyright 2026 Google LLC. All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.