このラボは Google のパートナーである 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 は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

2. ウィンドウで次の操作を行います。

   • Cloud Shell 情報ウィンドウで操作を進めます。
   • Cloud Shell が認証情報を使用して Google Cloud API を呼び出すことを承認します。

接続した時点で認証が完了しており、プロジェクトに各自の 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"}}} 注: Google Cloud における gcloud ドキュメントの全文については、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 フラグを指定すると、多くの設定が安全でないデフォルトになります。

警告: 本番環境では、開発モードのサーバーを実行しないでください。開発モードのサーバーは安全ではなく、再起動するたびにデータが失われます（データがメモリに保存されるため）。開発用またはテスト用としてのみ使用してください。

開発サーバーを起動する

まず、Vault 開発サーバーを起動します。開発用サーバーは、事前構成された組み込みのサーバーです。セキュリティはあまり高くありませんが、Vault をローカルで試すのに便利です。

1. Vault 開発サーバーを起動するには、次のコマンドを実行します。

vault server -dev

Vault サーバーの構成に関する出力が表示されます。Unseal Key と Root Token の値が表示されていることを確認します。

==> 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! 注: 開発サーバーは、すべてのデータをメモリに保存し（暗号化は行われます）、TLS なしで localhost をリッスンし、自動的にシールを解除して、シール解除キーとルート アクセスキーを表示します。 注: 安全ではないオペレーション

本番環境で Vault 開発サーバーを実行しないでください。ここでは、このデモのシール解除プロセスを簡素化する目的でのみ、このサーバーを使用しています。

Vault 開発サーバーが起動したので、アクセス設定を続行できます。

2. 新しい Cloud Shell タブを開きます。

3. ターミナル出力から export VAULT_ADDR … コマンドをコピーして実行します。これにより、Vault クライアントが開発サーバーと通信するように構成されます。

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 は初期化中に ルートポリシーを作成します。ルートポリシーは、すべてのパスに対してすべての操作を実行できます。このポリシーは、初期化が完了したときに表示されるルートトークンに割り当てられます。これにより、シークレット エンジンを有効にし、ポリシーを定義し、認証方法を構成するための最初のスーパーユーザーが提供されます。

Vault は デフォルト ポリシーも作成します。デフォルト ポリシーは、トークンがそれ自体を反映して管理できるようにする一連の共通機能を定義します。このポリシーはルートトークンにも割り当てられ、デフォルトですべてのトークンにアタッチされます。

ポリシーの構文

ポリシーは HCL または JSON で記述し、ユーザーまたはマシンがアクセスできる Vault 内のパスを記述します。ポリシーはパスのリストを定義します。各パスは、許可される機能を表現します。Vault はデフォルトでパスに対する機能を拒否して、デフォルトで保護されるようにするため、パスに対する機能は明示的に付与する必要があります。

ポリシーの基本形式は次のとおりです。

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

パス "secret/foo" に対する読み取り機能を付与する非常にシンプルなポリシーを次に示します。

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

このポリシーがトークンに割り当てられると、トークンは "secret/foo" から読み取ることができます。ただし、このトークンでは "secret/foo" の更新や削除はできません。これは、それらの機能が許可されていないためです。ポリシーはデフォルトで拒否する設定になるため、トークンは Vault 内で他のアクセス権を持ちません。つまり、Vault ポリシーが空の場合、システムで権限は付与されません。

機能

ポリシーでは、1 つ以上のパスと、許可される機能のリストを定義します。各パスでは、許可（または拒否）される操作をきめ細かく制御する 1 つ以上の機能を定義する必要があります。以下の例でわかるように、機能は常に文字列のリストとして指定され、機能が 1 つしかない場合でも同様です。これらの機能のほとんどは、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"] } }

ポリシーはパスベースのマッチングを使用して、一連の機能をリクエストに照らして判定します。ポリシーのパスでは、照合する正確なパスを指定することも、Vault に接頭辞の一致を使用するよう指示するグロブ パターンを指定することもできます。

たとえば、このポリシーでは "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"] }

最後に、+ を使用して、1 つのパスセグメント内の任意の数の文字を表すことができます。以下のポリシーでは、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 Secret Engine のセクションを作成します。

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

テンプレート化されたポリシーについて詳しくは、テンプレート化されたポリシーのドキュメントをご覧ください。

注: テンプレート化されたポリシーを開発する場合は、可能な限り ID を使用してください。各 ID はユーザーごとに一意ですが、名前は時間の経過とともに変更される可能性があり、再利用されることもあります。これにより、特定のユーザー名やグループ名が変更された場合でも、ポリシーが目的のエンティティやグループにマッピングされます。

組み込みのポリシー機能を確認する

ポリシーの記述方法を確認したところで、ルートポリシーとデフォルト ポリシーの機能について簡単に見ていきましょう。

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"] 注: アタッチされているポリシーは ルートポリシーです。

2. ルートポリシーでは 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..

