Vault Agent Auto-Authでシークレット取得の自動化を現場に落とし込む

アプリにシークレット取得の責務を持たせると、認証情報の埋め込みや更新漏れが発生しがちです。Vault AgentのAuto-Authは、アプリの脇で安全にトークンを取得・更新し、テンプレートやローカルプロキシ経由でシークレットを配布します。

この記事では、安定機能を前提に、構成の最小単位からトークンのライフサイクル、テンプレート/キャッシュの使い分け、運用時の落とし穴までを整理します。

基本概念と出題ポイント

Vault Agent Auto-Authは、Vaultの認証メソッド（Kubernetes、AWS、GCP、Azure、AppRoleなど）を使ってAgent自身がログインし、クライアントアプリに代わってVaultトークンを取得・更新する仕組みです。アプリはトークンやシークレットの直接管理から解放されます。

試験では、Auto-Auth（トークン取得）、テンプレート（ファイルへシークレットをレンダリング）、キャッシュ（ローカルHTTPプロキシでトークン・シークレットのリース管理）を区別できることが重要です。特に、トークンの更新（renew）と失効（revoke）の扱い、認証メソッド選定、最小権限ポリシーの適用が頻出です。

• Auto-Auth: Agentが認証メソッドでログインし、トークンを取得・更新。必要に応じてファイル等のシンクに書き出す。
• Template: 取得したシークレットをファイルに安全に出力。TTLや変更を検知して再レンダリング。
• Cache: ローカルのHTTPプロキシ。アプリはVAULT_AGENT_ADDRに向けてリクエストし、Agentがトークンとリースの更新を肩代わり。
• 最小権限: Agentが取得する子トークンに限定的なポリシーを付与。rootトークンは使わない。
• 可観測性: ログのレベル/出力先、ヘルスチェックの組み込み（プロセス監視）を準備。

アーキテクチャとデータフロー

Agentはアプリの同一ホスト（あるいはPod内のサイドカー）で動作し、起動時にAuto-AuthでVaultへログインします。取得したトークンはシンク（例: ファイル）に書き出すか、キャッシュプロキシ内で保持します。アプリはファイル/環境変数/ローカルHTTP経由でシークレットへアクセスします。

ポイントは、アプリがVaultの認証方式を理解する必要がないこと、トークンの更新・期限切れ処理をAgentが担うこと、テンプレートにより“ファイルとしてのシークレット”を安全に渡せることです。

• Auto-Authは再試行・バックオフを行い、安定すれば定期更新を継続
• シンクを使う方式（ファイル）か、キャッシュプロキシ方式（HTTP）かを要件で選定
• テンプレートは再レンダリング時に権限・パーミッションを維持

Vault Agent Auto-Authの代表的な流れ

 [App] --(1. シークレット要求)--> [Vault Agent]
    |                                   ^
    |                                   |
    |                         (2. Auto-Authでログイン)
    |                                   |
    v                                   |
 [ファイル/HTTP] <-(3. トークン/シークレット提供)-- [Vault]

 説明:
 1) アプリはローカルのAgentへリクエスト（ファイル読み込み or HTTP）
 2) Agentは認証メソッド（例: Kubernetes/AppRole）でVaultにログインしトークン取得
 3) Agentはテンプレート/キャッシュを通じてシークレットを提供し、トークンとリースを更新

最小構成: AppRole + ファイルシンク + テンプレート

まずは汎用的なAppRoleでの最小構成です。role_id/secret_idはプロビジョニング時に安全に配布します。AgentはAuto-Authでトークンを取得し、テンプレートでアプリ用の設定ファイルを生成します。

Kubernetes環境なら、methodをkubernetesに切り替え、ServiceAccount JWTとVaultのkubernetes auth roleを紐づけます。いずれも、Agentが子トークンを取得し、そのトークンでテンプレートやキャッシュが動く点は同じです。

• ファイルシンクは最小で分かりやすいが、権限と秘密管理の責任がOS側に及ぶ
• 権限は0640程度に制限し、所有者グループをアプリの実行ユーザに合わせる
• テンプレート再レンダリング時のreloadコマンドでアプリに反映を促す

