Vault Root Token: 最高権限とベストプラクティス

Root TokenはVaultでもっとも強力なトークンで、sys/配下の操作を含む全機能に対するsudo権限を持ちます。便利な反面、誤用や漏えいはそのままクラスタ全体の危機に直結します。

この記事では、Root Tokenの正体、最小権限設計に向けたブートストラップ、失効・再生成手順(generate-root)、試験で狙われやすい論点をまとめます。内容は公式ドキュメントの安定機能を前提にしています。

Root Tokenの正体と権限モデル

Vaultの初期化時に発行されるInitial Root Tokenは、ポリシー上はpath "*" に対するcreate/read/update/delete/list/sudoを含む全権を持つ、事実上の最高権限トークンです。多くのsys/系エンドポイントはsudoが必須であり、Root Tokenはこれらを無制限に実行できます。

Root Tokenは日常運用用ではありません。初期セットアップで監査と認証を整備したら、広い権限の管理者トークンへ引き継ぎ、Rootは失効させるのが基本方針です。実環境ではRoot Tokenが失効しない(無期限扱い)構成もあるため、保持期間に依存せず明示的なrevokeを前提にしてください。

• 初期化時に一度だけ生成されるInitial Root Tokenを受け取る
• sys/配下の操作やバックエンドの有効化/無効化などsudo必須操作をすべて実行可能
• 無期限に近い扱いになりやすいので、原則として保管せず必要時に再生成する運用に寄せる

初期化直後のブートストラップ手順

Initial Root Tokenを受け取った直後にやるべきことは、監査の有効化、認証方式の準備、ACLポリシー作成、管理者ロールの構築、そしてRootの役割終了(失効)です。Rootを長く持たない流れを確立すれば、漏えい時の被害半径を最小化できます。

実務での安全な流れは次のとおりです。1) auditデバイスを最初に有効化、2) 必要なSecrets Engine/Auth Methodを有効化、3) 管理者/運用者用のACLポリシーを作成、4) 認証方式(OIDC/LDAP/AppRole)を構成し管理者トークンを発行・検証、5) Root Tokenを失効。

• 最初にauditを有効化し、以後の操作を必ず記録する
• Auth Method(OIDC/LDAP/AppRole)とACLポリシーを整備して日常運用の入口を用意する
• 管理者トークンでsudoが本当に必要なパスだけに限定付与する
• Root Tokenはブートストラップが終わり次第revokeする

ブートストラップの流れ(概要)

運用ベストプラクティス

Root Tokenは「原則保管しない・必要なら再生成する」方針が安全です。自動化や日常運用にRootを用いないでください。Rootが必要な作業はRunbook化し、発行から失効までの所要時間を最短化します。

sudoが本当に必要な操作(sys/auth, sys/mount, sys/policies等)を棚卸しし、管理者ポリシーに限定的なsudoだけを付与します。監査ログは最初に有効化し、Root使用は必ず監査対象にします。

• Rootは自動化・CI/CD・アプリから絶対に使用しない
• 管理者ポリシーに限定sudoを付与し、path単位で最小権限化
• Root使用はチケット/承認フロー(ブレークグラス)と監査でカバー
• トークンは環境変数やファイルに残さない。渡す場合はラップトークンを用いる
• Enterprise利用時はNamespace境界で権限をさらに分離

失効・ローテーション・再生成(generate-root)

Root Tokenの基本は明示的revokeです。既存Rootでログイン中ならvault token revoke -self、別セッションからならvault token revoke <token>で失効します。漏えい疑い時は直ちにrevokeし、必要なら再生成します。

再生成はvault operator generate-rootを用います。OTP方式では、1) 初期化(-init)でnonceとOTPを取得、2) 所定のクォーラム数のUnseal Key(またはリカバリーキー)保有者が順番にキーを適用してエンコード済みトークンを完成、3) OTPでデコードして新しいRoot Tokenを取り出します。作業後は速やかに目的操作を終え、Rootを再度revokeしてください。PGP鍵を使って復号可能者を限定する運用も一般的です。

• 失効: vault token revoke -self または vault token revoke <token>
• 開始: vault operator generate-root -init -otp → nonceとOTPを受領
• 進行: vault operator generate-root -nonce <nonce> を実行し、クォーラム分のUnseal/Recoveryキーを順次入力
• 復号: 得られたエンコード値を vault operator generate-root -decode=<value> -otp=<otp> で復号
• 中止: vault operator generate-root -cancel -nonce <nonce>

例: OTP方式でRoot Tokenを一時再生成する手順

# 1) 初期化: nonceとOTPを取得
$ vault operator generate-root -init -otp
Nonce         : 9b1d... (記録)
One-time OTP : c2VjdXJlLW90cA== (記録)

# 2) クォーラム分のキーを順次適用
$ vault operator generate-root -nonce=9b1d...
Unseal Key (will be hidden): <キー1を入力>
Progress: 1/3
$ vault operator generate-root -nonce=9b1d...
Unseal Key (will be hidden): <キー2を入力>
Progress: 2/3
$ vault operator generate-root -nonce=9b1d...
Unseal Key (will be hidden): <キー3を入力>
Progress: 3/3
Encoded Token: eyJlbmNvZGVkX3Jvb3QiOi... (記録)

# 3) 復号してRoot Tokenを取り出す
$ vault operator generate-root -decode=eyJlbmNvZGVkX3Jvb3QiOi... -otp=c2VjdXJlLW90cA==
Root Token: s.zwJ9... (用途限定で使用)

# 4) 目的操作完了後に明示失効
$ VAULT_TOKEN=s.zwJ9... vault token revoke -self

検証・トラブルシュート: 何がRoot専用かを見極める

どの操作にsudoが必要かはpath-helpで確認できます。sudoが必要なエンドポイントを通常トークンで叩くとpermission deniedになります。管理者ポリシーにsudoを付けるのは、そのpathに限定してください。

トークンの状態はvault token lookupで、権限はvault capabilitiesで確認します。Root使用時は監査ログで該当操作を追跡できることも検証ポイントです。

• sudo要否の確認: vault path-help sys/auth, sys/mount など
• 権限の確認: vault capabilities <token> <path>
• トークン情報: vault token lookup
• 権限エラー時はACLポリシーにsudoを追加する前に、本当にsudoが必要かをpath-helpで再確認

試験(Associate/Ops)で問われやすいポイント

試験では、Root Tokenの用途を初期ブートストラップに限定し、監査→認証→ポリシー→Root失効の順序を理解しているかが頻出です。generate-rootはクォーラムのキー保有者が関与する多段プロセスで、OTPやPGPを使った安全な配布を問われることがあります。

sudoとrootの違い、Auth Methodで得た管理者トークンに限定的sudoを付ける設計、Rootを自動化に使わないこと、Unseal/Recoveryキーはトークンではないことなど、基本用語の取り違えもよく狙われます。

• 最初にauditを有効化してから設定を進める
• Rootはブートストラップ後にrevoke。日常は管理者トークンで実施
• generate-rootはクォーラム必須。OTPで復号、PGPで宛先限定可
• sudoが必要なpathはsys/*等。path-helpで要件を確認
• Unseal/Recoveryキーとトークンは別物で、用途も管理も異なる

問題で確認

よくある質問