Vault Cert 認証の実務と試験対策: クライアント証明書でのセキュアなログイン

Vault の cert 認証は、クライアント証明書を提示して Vault にログインし、ポリシーが付与されたトークンを取得する方式です。mTLS で証明書を提示し、認証メソッド側で証明書とポリシーの対応付けを行います。

本稿は、公式挙動に沿った最小限の導入、設計の要点、失効やローテーションの考え方、試験で混同しやすい点を短時間で押さえられるようにまとめています。

基本概念と試験で問われるポイント

Vault の cert 認証は、TLS クライアント証明書を提示して /auth/cert/login にログインし、Vault が証明書を検証してポリシー付トークンを発行する仕組みです。認証自体は Vault の cert 認証メソッドが行い、通信路の暗号化とサーバー認証は通常の TLS 設定が担います。

証明書の信頼は、cert 認証メソッドに登録したクライアント証明書そのもの、または発行元 CA 証明書に基づいて行われます。CA 単位で信頼する場合は、CN や SAN、OU などの属性で許容範囲を絞り込む設計が重要です（属性名や詳細なパラメータはバージョンで差異があり得るため、導入時はドキュメントを確認してください）。

試験では、mTLS で提示したクライアント証明書を「Vault 側の cert 認証メソッドで検証・マッピングしてトークンを発行する」という流れと、AppRole や Kubernetes/OIDC など他方式との使い分けが頻出です。

• ログインは POST /auth/cert/login。CLI は vault login -method=cert
• 証明書は TLS ハンドシェイクで提示。Vault は接続に紐づく証明書を認証メソッドで検証
• マッピングは「証明書（または CA）→ ポリシー」。必要に応じて属性でスコープを絞る
• 得られるのは通常の Vault トークン。TTL・再認証戦略はトークン運用に従う

最小のログイン例（CLI と curl）

export VAULT_ADDR=https://vault.example.com:8200
export VAULT_CACERT=/path/to/vault-ca.pem
export VAULT_CLIENT_CERT=/path/to/client.pem
export VAULT_CLIENT_KEY=/path/to/client.key

# CLI でログイン（cert 認証）
vault login -method=cert

# HTTP で直接（mTLS 必須）
curl --cacert /path/to/vault-ca.pem \
     --cert /path/to/client.pem --key /path/to/client.key \
     https://vault.example.com:8200/v1/auth/cert/login

導入と最小構成手順

最小構成は、1) 認証メソッドの有効化、2) クライアント証明書や CA の登録（ポリシー紐付け）、3) mTLS でのログイン、の3段階です。開発・検証から始め、本番では属性で許容範囲を絞り、トークン TTL/Max TTL/Period を設計します。

証明書単体でピン留めすると紛失・失効対応が明確になります。CA 単位で信頼する場合は利便性が上がる反面、失効伝播や属性スコープ設計がより重要です。

• auth/cert を有効化: vault auth enable cert
• マッピングの作成: auth/cert/certs/<name> に証明書または CA 証明書を登録し、ポリシーを付与
• mTLS で /auth/cert/login にアクセスし、トークンを取得

最小の設定例（証明書ピン留め と CA 信頼の両パターン）

# 認証メソッドを有効化
vault auth enable cert

# パターンA: 特定クライアント証明書をピン留め（証明書そのものを登録）
# client.pem は公開鍵証明書（PEM）。ポリシー dev-app を付与
auth_path="auth/cert/certs/dev-client"
vault write ${auth_path} \
  certificate=@/path/to/client.pem \
  policies="dev-app" \
  display_name="dev-client"

# パターンB: 発行元 CA を信頼（CA による署名済みクライアント証明書を受け入れる）
auth_path="auth/cert/certs/ci-clients-ca"
vault write ${auth_path} \
  certificate=@/path/to/ci-clients-ca.pem \
  policies="ci-build" \
  display_name="ci-clients"
# CN/SAN/OU などの属性で許容範囲を狭めるオプションを追加（Vault のバージョンにより名称差異あり）
# 例: allowed_common_names=..., allowed_dns_sans=..., allowed_organizational_units=...

# ログイン（該当エントリを明示する場合）
vault login -method=cert name=dev-client

アーキテクチャとフロー（mTLS とポリシーマッピング）

クライアントは mTLS で Vault に接続し、TLS ハンドシェイクでクライアント証明書を提示します。Vault はサーバー TLS で通信を保護しつつ、cert 認証メソッドが接続に付随する証明書を参照し、事前登録のマッピングと照合します。

マッチしたエントリに紐づくポリシーを付与したトークンが発行され、以降の Vault API 呼び出しに利用します。

• mTLS ハンドシェイク → cert 認証メソッドで証明書検証 → マッピング一致 → トークン発行
• 複数エントリにマッチし得る場合は name パラメータで限定
• 発行トークンの TTL/Max TTL/Period は設計上の重要パラメータ