vault-agent.hcl（例: AppRole + file sink + template）

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

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 = "/run/vault/token"
      mode = "0640"
    }
  }
}

cache {
  use_auto_auth_token = true
}

# ローカルHTTPプロキシ（必要に応じて）。
listener "tcp" {
  address     = "127.0.0.1:8201"
  tls_disable = true
}

# シークレットをファイルへレンダリング
template {
  source      = "/etc/vault/templates/app.ctmpl"
  destination = "/run/secrets/app-config.json"
  command     = "/usr/bin/systemctl reload myapp"
  perms       = "0640"
}

トークンのライフサイクルとセキュリティ運用

AgentはAuto-Authで得たトークンを自動で更新します。トークンに付随するリース（例: 動的DBクレデンシャル）は、キャッシュ経由で取得した場合にAgentが更新を肩代わりします。期限切れ前に更新できない場合、既存のトークン/シークレットは失効し、再ログイン後に新たなトークン/シークレットが配布されます。

セキュリティ上は、子トークンに最小権限ポリシーを適用し、シークレットパスも絞り込みます。ファイルシンクを用いるなら、ファイルと格納ディレクトリのパーミッション、ログへの秘匿情報混入防止、バックアップ対象外の扱いを徹底します。

• 子トークンは定期的に更新（renew）。上限TTLを超える場合は再ログインが必要
• 動的シークレットはリースで管理。キャッシュ経由ならAgentがrenewを実施
• 障害時の挙動: Vault不達→更新停止→期限切れ→再接続後に再ログイン
• 監査: VaultのAuditデバイスでAgentのアクセスを記録。アプリからの直接認証は不要

キャッシュとテンプレートとサイドカーの使い分け

ファイルとして受け取りたい場合はテンプレート、アプリがVault API互換で取りたい場合はキャッシュプロキシが向きます。KubernetesではサイドカーとしてAgentを同居させるのが一般的です。Auto-Authはどの形でも共通して“トークン取得と更新”を担います。

実務では、まずテンプレートで静的設定＋一部のシークレットを書き出し、より動的な資格情報（例: DB動的ユーザ）はキャッシュプロキシで都度取得、という併用が扱いやすいです。

• テンプレート: 設定ファイルにまとめたい、プロセス再読込で反映できる
• キャッシュ: 高頻度アクセス、動的シークレット、自動リース更新が必要
• サイドカー: Pod単位で閉じ、ネットワーク面・権限面の境界を分かりやすく

キャッシュ経由でのアプリ設定例（環境変数）

export VAULT_ADDR="http://127.0.0.1:8201"   # Agentのlistener
export VAULT_TOKEN=""                         # 未設定（Auto-Auth + cacheを利用）
# 以降、アプリはVAULT_ADDRに対して通常のVault APIを呼ぶだけで、
# Agentがトークンとシークレットのリース更新を肩代わりする。

運用ベストプラクティスとトラブル時の挙動

トラブルは“更新が止まる/再ログインできない/ファイル権限が不適切”に集約されます。ログレベルをINFO以上にし、Auto-Authの再試行やテンプレートの再レンダリング履歴を追えるようにします。シンクのパスと権限は構成管理に取り込み、誤変更を防ぎます。

再起動戦略も重要です。Agentプロセスはサービスマネージャで自動再起動、アプリはテンプレートのcommandで安全にreload。Vault側は認証メソッドのロール設定（bound_*制約など）を厳密化し、誤用時にはログで早期検知できるよう監査を有効化します。

• Kubernetes: ServiceAccountとRoleの対応を最小に、Namespaceスコープを絞る
• IaaS: IAMロール・メタデータ連携（AWS/GCP/Azure）を優先、静的共有秘密は避ける
• CI/CD: AppRoleでSecretIDの一時性を担保、ラップトークンの利用も検討
• 監視: 期限接近アラート（トークンTTL/リースTTL）と再試行の失敗回数を可視化

問題で確認

よくある質問