Vault AppRole 認証の実務設計と試験対策（Associate向け）

AppRoleは、アプリケーションやバッチ、CI/CDなど“人以外”のクライアントがVaultにログインするための認証方式です。RoleID（識別子）とSecretID（認証子）の二要素でサービス用トークンを発行します。

本稿では、公式ドキュメントに沿った安定的な設定項目に限定し、実運用での安全なSecretID配布、レスポンスラッピング、Vault Agentの活用、他方式との使い分けまでを網羅します。

AppRoleの基本と“アプリ向け推奨”の理由

AppRoleは、RoleID（固定の識別子）とSecretID（短命・使用回数制限可能な認証子）を用いて、Vaultがアプリ用のサービス・トークンを発行する仕組みです。Role単位でトークン特性（ポリシー、TTL、最大TTL、更新可否、CIDR制約など）を宣言的に定義できます。

ユーザ対話を前提としないため、プロセス起動時やコンテナ初期化時に安定して使えるのが強みです。Kubernetes AuthやJWT/OIDCが前提を置く環境と異なり、あらゆる実行環境（VM、オンプレ、エッジ）で使える“デフォルト”の選択肢になりやすいのがAppRoleです。

• RoleIDは“識別子”で秘匿対象ではない（とはいえ露出最小化は推奨）
• SecretIDは“認証子”。TTLと使用回数を制限し、流出時の影響半径を縮小
• トークンに付与するポリシーやTTLをロールで一元管理
• レスポンスラッピングとVault Agentの併用で安全かつ自動運用
• Associate試験では、AppRoleが“汎用アプリ向けの推奨”である点と、SecretIDの短寿命・回数制限が頻出

発行フローの全体像（RoleID/SecretID → トークン）

典型フローは、管理面（SecOps/CI）でRoleを定義し、アプリ側にRoleIDを配布。SecretIDはレスポンスラッピング等で安全に一時配布します。アプリはRoleIDとSecretIDでログインし、得たVaultトークンでシークレットを取得します。

重要なのは、SecretIDを“一時的・最小権限・最小回数”で扱うこと。トークン側もポリシーとTTLで範囲・時間を絞り、漏えい時の blast radius を抑えます。

• Role定義時にtoken_policies、token_ttl、token_max_ttl、token_bound_cidrs等を設定
• SecretIDはsecret_id_ttl、secret_id_num_uses、secret_id_bound_cidrsでさらに縮小
• 配布はX-Vault-Wrap-TTLによるラッピングでワンタイム引き渡し
• アプリはauth/approle/loginでサービス・トークンを取得
• Vault Agentのauto-authでトークン更新を自動化可能

AppRoleによる認証とトークン発行（概念図）

SecretID配布とセキュリティ設計の要点

SecretIDは実質的な“パスワード”。最重要は配布経路の安全化と短寿命・回数制限です。レスポンスラッピング（Wrap）を使うと、SecretIDそのものを直接配送せず、短TTL・一回限りのラップトークンで受け渡しできます。

ロール設定では、secret_id_num_uses（例: 1回）、secret_id_ttl（例: 10分）、secret_id_bound_cidrs（利用元CIDR制限）を組み合わせ、漏えい時の影響を局所化します。発行されるトークン側もtoken_ttlとtoken_max_ttl、token_bound_cidrsで裾野を狭めます。

• レスポンスラッピング: X-Vault-Wrap-TTLでWrapトークン発行→受け手がunwrap
• secret_id_num_uses=1でワンタイム化（既定0=無制限は避ける）
• secret_id_ttlを短めに（数分〜十数分）
• secret_id_bound_cidrs / token_bound_cidrsでネットワーク境界を強制
• local_secret_ids=trueでクラスター外使用を不可に（マルチクラスタ運用時に有効）
• bind_secret_id=true（既定）を維持し、RoleID単独ログインは避ける

セットアップ手順（CLI/APIとVault Agent）

以下は安定した基本手順です。プロダクションではCIDR制約やTTL値を環境に合わせて調整してください。APIは/v1/auth/approle配下のパスを使用します。

Vault Agentのauto_authを併用すると、アプリ側はRoleID/SecretIDのファイル読込だけで済み、以降のトークン更新が自動化されます。

• auth/approleをenable → ロール作成 → RoleID/SecretID取得 → login
• SecretIDは-f（generate）とWrapを併用し、平文を移動させない
• ポリシーは最小権限で専用定義。運用ローテーションはCIに組み込む
• トークンはrenewableを前提にVault Agentで自動更新

CLI/API/Agentの最小構成例

# 0) 前提
export VAULT_ADDR=https://vault.example.com
export VAULT_TOKEN=<operator_root_or_admin_token>

# 1) AppRoleを有効化
vault auth enable approle

