Vault × Okta 認証の実務と試験対策：SaaS ID Provider 連携の基本

Vault は複数の認証方式を持ち、Okta とは大きく「Okta 認証メソッド（/auth/okta）」と「OIDC 認証メソッド（Okta を IdP とする SSO）」の2通りで連携できます。

現場ではブラウザベースの SSO（OIDC）が主流ですが、CLI 前提の運用やパスワード＋MFA を Okta 側で統制したい場合に Okta 認証メソッドが有効です。試験では両者の違いと、グループからポリシーへマッピングする考え方が問われやすいです。

試験で問われる観点と全体像

Associate レベルでは、認証メソッドの選択理由、最小限の設定項目、ポリシー適用までの経路を説明できることが重要です。Vault は認証（AuthN）で「誰か」を確かめ、ポリシーで「何ができるか」（AuthZ）を決めます。Okta 連携では、最終的に Vault トークンへどのポリシーを付与するかを設計の中心に置きます。

現場の落とし穴は、グループ名の不一致、リダイレクトURIの欠落、Okta 側スコープ設定不足（groups クレーム未付与）です。これらは試験でも定番の引っかけとして出題されます。

• Auth メソッドの選択軸（UX、MFA、ブラウザ有無、API トークン要否）
• Okta グループから Vault ポリシーへ至るマッピング経路
• OIDC ロールとクレーム（sub, groups）の基本
• 運用でのローテーション（Okta API トークン、OIDC クライアントシークレット）

ポリシーの最小例（読み取り専用パス）

path "secret/data/team/*" {
  capabilities = ["read", "list"]
}

Vault の Okta 連携方式を比較（Okta 認証メソッド vs OIDC SSO）

Okta 認証メソッドは、Vault が Okta API を用いてユーザー名・パスワード（＋Okta 側MFA）を検証します。CLI でもブラウザ不要で動作し、Okta API トークンを Vault に登録します。

OIDC は Okta を OIDC Provider として用いるブラウザベースの SSO です。標準的な OAuth 2.0/OIDC フローでトークンを取得し、Vault はロール設定に基づいてポリシーを付与します。利便性と拡張性が高く、近年はこちらが推奨されることが多いです。

• 業務要件でブラウザが使えるなら OIDC が第一候補
• CLI 専用やシンプルなユーザー/グループ連携なら Okta 認証メソッド
• いずれも最終的には Vault ポリシーに集約する設計が基本

フロー比較（左：Okta 認証メソッド / 右：OIDC）

選択基準の要点（擬似コード的メモ）

# ブラウザ可/SSO要件あり -> OIDC（groupsクレーム/ロール設計）
# ブラウザ不可/CLI特化 -> Okta認証（/auth/okta, APIトークン管理）
# いずれも最終的に Vault Policy の設計が鍵

Okta 認証メソッド（/auth/okta）の設定手順

Okta 側でAPIトークンを発行し、Vault に登録します。Vault はそのトークンで Okta API に対しユーザー認証とグループ取得を行います。ユーザー/グループを Vault のポリシーへマッピングすることで、ログイン後のトークンに権限が付与されます。

本方式はブラウザを介さず CLI で完結します。MFA は Okta 側の設定が有効であれば、API 経由の検証時に適用されます。

• 前提: Vault 管理者トークン、Okta 組織URLとAPIトークン
• ポイント: org_name, api_token, base_url の設定とグループマッピング
• 試験対策: users/ と groups/ の書き込み先を取り違えないこと

最小構成のCLI例

# 1) 認証メソッドの有効化
vault auth enable okta

# 2) Okta 接続設定
vault write auth/okta/config \
  org_name="dev-123456" \
  api_token="<OKTA_API_TOKEN>" \
  base_url="okta.com"   # 組織のドメインに合わせる（例: okta.com）

# 3) グループ→ポリシーのマッピング（Okta側グループ名を使用）
vault write auth/okta/groups/engineering policies="dev"

# 4) 必要なら個別ユーザーの上書き設定
vault write auth/okta/users/alice policies="dev" groups="engineering"

# 5) ログイン（ユーザー自身が実行）
vault login -method=okta username=alice password=<PASSWORD>

OIDC（Okta）を使った SSO 設定手順

