Kubernetes シークレットエンジンで実現する動的 Service Account 発行

Kubernetes クラスタでの権限付与を最小化しつつ、自動化基盤やワークロードに短命な認証情報を配布したい――この要件に対し、Vault の Kubernetes シークレットエンジンは、Kubernetes の TokenRequest API を呼び出して Service Account のトークンを動的に払い出します。

本稿では、公式ドキュメントに基づく安定挙動を前提に、導入ステップ、RBAC 設計、運用パターン、試験で狙われやすい差異（Kubernetes 認証方式との違い）を具体的に解説します。

基礎と動作フロー：TokenRequest による短命トークン

Vault の Kubernetes シークレットエンジンは、既存の Service Account（SA）に対して Kubernetes API の TokenRequest サブリソースを呼び出し、短い有効期限の JWT を取得してクライアントに返します。Vault はこの発行処理に必要な Kubernetes への接続情報と、どの SA／Namespace への発行を許可するかをロールで制御します。

この方式は、Kubernetes 側で署名・検証される標準の SA トークンを用いるため互換性が高く、かつ TTL による自然失効を前提とする運用にフィットします（一般に早期の強制失効は不可。短寿命・頻繁な再取得が前提）。

• 利点: 短命トークンにより漏えいリスク低減、配布の自動化が容易
• 制約: Kubernetes の TokenRequest 上限やクラスター設定により TTL が切り詰められる場合あり
• 前提: Vault から Kubernetes API に対し TokenRequest を行える RBAC 権限が必要

動的発行の全体像

Vault からトークンを取得する最小例（概念）

## 概念的な例（実際のパス名やフィールドはバージョンで差異あり。公式ドキュメントで要確認）
# 役割名 my-role で SA トークンを払い出し
vault read kubernetes/issue/my-role \
  service_account_name=my-app \
  namespace=apps \
  ttl=15m \
  audiences=https://kubernetes.default.svc

# 出力例（概略）
# token          : eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
# expiration     : 2026-04-19T12:34:56Z
# namespace      : apps
# service_account: my-app

必要な権限と接続設定：RBAC と Vault 側の config

Vault が TokenRequest を実行できるように、Kubernetes 側で serviceaccounts/token の create 権限を付与します。広範な権限は避け、原則は Namespace 単位・必要最小限の Service Account に絞るロール設計を推奨します。

Vault のシークレットエンジン側では、Kubernetes API サーバーのエンドポイント、CA 証明書、そして前述の RBAC が付与された Service Account トークン（Vault が Kubernetes に接続する際に用いる）を設定します。

• RBAC は Role/RoleBinding（Namespace 単位）を基本に。やむを得ない場合のみ ClusterRoleBinding
• TokenRequest の create 権限を対象 SA あるいは対象 Namespace に限定
• Vault の kubernetes/config に CA と API エンドポイント、トークンを設定

RBAC と Vault シークレットエンジンの接続設定（例）

# Kubernetes 側（最小権限の例: apps Namespace 内の TokenRequest のみ許可）
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vault-k8s-se
  namespace: vault
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tokenrequest-minimal
  namespace: apps
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: vault-k8s-se-binding
  namespace: apps
subjects:
- kind: ServiceAccount
  name: vault-k8s-se
  namespace: vault
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tokenrequest-minimal

# Vault 側（概念例。実際のフィールド名は公式ドキュメントを確認）
# Kubernetes シークレットエンジン有効化
vault secrets enable kubernetes

# 接続設定（in-cluster を想定）
vault write kubernetes/config \
  kubernetes_host="https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
  token=@/var/run/secrets/kubernetes.io/serviceaccount/token

ロール設計と発行手順：Namespace/SA/Audience/TTL の詰め

発行対象をロールで定義します。ロールでは、許可する Namespace と Service Account、許可 Audience、TTL の上限などを縛ります。これにより、Vault 側の権限分離と最小権限を維持できます。

発行時はロール名を指定して読み取り（または書き込み）操作を実行します。返却されるトークンは Kubernetes で署名・検証される JWT で、Kubernetes 側の設定により TTL が短縮される場合があります。

• TTL は Kubernetes の TokenRequest 上限により短縮されうる（クラスター設定依存）
• ロールは Namespace と SA を狭く指定し、横展開はロールを分ける
• 発行と同時に Vault のリースが作成されるが、Kubernetes トークン自体の早期失効は一般に不可

ロール作成と発行（概念コマンド例）

# ロール作成（概念例。ご利用の Vault 版のロールパラメータ名は公式ドキュメントで確認）
vault write kubernetes/roles/ci-deployer \
  allowed_namespaces=apps,staging \
  allowed_service_accounts=deployer \
  allowed_audiences=https://kubernetes.default.svc \
  ttl=15m \
  max_ttl=1h

