Dynamic Secrets の全体像: 短命クレデンシャルの利点を実務と試験観点で押さえる

Dynamic Secrets は「要求時に発行され、期限で自動失効する」短命クレデンシャル。漏えいリスクと運用コストを同時に下げられるのが最大の利点です。

本稿は Vault Associate / Operations レベルで問われやすい概念と運用パターンに絞り、CLI/API の手順と比較表、ASCII 図で全体像をクリアにします。

1. Dynamic Secrets の基本と短命クレデンシャルの価値

Vault の Dynamic Secrets は、リクエストごとに固有の資格情報をバックエンドで即時生成し、TTL に達すると自動で無効化または削除されます。これにより、長期共有パスワードのように回収し忘れが残らず、漏えい時の被害範囲を最小化できます。

重要な点は、発行と失効が Vault の Lease 管理下にあることです。発行時に lease_id と lease_duration が付与され、クライアントは必要に応じて更新や明示的な失効が可能です。監査ログとも親和性が高く、誰がいつどの権限を使ったかを追跡できます。

• 主な対象: Database、Cloud (AWS/Azure/GCP)、PKI、SSH
• 失効の自動化: TTL 経過で自動 revoke。明示的 revoke も可能
• 権限の最小化: ロール単位で絞り、都度払い出し
• 監査容易性: 発行・更新・失効がすべて監査対象

要求時発行と自動失効の流れ

最小構成の例 (Database Secrets Engine / Postgres)

vault secrets enable database

vault write database/config/my-postgres \
  plugin_name=postgresql-database-plugin \
  allowed_roles=readonly \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=verify-full" \
  username="vault_admin" \
  password="s3cr3t"

vault write database/roles/readonly \
  db_name=my-postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl=1h \
  max_ttl=24h

# 短命クレデンシャルの取得
vault read database/creds/readonly
# 出力例: username, password, lease_id, lease_duration, renewable など

2. TTL/Lease のキホン: default_ttl, max_ttl, renew, revoke

Dynamic Secret は lease_id と lease_duration を伴います。lease_duration は発行時の実効 TTL で、必要に応じて lease renew が可能です。ただし、更新はロールに定義された max_ttl およびシステムの最大 TTL を超えられません。

renew が不可のケースは、renewable=false のリー ス、上限を超える延長、またはバックエンド仕様上の制約です。期限切れに達すると Vault は対象システム側の資格情報を無効化または削除します。トークンの TTL とシークレットの TTL は別物で、どちらかが先に失効すると取得・更新に影響します。

• 重要フィールド: lease_id, lease_duration(秒), renewable(true/false)
• 上限: role の max_ttl とシステム設定 max_lease_ttl を超えない
• 更新: vault lease renew LEASE_ID で延長(許可時)
• 取り消し: vault lease revoke LEASE_ID または -prefix で一括

TTL と更新・失効のタイムライン

Lease 情報の確認と更新・取り消し

# JSON 出力で lease を確認
vault read -format=json database/creds/readonly | jq '.lease_id, .lease_duration, .renewable'

# 更新(延長)
vault lease renew <LEASE_ID>

# 即時取り消し
vault lease revoke <LEASE_ID>

# パス配下を一括取り消し
vault lease revoke -prefix database/creds/readonly

3. クラウド動的クレデンシャル (AWS/Azure/GCP) の要点

クラウド向けエンジンは、短命の一時クレデンシャルを払い出すことで、長期キーの配布/回収問題を解消します。AWS では STS による一時認証情報を推奨し、IAM ユーザー生成は例外用途に留めるのが一般的です。Azure/GCP も同様に短命トークンや一時鍵の発行が中心です。

試験観点では、credential_type の選択、TTL/Max TTL の整合、ロールの権限境界、失効時の動作(STS の期限切れ、鍵の削除など)が問われやすいポイントです。

• AWS: credential_type=sts が短命で標準。iam_user は長命になりがち
• Azure: SP ベースで短命シークレット。RBAC の割り当て範囲に注意
• GCP: 使い捨ての鍵/アクセストークン。Roleset 設計で権限を最小化

Vault 経由でのクラウド一時認証情報払い出し

AWS エンジンで STS を使う例

vault secrets enable aws

vault write aws/config/root \
  access_key=AKIA... \
  secret_key=... \
  region=ap-northeast-1

