Vault の AWS 認証をIAMロールで実装する実務ポイント（Associate対策）

Vault の AWS 認証には IAM と EC2 の2モードがあるが、コンテナやサーバレスでは IAM モードが実務適合しやすい。

IAM 認証は、署名済みの sts:GetCallerIdentity を用いて Vault がクライアントの AWS アイデンティティを検証するのが肝要。

AWS 認証(IAM)の全体像

IAM モードは、クライアントが AWS 署名バージョン4で署名した sts:GetCallerIdentity リクエストを Vault に提出し、Vault がそれを AWS STS に転送して正当性を検証する方式です。Vault 側はクライアントの IAM ロールまたはユーザ ARN を事前にロール設定へバインドしておき、一致すれば Vault トークンを発行します。

リプレイ耐性のため、Vault は X-Vault-AWS-IAM-Server-ID ヘッダ（header_value）を推奨します。サーバ側設定とクライアント側署名に同一値を入れることで、中間者攻撃やリージョン跨ぎのリプレイを抑止します。

• 検証対象は署名済みの sts:GetCallerIdentity。成功すると Caller ARN を取得し、ロールの bound_iam_principal_arn と照合する。
• Vault 側で AWS 資格情報は不要（IAM モード）。ネットワーク的に STS に到達できればよい。
• ロールに紐づくポリシーと TTL が、発行される Vault トークンに適用される。

IAM ログインの信頼チェーン

IAM 認証と他方式の使い分け

Vault の AWS 認証は IAM と EC2 の2モード。さらに非AWSワークロードでは AppRole 等が候補になります。試験でも境界条件（どの方式をどの環境に当てるか）が頻出です。

IAM はタスク実行ロールやLambda実行ロールなど、インスタンスに依存しない実行主体に適合。EC2 はインスタンスID文書によるバインドが強み。AppRole は完全にAWS外でも使えますが、ローテーション運用が別途必要です。

• ECS/EKS/Lambda などインスタンスレス実行環境 → IAM 認証
• 長寿命EC2かつインスタンスメタデータ活用 → EC2 認証
• オンプレ・マルチクラウド・バッチなど IAM が使えない → AppRole

Vault 側の設定手順（IAM ロールバインド）

IAM モードは、基本的に AWS 資格情報のサーバ設定は不要です。まず AWS auth を有効化し、Server-ID を設定してから、IAM ロール（またはユーザ）をバインドした認証ロールを作成します。

ロールでは policies、TTL、再認証可否などを定義します。bound_iam_principal_arn は複数指定が可能で、クロスアカウントも扱えます。

• auth/aws/config/client の iam_server_id_header_value はクライアントと一致させる
• ロールの auth_type=iam を必ず指定（デフォルトと混同しない）
• ポリシーは Vault のアクセス境界。最小権限で設計する

Vault サーバ設定例（IAM モード）

# AWS auth を有効化（パスは必要に応じて変更）
vault auth enable -path=aws aws

# Server-ID ヘッダ値を設定（クライアントが署名時に同値を入れる）
vault write auth/aws/config/client \
  iam_server_id_header_value="vault.example.com"

# アプリ用ポリシー（例）
vault policy write app - <<'EOF'
path "secret/data/app/*" {
  capabilities = ["read"]
}
EOF

# IAM ロールにバインドした認証ロールを作成
vault write auth/aws/role/app \
  auth_type=iam \
  bound_iam_principal_arn=arn:aws:iam::111111111111:role/app-task \
  policies=app \
  max_ttl=1h \
  disallow_reauthentication=true

クライアントからのログイン（IAM サインイン）

クライアントは自分の AWS 実行ロールを用いて署名済みの sts:GetCallerIdentity を生成します。Vault CLI や Vault Agent を使うと、この署名生成と /auth/aws/login への提出を自動で行えます。

AWS 環境変数（またはインスタンス/タスクロール）から認証情報を取得し、Server-ID ヘッダ値を一致させるのがポイントです。

• Vault CLI: AWS SDK を用いて自動署名し、role と header_value を指定してログイン
• Vault Agent: auto_auth.method "aws" type=iam でトークンの自動取得・更新が可能

CLI と Vault Agent の実行例

# CLI 例（AWS_PROFILE / タスクロールなどで認証情報が利用可能であること）
export AWS_REGION=ap-northeast-1
vault login -method=aws role=app header_value=vault.example.com

# 成功すると Vault トークンが返る（-format=json で機械可読）
# vault login -method=aws role=app header_value=vault.example.com -format=json | jq

# Vault Agent 例（/etc/vault.d/agent-iam.hcl）
auto_auth {
  method "aws" {
    mount_path = "auth/aws"
    config = {
      type         = "iam"
      role         = "app"
      header_value = "vault.example.com"
      # 必要に応じて region 等を指定
    }
  }
  sink "file" {
    config = {
      path = "/tmp/vault-token"
    }
  }
}

cache {
  use_auto_auth_token = true
}

vault {
  address = "https://vault.example.com"
}

クロスアカウントと最小権限設計

IAM 認証は、別AWSアカウントのロールにもバインド可能です。bound_iam_principal_arn に対象ロールARNを列挙するだけで、クロスアカウントのアプリからログインできます。assumed-role のセッションARNであっても、Vault は実体のロールARNへ正規化して照合します。

sts:GetCallerIdentity は原則どのプリンシパルでも呼べるため、IAM 認証のために特別なIAM許可を追加する必要はありません。ネットワーク的に Vault から AWS STS へ到達できること、時刻同期、Server-ID の整合が実務上の成否ポイントです。

• 複数ARNの指定で、段階的移行やブルーグリーン運用にも対応しやすい
• Vault ポリシーは最小権限で設計し、トークンTTLも短めに設定する
• 監査ログ（audit device）で /auth/aws/login を必ず可視化

複数プリンシパルへのバインド例

# 複数の IAM ロールを同一 Vault ロールへバインド
vault write auth/aws/role/app \
  auth_type=iam \
  bound_iam_principal_arn=arn:aws:iam::111111111111:role/app-task,arn:aws:iam::222222222222:role/app-task \
  policies=app \
  max_ttl=1h

トラブルシュートと試験で狙われるポイント

実務では Server-ID 不一致、時計ずれ、ARN の型違い（ユーザARNをロールとして登録など）が典型。試験では IAM と EC2 の使い分け、bound_iam_principal_arn、header_value の意味、Vault が AWS 資格情報不要で検証できる点などが問われやすいです。

問題切り分けでは、-format=json での応答確認、audit ログ、そして AWS STS への到達性（プロキシやFW）を順に検査します。

• Server-ID 不一致: auth/aws/config/client とクライアントの header_value を同一に
• 時刻ずれ: NTP を有効化。署名の有効期限が過ぎると認証失敗
• ARN 型: bound_iam_principal_arn は role または user のARN。ポリシーARNではない
• IAM モードは auth/aws/config/client に access_key/secret_key は不要
• Vault トークンのTTL/ポリシーはロールで決まる。AWS 側ポリシーではない

確認用コマンド断片

# 応答の確認
vault login -method=aws role=app header_value=vault.example.com -format=json | jq '.auth.lease_duration,.auth.policies'

# 監査ログ（ファイル監査デバイス例）
vault audit enable file file_path=/var/log/vault_audit.log

tail -f /var/log/vault_audit.log | grep "/auth/aws/login"

問題で確認

よくある質問