# 発行（ロールに許可された SA/Namespace の組み合わせで実行）
vault read kubernetes/issue/ci-deployer \
  service_account_name=deployer \
  namespace=apps \
  audiences=https://kubernetes.default.svc \
  ttl=10m

# 返却値（概略）: token, expiration, namespace, service_account など

運用パターン：Vault Agent と CI/CD への組み込み

ワークロードにトークンを配る実装では、Vault Agent（サイドカー）で定期的に再取得し、ファイルに書き出してプロセスに読み込ませる方法が現実的です。CI/CD では、ジョブ開始時に 1 回だけ取得し、TTL をジョブ時間内に収まるよう設計します。

可観測性の観点では、リース期限の監視、発行失敗のメトリクス化、監査ログの収集を最低限そろえます。早期失効が不要でも、短 TTL と自動再取得の検証は定期的に行いましょう。

• ワークロード: Vault Agent サイドカーで自動再取得とローテーション
• CI/CD: ジョブ時間に合わせた TTL 設計（冪等な再試行と失敗時の明確な終了）
• 監査: Vault の audit デバイス有効化と Kubernetes API サーバー監査ログの併用

Vault Agent（サイドカー）でのテンプレート出力例

# Agent 設定（概念）: kubernetes/issue/ci-deployer から取得しファイル出力
exit_after_auth = false
pid_file = "/tmp/vault-agent.pid"

auth {
  method = "approle"  # 例: AppRole で Agent を認証
  mount_path = "auth/approle"
  config = {
    role_id_file_path   = "/vault/secrets/role_id"
    secret_id_file_path = "/vault/secrets/secret_id"
  }
}

template {
  destination = "/work/token"
  contents    = <<EOF
{{ with secret "kubernetes/issue/ci-deployer" (printf "service_account_name=%s namespace=%s ttl=%s" "deployer" "apps" "10m") }}{{ .Data.token }}{{ end }}
EOF
}

# ワークロードは /work/token を読み、期限前に Agent が置換する設計

試験対策の要点：認証方式との違いと TTL/リー スの理解

Vault の Kubernetes 認証方式（auth method）は「Pod が Vault にログインするため」の仕組みです。一方、本稿の Kubernetes シークレットエンジンは「Vault が Kubernetes の認証情報（SA トークン）を払い出す」仕組みです。方向の違いを取り違えると設計ミスになります。

また、Kubernetes の TokenRequest で払い出されたトークンは時間で自然失効します。Vault のリース取り消しは Vault 内部の管理にすぎず、Kubernetes 側で発行済みトークンの強制失効は一般にできません。したがって短 TTL と自動ローテーションが前提運用です。

• Kubernetes 認証方式: Pod→Vault の認証
• Kubernetes シークレットエンジン: Vault→Kubernetes のトークン発行
• 早期失効: できない前提。短 TTL と頻繁な再取得が解

試験で押さえる最小ポリシー例（Vault 側で発行ロールの読み取り許可）

# Vault ポリシー（例）: 指定ロールの発行のみ許可
auth "*" {
  # 認証方法は別途
}

path "kubernetes/issue/ci-deployer" {
  capabilities = ["read"]
}

# 実務では対象ロールごとに最小権限で切り分ける

トラブルシューティングと監査：よくある躓きと確認ポイント

TokenRequest の RBAC 不足が最頻出です。serviceaccounts/token の create が対象 Namespace/SA に付いているか、ResourceName で過度に縛っていないか確認します。TTL が期待より短い場合は Kubernetes 側の上限設定を疑います。

監査では Vault の audit デバイスを有効化し、誰がどのロールでいつ発行したかを追跡可能にします。Kubernetes 側の API 監査と突合せができると尚良いです。

• 403 Forbidden: Role/RoleBinding の Namespace 違い、もしくは resourceNames の不一致
• TTL が短縮: クラスタの TokenRequest 上限に到達。Vault 側 TTL を伸ばしても超えられない
• Audience 不一致: 対象サービスの検証 Audience に合わせる（例: https://kubernetes.default.svc）

監査・確認の実用コマンド

# リース確認（Vault 側）
vault list sys/leases/lookup/kubernetes

# 直近の発行リクエスト（Vault 監査ログから grep）
# 例: file 監査デバイスを /var/log/vault_audit.log に設定済みとする
grep 'kubernetes/issue/ci-deployer' /var/log/vault_audit.log | tail -n 20

# Kubernetes 側の権限テスト（権限レビュー）
kubectl auth can-i create serviceaccounts/token --as=system:serviceaccount:vault:vault-k8s-se -n apps

問題で確認

よくある質問