vault write aws/roles/readonly-sts \
  credential_type=sts \
  role_arn=arn:aws:iam::123456789012:role/ReadOnlyRole \
  default_sts_ttl=900 \
  max_sts_ttl=3600

vault read aws/sts/readonly-sts  # AccessKeyId/SecretAccessKey/SessionToken と TTL を取得

4. アプリ統合パターン: Agent/Sidecar、テンプレート、ラップ

アプリに Vault クライアント機能を直接組み込むか、Vault Agent を sidecar/デーモンとして配置し、ファイルに資格情報を書き出す運用が一般的です。Dynamic Secrets は短命のため、ファイル更新とシグナル再読込、または接続再確立の設計が重要になります。

ゼロトラスト観点では、Response Wrapping により資格情報やトークンの受け渡し経路での露出を抑えることができます。試験では Wrapping Token の一回限り・短命性、unwrap の責務が問われることがあります。

• Vault Agent Template で環境変数/設定ファイルをレンダリング
• renew/reload ループ: TTL の 1/2〜2/3 時点で更新と再読込
• Response Wrapping で中継点をまたぐ引き渡しを安全化

Agent サイドカーによる資格情報の供給

Vault Agent の最小構成例 (AppRole + Template)

auto_auth {
  method "approle" {
    mount_path = "auth/approle"
    config = {
      role_id_file_path = "/etc/vault/role_id"
      secret_id_file_path = "/etc/vault/secret_id"
    }
  }
  sink "file" {
    config = { path = "/etc/vault/token" }
  }
}

template {
  source      = "/etc/vault/templates/db.tpl"
  destination = "/etc/secrets/db.env"
  command     = "/usr/local/bin/reload-app"
}

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

# db.tpl の例:
# export DB_USER="{{ with secret \"database/creds/readonly\" }}{{ .Data.username }}{{ end }}"
# export DB_PASS="{{ with secret \"database/creds/readonly\" }}{{ .Data.password }}{{ end }}"

5. セキュリティ/監査/運用制御: Policy と一括失効の扱い

最小権限を実現するため、アプリのトークンには必要な読み取りパス(database/creds/role など)のみ付与します。管理者は revoke -prefix を用いて影響範囲別に一括失効を計画的に実行できます。監査ログは発行・更新・失効のトレースを提供し、インシデント対応を容易にします。

試験で混同しやすい点として、トークン TTL とシークレット TTL の独立性、default_ttl と max_ttl の関係、orphan トークンと revoke 伝播の挙動があります。各概念を切り分けて覚えましょう。

• Policy は list/read など必要最小限を付与
• 監査は file/socket/sink で有効化し、時刻同期を維持
• revoke -prefix は広範囲に影響、メンテ時間帯に実施
• default_ttl ≤ max_ttl。不整合は作成/更新エラーの原因

Lease の階層と一括失効イメージ

最小権限ポリシーと監査の有効化

# アプリが readonly 資格情報だけ取得可能にする例
path "database/creds/readonly" {
  capabilities = ["read"]
}

# 監査ログをファイルで有効化
vault audit enable file file_path=/var/log/vault_audit.log

6. トラブルシューティングと Associate/Ops 向けチェックリスト

よくある失敗は、ロール名の不一致、max_ttl を超える更新、バックエンド接続権限不足(例: DB 側で CREATE ROLE 権限なし)、またはトークン権限不足(read 不可)です。メッセージに lease TTL too large、permission denied、no handler for route などが出たら、それぞれ TTL 上限、ポリシー、マウント/パスの誤りを疑います。

運用では、プール接続の更新戦略(コネクション再確立)、ネットワーク分断時の再試行窓、監査とメトリクス(発行失敗率/更新失敗率)の可視化が安定稼働の鍵です。

• パス/ロール/ポリシーをまず確認: sys/mounts と list で可視化
• TTL 不一致は role の default_ttl/max_ttl とシステム上限を調整
• バックエンド側の権限(例: Postgres の CREATE ROLE)を検証
• 更新は期限の 50〜70% 時点で実施。失敗時は再取得へフェイルオーバー

簡易診断フロー

確認系コマンド/API スニペット

# マウント一覧
vault list sys/mounts

# ロール定義の確認
vault read database/roles/readonly

# API 例: 認証後に creds を取得
curl -s \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  https://vault.example.com/v1/database/creds/readonly | jq

問題で確認

よくある質問