Vault EnterpriseのRGP（Role Governing Policy）：ロール単位の制御を設計・実装する

RGP（Role Governing Policy）は、Vault EnterpriseにおけるSentinelポリシーの一種で、特定の認証ロールから発行されたトークンに対し、追加のガバナンス（時間帯やネットワークなどの条件）を課すための仕組みです。

ACLポリシーで機能的な許可を定義し、EGP/RGPでコンテキストに応じた絞り込みを行うのが実務の定石です。本稿では、Ops視点でのRGPの捉え方、実装ステップ、比較観点、試験対応の勘所をまとめます。

RGPの概要と前提

RGP（Role Governing Policy）はVault Enterprise専用の機能で、Sentinel言語で記述されたポリシーを、認証ロール単位で適用します。ACLで「何をできるか」を定めたうえで、RGPは「いつ・どこから・どの条件なら許可するか」を絞り込む補完層です。RGPは許可を拡張せず、条件に合致しなければリクエストを否認します。

RGPの適用対象は、AppRoleやKubernetes、AWSなどの各認証メソッドに定義されたロールです。対象ロールで発行されたトークンのリクエストに対して評価されます。これにより、人間と機械、CIと本番アプリなど、性質の異なる主体ごとにガバナンスを分離できます。

• Enterprise専用機能（OSS版には非搭載）
• ACLを補完し、より細粒度なコンテキスト制御を付与
• 認証ロール単位での適用（例: auth/kubernetes/role/web）
• 許可の拡張は不可。否認のみを追加可能
• Opsではロール設計とRGPの紐付けが運用品質を左右

ACL・EGP・RGPの違い（どれで何を縛るのか）

Vaultのアクセス制御は多層です。ACLは基本の許可（read/write/listなど）をパス単位で定義します。EGPはエンドポイント（パス）に対してコンテキスト条件を付与し、RGPは認証ロール由来のトークンに対して条件を付与します。運用では、ACLで“できること”を定義し、EGP/RGPで“してよい時/場所/主体”に絞るのが安全です。

資格試験では、ユースケースに即して“どの層で縛るべきか”を選ばせる設問が頻出です。時間帯や発信元ネットワークなど、主体（ロール）に依存する条件はRGP、パスに依存する条件はEGP、と切り分けるのが定石です。

• ACL: パス×能力（capabilities）を定義
• EGP: パスに対する条件（例: 対象エンドポイントの書き込みは就業時間内のみ）
• RGP: ロールに対する条件（例: CIロールのトークンは本番パスには読取のみ）

Vaultリクエストにおける多層ガバナンス（概念図）

RGPの評価スコープと適用上の注意

RGPは、指定した認証ロールから発行されたトークンによるリクエストに対して評価されます。未認証エンドポイントや、対象ロールと無関係のトークンには適用されません。評価結果がdenyであれば、ACLで許可されていても処理は否認されます。

運用上は、ロールを粗くしすぎるとRGPの影響範囲が広がり、意図しない否認が発生しやすくなります。逆に細かく分けすぎるとロール管理が肥大化します。境界（人/機械、CI/本番、Prod/Non-Prod）ごとにロールとRGPをセットで設計すると、影響を読みやすくなります。

• RGPは対象ロール単位で“deny”の文脈を追加する機構
• 未認証リクエストや対象外ロールのトークンには評価されない
• 影響範囲を意識したロール粒度の設計が重要
• ロール更新時はRGPの対象リストも同時に見直すのが安全運用

ロール単位の制御パターン（実務ユースケース）

次のような要件は、RGPでロール単位に制御するのが適しています。ACLでは表現しづらい“いつ/どこから/誰が”の条件を、ロールの性質に応じて実装します。

時間やネットワークに依存する要件は、環境差（本番/検証）や主体の特性（人/機械）で最適な条件が異なりやすいため、ロール分割とRGPの組み合わせが効果的です。

• 就業時間内のみ更新可（例: 人手オペレーション系ロール）
• 発信元CIDR制限（例: 社内IP/特定VPCからのみ許可）
• 高リスク操作のMFA属性要求（例: 人間系ロールのみ要求）
• CIロールは本番パスはreadのみ、書き込みはステージング限定
• 監査・運用ロールは特定ネームスペースのみに限定

RGPの作成・適用・検証（ハンズオン）

例として、人間系のKubernetesロールに対し“平日9:00〜18:00のみ書き込み許可”のガバナンスを追加します。ACL側では必要なcapabilities（read/writeなど）を既に付与済みとし、RGPで時間帯外の書き込みをdenyします。

RGPは“enforcement_level”をsoft-mandatory（違反時に許可しつつ警告）またはhard-mandatory（違反時に否認）で設定できます。段階移行ではsoftで影響を観測し、問題がないことを確認してからhardへ切り替えるのが実務的です。

• Sentinelファイルで条件を定義
• sys/policies/rgpにポリシーを作成
• 対象ロールを指定して適用
• 検証は対象ロールのトークンで実行
• 段階移行はsoft→hardが安全

RGPの定義と適用（例：就業時間内のみwrite許可）

# 1) Sentinelポリシー（office-hours.sentinel）
import "time"

main = rule {
  # 現在時刻（サーバのタイムゾーン/UTCに注意）
  t = time.now()

  # 平日かつ 09:00〜18:00 の時間帯のみ許可
  weekday = t.weekday
  in_office_hours = t.hour >= 9 && t.hour < 18
  is_weekday = weekday >= 1 && weekday <= 5  # 1=Mon ... 5=Fri

  # 書き込み系操作のみ絞り込み（read等は本ポリシーでdenyしない）
  write_ops = ["create", "update", "patch"]
  is_write = rule { request.operation in write_ops }

  # 書き込みであれば時間帯条件を満たす必要あり
  # 書き込み以外の操作（read/list等）はこのRGPでは否認しない
  (is_write and (is_weekday and in_office_hours)) or (!is_write)
}

# 2) RGPの作成（Enterpriseのみ）
# 例: hard-mandatoryで適用。まずはsoftで様子見が推奨
vault write sys/policies/rgp/office-hours \
  [email protected] \
  enforcement_level=hard-mandatory \
  roles="auth/kubernetes/role/human-ops"

# 3) 検証
# 対象ロールで認証し、時間外にwrite操作を試すとdenyとなる
# 時間内はACLで許された操作が実行できる
# ログ/監査ログでRGPによるdenyを確認すること

Ops資格向けポイントと落とし穴

RGPは“ロール由来のトークンに対するコンテキスト制御”である点を押さえてください。EGPはパス単位、ACLは基礎許可です。ユースケースから“何を縛るか（主体か、パスか）”を素早く見抜く力が問われます。

段階導入（soft-mandatory→hard-mandatory）、影響範囲の把握（対象ロールの棚卸し）、監査ログでの検証（deny理由の確認）がOpsの基本動作です。ロール統合/改名時にRGPの対象更新を忘れると、想定外denyが起きやすい点に注意。

• RGPは許可を“広げない”。denyの条件追加のみ
• 主体（ロール）起点の条件はRGP、パス起点の条件はEGP
• enforcement_levelの使い分け（softで観測→hardで強制）
• 影響範囲はロール設計に比例。境界ごとの分離が有効
• 監査ログでの可観測性を前提にロールアウト計画を立てる

問題で確認

よくある質問