# 2) 最小権限のポリシー作成（例）
cat > app.hcl <<'HCL'
path "secret/data/app/*" {
  capabilities = ["read"]
}
HCL
vault policy write app app.hcl

# 3) ロール作成（推奨パラメータ例）
vault write auth/approle/role/my-app \
  token_policies="app" \
  bind_secret_id=true \
  secret_id_num_uses=1 \
  secret_id_ttl=10m \
  token_ttl=1h \
  token_max_ttl=4h \
  token_bound_cidrs="10.0.0.0/8" \
  secret_id_bound_cidrs="10.0.0.0/8" \
  local_secret_ids=true

# 4) RoleIDの取得（配布は安全経路で）
ROLE_ID=$(vault read -field=role_id auth/approle/role/my-app/role-id)

echo "$ROLE_ID" > role_id

# 5) SecretIDの発行（Wrapして配布）
WRAP_TOKEN=$(vault write -f -wrap-ttl=5m auth/approle/role/my-app/secret-id | awk '/wrapping_token/ {print $2}')
# 受け取り側:
SECRET_ID=$(VAULT_TOKEN=$WRAP_TOKEN vault unwrap -field=secret_id)

echo "$SECRET_ID" > secret_id

# 6) ログイン（サービストークン取得）
APP_TOKEN=$(vault write -field=token auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID")

echo "$APP_TOKEN" > app.token

# --- 同等のHTTP API例 ---
# ロール作成
curl -sS \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
        "token_policies":"app",
        "bind_secret_id":true,
        "secret_id_num_uses":1,
        "secret_id_ttl":"10m",
        "token_ttl":"1h",
        "token_max_ttl":"4h",
        "token_bound_cidrs":["10.0.0.0/8"],
        "secret_id_bound_cidrs":["10.0.0.0/8"],
        "local_secret_ids":true
      }' \
  $VAULT_ADDR/v1/auth/approle/role/my-app

# RoleID取得
curl -sS -H "X-Vault-Token: $VAULT_TOKEN" \
  $VAULT_ADDR/v1/auth/approle/role/my-app/role-id | jq -r .data.role_id

# SecretID（Wrap）
curl -sS -H "X-Vault-Token: $VAULT_TOKEN" \
  -H "X-Vault-Wrap-TTL: 5m" \
  -X POST $VAULT_ADDR/v1/auth/approle/role/my-app/secret-id | jq -r .wrap_info.token

# ログイン
curl -sS -H "Content-Type: application/json" \
  -X POST \
  -d '{"role_id":"'$ROLE_ID'","secret_id":"'$SECRET_ID'"}' \
  $VAULT_ADDR/v1/auth/approle/login | jq -r .auth.client_token

# --- Vault Agent（auto_auth）例 ---
cat > agent.hcl <<'HCL'
auto_auth {
  method "approle" {
    config = {
      role_id_file_path   = "./role_id"
      secret_id_file_path = "./secret_id"
    }
  }
  sink "file" {
    config = {
      path = "/tmp/app.token"
    }
  }
}
cache {
  use_auto_auth_token = true
}
HCL

vault agent -config=agent.hcl

運用：ローテーション、更新、監査

SecretIDローテーションは自動化が前提です。CIから定期的にSecretIDを発行→Wrapで受け手に渡し→旧SecretIDは破棄、をパイプライン化します。漏えい時はsecret-idアクセスパスでdestroy/revokeできます。

発行されたトークンは、token_ttlとtoken_max_ttlに従い更新可能です。Vault Agentでの自動更新を基本とし、更新不能時（max_ttl到達や権限不足）に備えてヘルスチェックとフォールバックを設けます。

• SecretIDの破棄: auth/approle/role/<role>/secret-id/destroy（ID指定）
• トークン失効: sys/revoke、または関連アクセサでrevoke-prefix
• 監査ログでloginとunwrapを相関させ、配布経路を可視化
• token_period（必要に応じて）で“期限のない更新型”トークンも選択可
• 障害時再起動に備え、RoleIDは恒久保存、SecretIDは都度再取得

他の認証方式との使い分け（Associate対策）

AppRoleは“どこでも動く”のが強み。一方、Kubernetes AuthやJWT/OIDCは環境統合が進むほど運用が軽くなります。試験では適材適所の判断が頻出です。

AppRoleはCI/CDやオンプレVM、エッジでのデフォルト。Kubernetes環境ではまずKubernetes Authを検討し、外部IDプロバイダ統合が進んでいればJWT/OIDCも有力です。TLS証明書方式はクライアント証明書管理が行き届く環境向け。

• “アプリ向けの推奨”としてAppRoleが基準解
• Kubernetes上はServiceAccount連携のKubernetes Authが第一候補
• SaaS連携やフェデレーションはJWT/OIDCが適合
• 証明書運用が成熟していればTLS Cert Authも堅牢

問題で確認

よくある質問