Vault AWS シークレットエンジンで発行する IAM 一時クレデンシャル: 実務と試験対策

AWS の長期アクセスキーをやめ、Vault から動的に STS クレデンシャルを払い出すのが現在の定石です。

本稿は Associate / Ops レベルの試験を意識しつつ、最短で正しく動かすための実務ノウハウをまとめています。

基本概念と出題ポイント

Vault の AWS シークレットエンジンは、AWS 側の API（STS、IAM）を呼び出し、動的にクレデンシャルを生成します。最も実務的なのは assumed_role（既存の IAM ロールを STS AssumeRole で引き受ける方式）です。

Vault で発行される一時クレデンシャルにはリース（lease）が付き、TTL 超過で自動失効します。AWS 側のセッションはロールの MaxSessionDuration に縛られるため、Vault の TTL 設計は常に AWS 側の上限以下に収める必要があります。

試験では、静的シークレットとの違い、TTL/リースの扱い、assumed_role と iam_user の使い分け、最小権限（Least Privilege）設計が頻出です。

• 動的発行: 読み取りごとに新規クレデンシャルを生成
• リース管理: Vault が TTL と失効をトラッキング
• assumed_role 推奨: 長期キーを持たず STS に集約
• TTL は AWS ロールの MaxSessionDuration 以下で設定
• 早期失効: STS セッションは基本的に即時無効化できない（満了待ち）

Vault と AWS STS のやり取り（概念）

assumed_role と他方式の使い分け（比較表つき）

プロダクションでは基本的に assumed_role 一択です。理由は、長期キーを保有せず、発行・失効をセッションで完結できるためです。例外的に、外部要件でアクセスキーの形が必要な場合のみ iam_user を検討します。federation_token は一時的な制約付き利用者の付与に使えますが、既存ロール設計があるなら assumed_role の方が単純です。

• 原則: assumed_role（STS）を優先
• 例外: レガシー互換が必須なら iam_user
• 短期・限定権限: federation_token でポリシーを付与して短期利用

最小権限での IAM 設計（Vault が必要とする権限）

Vault は aws/config/root に設定した認証情報で AWS API を呼びます。assumed_role を使う場合、Vault 側には sts:AssumeRole のみを許し、ターゲットロールの信頼ポリシーで Vault の実行主体（IAM ユーザー/ロール）を許可するのが最小です。

iam_user を使う場合は、iam:CreateUser/iam:CreateAccessKey/iam:DeleteAccessKey などが追加で必要になります。実務でも試験でも、不要な権限を含めない点が重要です。

• Vault 実行主体 → sts:AssumeRole のみ（assumed_role のみ利用時）
• ターゲットロールの信頼ポリシーに Vault 実行主体を明示
• iam_user を併用するなら IAM 権限を追加し、パス/タグでスコープ制限

Vault 用 IAM ポリシー例（assumed_role のみを許可）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAssumeSpecificRoles",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": [
        "arn:aws:iam::111122223333:role/ProdAppReadOnly",
        "arn:aws:iam::111122223333:role/ProdAppRW"
      ]
    }
  ]
}

-- ターゲットロールの信頼ポリシー（抜粋） --
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/VaultRunner" },
      "Action": "sts:AssumeRole"
    }
  ]
}

導入手順（最短コースで動かす）

以下は assumed_role を使った最小構成の例です。まず Vault に AWS シークレットエンジンを有効化し、root 設定に AWS 側の実行資格を設定します。続いて、Assume したいターゲットロールを紐づける Vault ロールを作成します。

TTL は default_sts_ttl と max_sts_ttl を明示し、AWS 側ロールの MaxSessionDuration を超えない値にします。発行後は lease_id で追跡できます。

• aws/config/root は最小権限の実行主体で設定
• Vault ロールごとに role_arn・TTL を明示
• 発行・更新・失効の動作をテストで検証

Vault CLI（assumed_role で 30 分 TTL のクレデンシャル発行）

# 1) AWS Secrets Engine を有効化
vault secrets enable aws

# 2) 実行用クレデンシャルを設定（環境に応じて region など調整）
vault write aws/config/root \
  access_key="AKIA..." \
  secret_key="<REDACTED>" \
  region="ap-northeast-1"

# 3) Vault ロール作成（ターゲットの IAM ロールを Assume）
vault write aws/roles/app-readonly \
  credential_type=assumed_role \
  role_arn="arn:aws:iam::111122223333:role/ProdAppReadOnly" \
  default_sts_ttl="30m" \
  max_sts_ttl="1h"

# 4) 一時クレデンシャルを発行
vault read aws/creds/app-readonly
#=> access_key, secret_key, security_token, lease_id, lease_duration などが返る

# 5) リースの更新（AWS 側ロールの MaxSessionDuration を超える更新は不可）
vault lease renew <lease_id>

# 6) 失効（assumed_role は即時無効化できず、以降の払い出しを止めるのみ）
vault lease revoke <lease_id>

リース、TTL、失効の正しい理解

Vault は発行したクレデンシャルにリースを付与し、TTL 超過で自動的に失効扱いにします。assumed_role の場合、AWS 側のセッションは発行時点の DurationSeconds に従い、早期取り消しは基本的にできません。Vault の revoke は、そのシークレットをこれ以上配布しないという管理上の失効であり、既に発行された STS セッションを直ちに無効化するものではありません。

iam_user の場合は DeleteAccessKey で即時無効化が可能です。用途に応じて、即時失効の要件が強いときのみ iam_user を検討します。

• TTL 上限は AWS ロールの MaxSessionDuration に従う
• Vault の renew は AWS 上限内でのみ成功
• assumed_role の早期無効化は不可（設計で短め TTL＋頻繁発行を検討）
• 即時失効要件が強い場合は iam_user（要運用コスト）

運用の落とし穴と試験対策チェックリスト

実運用では TTL と AWS 側の MaxSessionDuration の不一致、ターゲットロールの信頼ポリシー漏れ、リージョン/エンドポイント設定ミスが典型的なハマりどころです。試験では、assumed_role が推奨である点、Vault は STS の上限を超えられない点、静的キーと動的キーの管轄が異なる点が問われやすいです。

• TTL は AWS ロール設定の上限以下に。超えると STS がエラー
• 信頼ポリシーに Vault 実行主体を忘れない
• aws/config/root の資格情報は最小権限で。監査ログを有効化
• マルチアカウントはアカウントごとにロールを用意し Assume で横断
• エラーハンドリング: STS レート制限と一時的失敗にリトライ設計
• 試験キーワード: dynamic secrets, leases, TTL, assumed_role, least privilege

問題で確認

よくある質問