Vault Cubbyholeで実現するトークンスコープの一時保管

Cubbyholeは、各トークンに専用のプライベート名前空間を与えるVaultの組み込みシークレットエンジンです。トークンが失効すれば中身も消えるため、短期的なシークレットの保管や受け渡しに適しています。

本稿では、Cubbyholeの仕組み、ライフサイクル、レスポンスラッピングとの連携、実践手順、運用上の制約、試験で問われやすい落とし穴をまとめます。

Cubbyholeの基礎: トークンごとのプライベート保管庫

CubbyholeはVaultにデフォルト搭載されるシークレットエンジンで、各アクセストークンに1つずつ固有の保管領域を割り当てます。あるトークンで書き込んだ値は、そのトークンでのみ読み出せます。他のトークンやポリシーによる委譲でアクセスすることはできません。

APIは単純で、バージョニングやメタデータ管理はありません。TTLはシークレットに付くのではなく、紐づくトークンのライフサイクルに従います。トークンが失効・取り消しされると、Cubbyhole内のデータは自動的に消えます。

• デフォルトマウントパス: cubbyhole/
• アクセス境界: トークン単位 (他のトークンからは不可)
• 用途: 起動時のブートストラップ、短期トークンの一時保管、片道の安全な受け渡しの足場

基本操作 (CLI)

vault write cubbyhole/bootstrap token=child-abc note="startup"
vault read cubbyhole/bootstrap
vault delete cubbyhole/bootstrap

セキュリティ特性とライフサイクル: TTL/取り消し/継承

Cubbyholeの可用期間は、格納したエントリではなく、紐づくトークンに従います。トークンを更新すればデータは維持され、トークンを取り消せば即座に消えます。これにより「置きっぱなし」を避けられます。

親子トークンの関係は注意点です。子トークンは独自のCubbyholeを持ち、親とは分離されています。親トークンの取り消しが子に連鎖する設定では、子も含めて無効化され、各自のCubbyholeも到達不能になります。

• トークン更新でCubbyhole中身は維持される
• トークン取り消し/失効で中身は破棄される
• ポリシーで他者のCubbyholeへのアクセスを付与することはできない
• HA構成・ストレージ種類に依らず、挙動は安定 (Vaultの設計に準拠)

トークンの更新/取り消しとCubbyholeの挙動 (CLI例)

# トークン発行 (例)
vault token create -ttl=1h -policy=default -format=json | jq -r .auth.client_token > parent.token

# 子トークン発行 (親の権限範囲内)
VAULT_TOKEN=$(cat parent.token) vault token create -ttl=15m -format=json | jq -r .auth.client_token > child.token

# 子でCubbyholeへ保存
VAULT_TOKEN=$(cat child.token) vault write cubbyhole/boot key=value

# 親を取り消すと、親由来の子も無効化されアクセス不能に
vault token revoke $(cat parent.token)

# 以降の child.token での read は失敗する想定
VAULT_TOKEN=$(cat child.token) vault read cubbyhole/boot

実践: トークンスコープの一時保管フロー

起動直後のプロセスが、最小権限の子トークンで一時的な設定値や次段の取得トークンを受け取る、というブートストラップでCubbyholeは有効です。配布側は対象プロセスの持つトークンにだけ見える場所へ書き込み、プロセスは起動後すぐ取り出して破棄する、という運用が安全です。

直接のCubbyhole読み書きは「一回限り」ではありません。使い捨てを保証したい場合は、後述のレスポンスラッピングを使います。

• プロセスごとに子トークンを払い出す
• 子トークンのTTLは短めに、必要に応じて更新
• 取り出し後は明示削除、またはトークン取り消しで後始末

CLI/HTTP APIでの一時保管

# CLI: 子トークンで書き込み/読み出し
VAULT_TOKEN=$CHILD_TOKEN vault write cubbyhole/config db_user=app db_pass=s3cr3t
VAULT_TOKEN=$CHILD_TOKEN vault read cubbyhole/config