Okta を OIDC Provider としてクライアント（Vault）を登録し、クライアントID/シークレットとディスカバリURLを Vault に設定します。Vault OIDC ロールでリダイレクトURI、スコープ（特に groups）を指定し、トークンに付与するポリシーまたは Identity グループ連携を整えます。

CLI での SSO はローカルのコールバックリスナー（デフォルト: 8250）を使います。Okta のアプリ設定にも同一のリダイレクトURIを登録しておく必要があります。

• 前提: Okta OIDC アプリ（Web/Trusted）で client_id/secret 発行、groups クレーム有効化
• Vault 側: /auth/oidc/config と /auth/oidc/role/<name> を設定
• 試験対策: allowed_redirect_uris に localhost:8250/oidc/callback を忘れない

最小構成のCLI例（OIDC）

# 1) OIDC 認証メソッドの有効化
vault auth enable oidc

# 2) OIDC 設定（Okta のディスカバリURLを使用）
vault write auth/oidc/config \
  oidc_discovery_url="https://dev-123456.okta.com" \
  oidc_client_id="<OKTA_CLIENT_ID>" \
  oidc_client_secret="<OKTA_CLIENT_SECRET>" \
  default_role="okta"

# 3) ロール設定（groups クレームを使う）
vault write auth/oidc/role/okta \
  allowed_redirect_uris="http://127.0.0.1:8250/oidc/callback,http://localhost:8250/oidc/callback" \
  user_claim="sub" \
  groups_claim="groups" \
  oidc_scopes="openid,profile,email,groups" \
  policies="dev"   # まずは固定ポリシーで動作確認

# 4) ログイン（ブラウザが開く）
vault login -method=oidc

グループマッピングとポリシー設計の要点

設計の原則は「IdPのグループ → Vault Identity グループ → ポリシー」。OIDC では groups クレームを受け取り、Vault Identity でグループエイリアスを張ると管理が明確になります。Okta 認証メソッドでは /auth/okta/groups/<name> に直接ポリシーを割り当てる形がシンプルです。

ポリシーは業務ロール（例: dev, ops, auditor）単位で定義し、グループからポリシーを参照する形にします。ユーザー個別にポリシーを付けるのは例外対応に留め、異動や組織改編でも影響が最小になるようにします。

• OIDC: Identity グループと group-alias を使うと可視性・再利用性が高い
• Okta 認証: groups/ と users/ の優先度を理解（ユーザー個別設定で上書きされ得る）
• 監査のしやすさを考え、ポリシー名と業務ロール名を対応させる

OIDC: Identity グループとエイリアス設定の例

# 1) Vault 側グループを作成（付与したいポリシーを指定）
vault write identity/group name="eng" policies="dev"

# 2) グループIDを取得
GROUP_ID=$(vault read -field=id identity/group/name/eng)

# 3) OIDC マウントのアクセサを確認
#    （実環境では `vault auth list` の出力から OIDC の accessor を控える）
ACCESSOR=<OIDC_MOUNT_ACCESSOR>

# 4) Okta の groups クレームに載る値（例: okta-eng）でエイリアスを作る
vault write identity/group-alias \
  name="okta-eng" \
  mount_accessor="$ACCESSOR" \
  canonical_id="$GROUP_ID"

トラブルシューティングと運用のコツ

OIDC でログイン後にグループが反映されない場合、Okta アプリのスコープに groups が含まれているか、グループルールでトークンへの groups 付与が有効かを確認します。リダイレクトURI不一致や、時刻ずれ（NTP未同期）も典型的な原因です。

Okta 認証メソッドでは API トークンの失効や権限不足が一因になりがちです。ローテーション計画を持ち、Vault 設定の更新手順を標準化しましょう。

• リダイレクトURIは Okta と Vault で完全一致させる（大小文字・プロトコル含む）
• NTP 同期を維持（OIDC の時刻検証に影響）
• API トークンと OIDC クライアントシークレットの定期ローテーション
• 監査: Vault audit device を有効化し、Auth ログを追えるようにする

確認に使えるコマンド（抜粋）

# 有効な認証メソッドとアクセサ
vault auth list

# OIDC ロールの実体確認
vault read auth/oidc/role/okta

# Identity グループとエイリアスの確認
auth_id=$(vault auth list -format=json | jq -r '."oidc/".accessor')
vault list identity/group-alias/id | true

問題で確認

よくある質問