Vault Capabilities 一覧と設計実務（CRUD+LIST 他）

Vault のアクセス制御は、ポリシー内で付与する Capabilities によって決まります。単なるCRUDに見えて実は評価順序やsudo保護などの独自ルールがあり、試験でも実務でも頻出です。

ここでは公式ドキュメントの挙動に基づき、create/read/update/delete/list/sudo/deny を中心に、最小権限での設計、ワイルドカードの使い分け、検証コマンドまでを一気に整理します。

Vault ACL Capabilities 概要

Vault のポリシーは path ごとに Capabilities を付与して権限を定義します。代表的なものは create、read、update、delete、list、sudo、deny です。評価は複数ポリシーの合算で行われ、deny が1つでも含まれると無条件に拒否されます。

sudo は一部の管理系エンドポイント（sys/ 配下など）に必要な特権で、通常の read/write だけでは到達できません。list はリスト取得専用の能力で、read とは別物です。

• create: 新規作成に相当する書き込みを許可
• read: 値の読み取りを許可
• update: 既存の値の更新や各種書き込み操作を許可（実装により create と同時に必要になる場合あり）
• delete: 削除操作を許可
• list: キー名やパスの一覧取得を許可（read では代替不可）
• sudo: sys/ など sudo 保護されたエンドポイントへの操作を許可（併せて create/update/read 等も必要）

Capabilities の評価フロー（簡略）

最小権限ポリシー例（HCL）

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

# 特定サブパスは明示拒否（deny は最優先）
path "secret/data/app/prod/*" {
  capabilities = ["deny"]
}

# 管理操作用（sudo が必要な sys/ 配下）
path "sys/auth/*" {
  capabilities = ["sudo", "create", "read", "update", "delete", "list"]
}

CRUD+LISTの使い分けと実務パターン

一覧取得は list、読み取りは read と分かれている点が最大のつまずきどころです。read を持っていても list が無ければパス一覧は取れません。逆に list だけでは値は読めません。

書き込み系は実装により create と update の要求が分かれる場合があります。設計段階で対象バックエンドの要件を確認し、迷う場合は create と update をセットで付与します。削除は delete が必要です。

• 読み取り専用: read のみを付与（list は付けない）
• 閲覧と一覧: read と list を付与
• フル書き込み: create と update をセットで付与（必要に応じて delete も）
• 最小権限: パスはできるだけ狭く、deny で明確に拒否

CLI での典型操作と必要権限

# 新規/更新（create/update）
vault kv put secret/app api_key=abc123

# 読み取り（read）
vault kv get secret/app

# 削除（delete）
vault kv delete secret/app

# 一覧（list）: 末尾のスラッシュに注意
vault kv list secret/

# 自分のトークンが特定パスで持つ権限を確認
vault token capabilities secret/data/app

パス指定とワイルドカード設計

Vault のポリシーはパス単位で評価され、複数の path ブロックがマッチした場合は能力を合算します。最長一致が優先されますが、deny は常に最優先で拒否します。

広いワイルドカードと、狭い例外指定（deny など）を組み合わせて、チーム単位の委譲と機密サブパスの遮断を両立させます。

• 最長一致を活用して例外パスを上書き
• チーム別やアプリ別にプレフィックスを設ける
• deny は強力。テスト環境での意図せぬ拒否に注意
• 一覧専用や読み取り専用のポリシーを分離して付与

ワイルドカードと例外指定の組み合わせ

# チームAは team-a/ 配下にフル権限
path "secret/data/team-a/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# ただし本番サブパスは明示拒否
path "secret/data/team-a/prod/*" {
  capabilities = ["deny"]
}

# 一覧だけ許可したい汎用閲覧者
path "secret/data/*" {
  capabilities = ["list"]
}

sys/ と sudo が関わる運用操作

シークレットエンジンや認証メソッドの有効化・無効化など、管理操作は sys/ 配下のエンドポイントで実行され、sudo が必要です。sudo だけでは不十分で、目的の操作に応じて create/update/read/delete も併せて付与します。

運用者用ポリシーは運用範囲を限定した sys/ パスにのみ sudo を与え、必要最低限の期間・トークンで使用するのが安全です。

• シークレットエンジン有効化: sys/mounts/*（sudo + create）
• 認証メソッド有効化: sys/auth/*（sudo + create）
• 設定変更・無効化: 該当 sys/ パスで sudo + update/delete
• 誤付与防止: ワイルドカードで広く sudo を与えない

運用者向けポリシーと実行例

# 認証メソッド管理
path "sys/auth/*" {
  capabilities = ["sudo", "create", "read", "update", "delete", "list"]
}

# シークレットエンジン管理
path "sys/mounts/*" {
  capabilities = ["sudo", "create", "read", "update", "delete", "list"]
}

# 認証メソッドの有効化（例）
vault auth enable userpass

# KV エンジンの有効化（例）
vault secrets enable -path=secret kv

権限の検証とトラブルシュート

思った通りに権限が効かない場合は、まず自トークンの Capabilities を確認します。CLI の vault token capabilities、または API の sys/capabilities-self を使うと評価結果を即時に確認できます。

Vault は情報漏えい防止のため、権限不足時に 404 を返すことがあります。存在しないのか権限が無いのか判別しづらいため、capabilities の確認が有効です。

• capabilities-self で現在トークンに対する評価を確認
• 404 は権限不足の可能性あり。即座にポリシーを見直す
• deny がどこかに混じっていないか長いパスから順に確認
• 最長一致の勝ち方を意識して例外パスを先に検証

検証コマンド例

# 現在ログイン中のトークンでのパス評価
vault token capabilities secret/data/app

# 明示トークンで評価（別トークンを指定）
vault token capabilities s.XXXXXXXX secret/data/app

# API で自己トークンの capabilities を確認
curl \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --request POST \
  --data '{"paths":["secret/data/app"]}' \
  $VAULT_ADDR/v1/sys/capabilities-self

Associate試験向けチェックポイント

list と read は別物。一覧には list が必須です。deny は常に最優先で、どこか1カ所でもあれば拒否されます。sudo は sys/ など管理系で必要となり、sudo 単独ではなく create/update 等を併せて付与します。

ワイルドカードと最長一致、複数ポリシーの合算、capabilities-self による検証は頻出テーマです。最小権限の原則でパスを狭く切り、例外は deny や個別パスで上書きします。

• 一覧取得に list、データ取得に read。両方必要なら両方付与
• deny は最優先。デバッグ時はまず deny の有無を確認
• sudo は管理操作用。対象 sys/ パスを広く取り過ぎない
• create と update はセットで付与するのが無難（実装差吸収）
• capabilities-self と token capabilities を使って即時検証

確認用ミニポリシー（チェックリストに沿った最小例）

# 閲覧＋一覧のみ
path "secret/data/app/*" {
  capabilities = ["read", "list"]
}

# 管理操作は別ポリシーで限定的に付与
path "sys/auth/userpass" {
  capabilities = ["sudo", "create", "read", "update"]
}

問題で確認

よくある質問