mTLS と cert 認証メソッドの流れ

Client                         Vault
  |    TLS ClientHello             |
  |------------------------------>|
  |  presents client certificate   |
  |<------------------------------|
  |      TLS handshake complete    |
  |                                |
  |  POST /auth/cert/login (mTLS)  |
  |------------------------------>|
  |  verify cert -> match mapping  |
  |  issue token with policies     |
  |<------------------------------|
  |    use token for secrets/API   |
  |------------------------------>|

トークン取得後の利用（例: KV から読む）

# ログインで得たトークンを環境変数に設定
export VAULT_TOKEN="s.xxxxx"

# KV v2 シークレットの読み取り
auth_header="X-Vault-Token: ${VAULT_TOKEN}"
curl --cacert /path/to/vault-ca.pem \
     -H "${auth_header}" \
     https://vault.example.com:8200/v1/secret/data/app/config

スコーピングとセキュリティ設計の勘所

CA を登録して広く受け入れる設計は運用が楽ですが、失効チェックや属性スコープの不足はリスクです。CN や SAN（DNS/URI/Email）、組織/部門（O/OU）で許容対象を厳密化し、ポリシーは最小権限に保ちます。

Vault の cert 認証は、提示証明書が事前登録エントリと整合するかで判定します。外部の CRL/OCSP を自動参照する前提にはしないほうが安全です。短命なクライアント証明書発行、ピン留め、マッピングの削除で迅速な無効化を図るとよいでしょう。

トークン側の TTL/Max TTL/Period を活用して、証明書が長命でもアクセスは短命化できます。人ではなくマシン認証中心のユースケースで効果的です。

• CA 信頼時は属性で厳密化（CN/SAN/OU など）
• 証明書失効は短寿命化＋ピン留め＋マッピング削除で即時反映
• トークン TTL/Period で実効アクセス期間を制御

属性で許容範囲を狭める設定の例（概念）

# CA を登録しつつ、CN/SAN/OU を制限する例（実際のパラメータ名はバージョンで要確認）
vault write auth/cert/certs/ci-clients-ca \
  certificate=@/path/to/ci-clients-ca.pem \
  policies="ci-build,artifact-read" \
  display_name="ci-clients" \
  # 以下は概念例（allowed_* や required_* の名称は環境の Vault で確認）
  allowed_common_names="ci-*,build-*" \
  allowed_dns_sans="*.corp.local" \
  allowed_organizational_units="CI,Build"

運用・ローテーション・トラブルシュート

ローテーションは二層で考えます。証明書（クライアント鍵素材）と、Vault トークンです。証明書は短命発行と更新手順を自動化し、Vault 側はトークン TTL/Period とポリシー最小化で被害半径を小さくします。

接続失敗は TLS レイヤと認証メソッドの二段階で切り分けます。TLS で弾かれる場合は証明書の提示有無やチェーン不備、キー不一致が多く、認証メソッドで弾かれる場合はマッピング未登録や属性不一致が典型です。

• エントリ確認: vault list auth/cert/certs
• 詳細確認: vault read auth/cert/certs/<name>
• 無効化: vault delete auth/cert/certs/<name>（即時アクセス停止に有効）
• TLS 切り分け: openssl s_client、curl の --cert/--key/--cacert
• ログ: Vault サーバーログと HTTP 400/403 のレスポンス本文を確認

点検コマンド集

# 登録済みエントリ一覧
vault list auth/cert/certs

# 個別エントリ内容
vault read auth/cert/certs/dev-client

# 即時無効化（マッピング削除）
vault delete auth/cert/certs/dev-client

# TLS ハンドシェイク確認（証明書提示の検証）
openssl s_client -connect vault.example.com:8200 \
  -cert /path/to/client.pem -key /path/to/client.key \
  -CAfile /path/to/vault-ca.pem -quiet

Associate 試験で混同しやすい点

cert 認証は「クライアント証明書 → ポリシー付トークン」を発行します。TLS 自体の有効期限やサーバー証明書は別管理で、試験ではここを混同した選択肢が出ます。

AppRole はシークレット（SecretID）を配布管理できる環境に適し、cert は PKI・mTLS が整ったマシン間通信に向きます。人のログイン主体は OIDC/SAML 系が妥当という整理がよく問われます。

• cert 方式のログイン先は /auth/cert/login。TLS はあくまで輸送路とサーバー認証
• CA 信頼時は属性スコープでの絞り込みが前提（受け入れすぎは減点ポイント）
• 取得するのは Vault トークン。以後の権限はポリシーで決定される

理解確認ワンライナー

# name を明示して特定エントリでログイン（競合回避）
vault login -method=cert name=ci-clients-ca

問題で確認

よくある質問