次に、デフォルト ポリシーのみがアタッチされたユーザーとして同じコマンドを実行してみます。

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 注: アタッチされているポリシーはデフォルト ポリシーです。

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. ラボで先ほど保存したルートトークンを入力し、[Sign In] をクリックします。

次のように Vault 開発サーバーが表示されます。

開発サーバーのウェブ UI にログインしたので、次のセクションに進みます。

新しいポリシーを作成します。

1. ホームページから [Access control] をクリックします。default と root の ACL ポリシーが表示されます。

2. [Create ACL policy] をクリックします。

3. まず、ポリシーに demo-policy という名前を付けます。

これで、ポリシーの作成を開始できます。前のセクションでは、sys/mounts パスにアクセスしてシークレット エンジンを読み取ることができませんでした。その機能を追加しましょう。

4. [Policy rules] で [Code editor] を選択し、次のプレースホルダ コードを追加します。

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

5. まず、path を、先ほどアクセスしようとした sys/mounts パスに更新します。

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

6. 次に、機能を追加します。Vault はこのパスに対して GET API 呼び出しを試みるため、read 機能が必要です。read を機能リストに追加します。

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

ポリシーは次のようになります。

7. [Create policy] をクリックします。

次に、このポリシーを、先ほど作成した example-user に関連付ける必要があります。

8. [Back to main navigation] をクリックします。

9. 左側のペインで [Access > Authentication methods] をクリックし、[userpass] をクリックします。

10. example-user ユーザーの横にある [More] メニューをクリックし、[Edit user] を選択します。

11. パスワード フィールドの下にある [Tokens] をクリックして、サブメニューを開きます。

12. [Generated Token's Policies] で、作成したポリシー（demo-policy）を追加し、[Add] をクリックします。

13. [Save] をクリックします。

これで、新しいポリシーを作成して、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. [Edit policy] をクリックします。

22. [Policy] ボックスで、作成した既存のポリシーの下に次のプレースホルダ コードを追加します。

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. [Save] をクリックします。

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 パスに対する読み取りと一覧表示のアクセス権を付与するポリシーも追加しました。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ポリシーを作成する

タスク 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 はトークンを生成し、構成されたポリシーのリストをトークンに割り当てて、そのトークンを認証されたユーザーに返します。

トークン

トークンには 2 つのポリシー セットがあります。1 つは、エンティティとそのグループに基づいて計算されるアイデンティティ ポリシー、もう 1 つは、ログイン方法に基づいて定義されるか、API を介して明示的にトークンが作成される場合はトークン作成時の入力となるトークン ポリシーです。以下は、トークン ポリシーのみに関するものです。トークンのアイデンティティ ポリシーは、基盤となるエンティティ、グループ、グループ メンバーシップを変更する場合を除き、制御できません。

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 ポリシーを作成する

このラボでは、admin ユーザーが次の操作を行えるようにする必要があります。

• システム ヘルスチェックを読み取る
• Vault 全体で広く ACL ポリシーを作成して管理する
• Vault 全体で広く認証方法を有効化して管理する
• secret/ パスで有効になっている Key-Value シークレット エンジンを管理する

1. Vault UI の左側のペインから [ACL policies] に移動します。default、default-ceiling、demo-policy、root の各ポリシーが表示されます。

2. [Create ACL policy] をクリックします。

3. まず、ポリシーに「admin」という名前を付けます。

4. [Policy rules] で [Code editor] を選択し、次のポリシーコードを追加します。

# 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. [Create policy] をクリックします。

appdev ポリシーを作成する

このラボでは、appdev ユーザーが次の操作を行えるようにする必要があります。

• シークレット エンジンの作成、読み取り、更新を行う
• secret/appdev/ パスで有効になっている Key-Value シークレット エンジンを管理する

1. [ACL Policies] ページに戻ります。

2. [Create ACL policy] をクリックします。

3. まず、ポリシーに「appdev」という名前を付けます。

4. [Policy rules] で [Code editor] を選択し、次のポリシーコードを追加します。

# 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. [Create policy] をクリックします。

security ポリシーを作成する

このラボでは、security ユーザーが次の操作を行えるようにする必要があります。

• Vault 全体で広く ACL ポリシーを作成して管理する
• シークレット エンジンを管理する
• secret/ パスで有効になっている Key-Value シークレット エンジンを管理する
• secret/admin パスでシークレットの読み取りと一覧表示のアクセス権は持たない

1. [ACL Policies] ページに戻ります。

2. [Create ACL policy] をクリックします。

3. まず、ポリシーに「security」という名前を付けます。

4. [Policy rules] で [Code editor] を選択し、次のポリシーコードを追加します。

# 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. [Create policy] をクリックします。

シークレットを作成する

さまざまなポリシーを作成したので、次はシークレットを作成します。

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 パスでシークレットを取得、作成できました。また、それ以外のパスのシークレットにはアクセスできないことを確認できました。

security のポリシーを確認する

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 パスへのアクセスは拒否されました。

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 Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2026 年 6 月 4 日

ラボの最終テスト日: 2026 年 6 月 4 日

Copyright 2026 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。