# HTTP API: 書き込み
curl \
  -H "X-Vault-Token: $CHILD_TOKEN" \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{"db_user":"app","db_pass":"s3cr3t"}' \
  $VAULT_ADDR/v1/cubbyhole/config

# HTTP API: 読み出し
curl -H "X-Vault-Token: $CHILD_TOKEN" $VAULT_ADDR/v1/cubbyhole/config

レスポンスラッピングとCubbyhole: 一回限りの安全な受け渡し

レスポンスラッピングは、Vaultの応答をラップトークンに封入し、一回限りで取り出せるようにする仕組みです。内部的にはCubbyholeが使われ、wrap-ttl内にunwrapされなければ自動的に破棄されます。これにより、シークレットを直接配布せず、トークンのみを配送できます。

配布側は任意の読み取り操作に -wrap-ttl を付与し、受け取り側は vault unwrap または /sys/wrapping/unwrap にラップトークンを渡します。unwrapが成功すると内容が返り、トークンは無効化されます。

• wrap-ttlは短めに設定 (例: 60s〜5m)
• ラップトークンは単回使用。漏えい監視のため監査ログを有効化
• 失敗時のリトライ戦略を決めておく (再ラップ)

レスポンスラッピングのハンドオフ

レスポンスラッピングの例

# 秘密データを読む際にラップ (例: kv v2 上のシークレット)
# ここでは対象エンジンが何であれ、応答をラップトークン化する点がポイント
vault kv get -wrap-ttl=60s kv/app/api
# 出力: wrapping_token=... (一度だけ使用可能)

# 受け取り側: unwrap して中身を取得 (トークンは失効)
VAULT_TOKEN=$WRAPPING_TOKEN vault unwrap

# HTTP APIでも同様
curl -s -H "X-Vault-Token: $VAULT_TOKEN" \
  "$VAULT_ADDR/v1/kv/data/app/api?wrap_ttl=60s"
# レスポンスJSONの auth.client_token がラップトークン

# unwrap
curl -s -H "X-Vault-Token: $WRAPPING_TOKEN" \
  -X POST "$VAULT_ADDR/v1/sys/wrapping/unwrap"

運用と制約: 何を置き、何を置かないか

Cubbyholeは軽量な一時保管に最適ですが、大きなバイナリや長期保管の設定ファイルには不向きです。サイズ上限は実ストレージや運用方針に依存するため、原則として小さなシークレットとトークンを対象にします。

監査ログを有効化しておけば、cubbyhole/ 以下のアクセスも記録されます (データ本体はマスクされます)。漏えい検知、ラップトークンの取り扱い監視に役立ちます。

• 小さな値・短寿命・使い捨てを基本方針に
• 不要になったら明示削除、またはトークン取り消しでクリーンアップ
• 長期保管や共有はKV v2など他エンジンを使用

後始末の明示化

# 取り出し後に削除
VAULT_TOKEN=$CHILD_TOKEN vault delete cubbyhole/config

# 役目が終わった子トークンを取り消す
vault token revoke $CHILD_TOKEN

試験対策: よくある誤解と用語整理

Cubbyholeは「トークンに付随するプライベート保管」であり、ポリシーで他者に見せる設計ではありません。KV v2のような共有・バージョニングと混同しないことが重要です。

レスポンスラッピングは「一回限りの取り出し」を実現するための仕組みで、内部的にCubbyholeを使っている点を押さえてください。wrap-ttl満了やunwrap成功で中身は破棄されます。

• キーワード: per-token isolation, revokeで消える, wrap-ttl, unwrap=single-use
• 設計判断: 共有/長期はKV、単回配送はラッピング、短期の同一トークン内受け渡しはCubbyhole
• 落とし穴: Cubbyholeに置いた時点では単回ではない (単回化はラッピングで)

理解度チェック用ワンライナー

# Cubbyholeはこのトークンでしか読めるべきでない
VAULT_TOKEN=$OTHER_TOKEN vault read cubbyhole/boot  # -> 権限外エラーになる想定

問題で確認

よくある質問