Vault の Consul ストレージをOps視点で理解する — クラシック構成との比較

Vault は保存前にデータを暗号化し、ストレージには暗号化済みブロブを書き込みます。かつては Consul をストレージに用いる構成がデファクトでした（本稿ではこれをクラシック構成と呼びます）。現在は統合ストレージ(Raft)も第一級ですが、既存の Consul 資産やマルチノード運用では、今も Consul 選択が合理的な場面があります。

この記事では、Consul ストレージの正しい使い方と、統合ストレージとの実運用差異を、資格試験（Ops）で問われやすいポイントに沿って解説します。

Consul ストレージとは何か

Vault の storage "consul" は、Consul の KV に暗号化済みデータを保存し、同時に Consul のセッション/ロックを用いて Vault のリーダー選出と HA を実現します。データ暗号化と復号は Vault のバリア層で行われ、Consul には平文は保存されません。

クラシック構成の特徴は、可用性と一貫性を Consul クラスタに委ねることです。運用者は Vault と Consul を独立にスケール/アップグレードでき、Consul ACL/TLS による厳格な境界防御も適用できます。

• 向いているケース: 既に運用中の堅牢な Consul クラスタがあり、ネットワークレイテンシが低い（数ms）環境
• 避けたいケース: WAN 超え、Consul を自前で維持できない/したくない環境、依存を減らしたい小規模導入
• 重要: Vault は保存前に暗号化するため、Consul 側の at-rest 暗号化は必須ではないが、通信路の TLS と ACL は必須

Vault サーバ設定例: Consul をストレージに利用

storage "consul" {
  address = "127.0.0.1:8500"   # 通常はローカルの Consul エージェントを指定
  path    = "vault/"           # Consul KV 上のプレフィックス
  token   = "${CONSUL_ACL_TOKEN}" # ACL 有効時は必須（環境変数で注入推奨）
  scheme  = "https"             # mTLS を推奨
  tls_ca_file   = "/etc/ssl/consul/ca.pem"
  tls_cert_file = "/etc/ssl/consul/vault-consul.pem"
  tls_key_file  = "/etc/ssl/consul/vault-consul-key.pem"
}

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = 0
  tls_cert_file = "/etc/vault/tls/server.crt"
  tls_key_file  = "/etc/vault/tls/server.key"
}

disoriented_behavior = "forbid" # バージョン差異に依存する設定は公式ドキュメントで確認

クラシック構成と統合ストレージの比較

クラシック構成（Vault + Consul）は、外部の Consul クラスタに依存し、Vault は Consul の KV とセッションで HA を成立させます。対して統合ストレージ（Raft）は、Vault 自身が Raft を内蔵し、外部依存を減らしつつ HA を実現します。

どちらも Vault の暗号化境界は不変ですが、運用対象・バックアップ手順・障害ドメイン・チューニング箇所が異なります。下表と図で全体像を掴んでから、要件に照らして選択します。

• 単一障害点を減らしたいなら統合ストレージ、既存の Consul を中核に据えるならクラシック
• レイテンシ要件とバックアップ運用の容易さで総合判断する

クラシック（左）と統合ストレージ（右）の全体像

設定スニペット比較（コメント付き）

# Consul をストレージにする（クラシック）
storage "consul" {
  address = "127.0.0.1:8500"
  path    = "vault/"
  token   = "${CONSUL_ACL_TOKEN}"
  scheme  = "https"
}

# 統合ストレージ（Raft）
# storage "raft" {
#   path    = "/opt/vault/data"
#   node_id = "vault-1"
#   retry_join = [{ leader_api_addr = "https://vault-1:8200" }]
# }

運用設計の要点（ACL/TLS/トークン/名前空間）

Consul ACL が有効な環境では、Vault 用に最小権限のトークンを発行します。Vault が利用するのは特定プレフィックス配下（例: vault/）の KV と、セッション/ロック関連 API です。Consul 通信は mTLS を必須化し、Vault はローカルの Consul エージェント（127.0.0.1:8500）に接続させるのが定石です。

Consul Enterprise の Namespaces を使用している場合は、Vault 用に専用 Namespace と Prefix を分け、誤操作や他ワークロードとの衝突を避けます。トークンはシークレット管理（例: Vault 自身の AppRole/Agent）で安全にローテーション可能にしておきます。

• 最小権限: KV は vault/ 以下のみ write/read、セッション関連は必要最小限
• mTLS: 相互認証で中間者攻撃を防止。CA ローテーション手順を用意
• ローカルエージェント: Caching/再試行/コネクション多重化により安定化
• Prefix 設計: 環境ごとに vault/prod, vault/stage など明確に分離

Consul ACL ポリシー例と Vault 側の指定

# Consul ACL ポリシー例（vault-policy.hcl）
# Vault が使うプレフィックスのみ許可
key_prefix "vault/" {
  policy = "write"
}
# セッション/ロックのための適切な許可
# （バージョンにより細部が変わるため公式ドキュメントで確認）
node_prefix "" {
  policy = "read"
}

# トークン作成（例）
# consul acl policy create -name vault -rules @vault-policy.hcl
# consul acl token create -description "vault" -policy-name vault

# Vault 側設定（環境変数で注入）
# export CONSUL_HTTP_ADDR=https://127.0.0.1:8500
# export CONSUL_HTTP_TOKEN=<token>
# vault.hcl の storage "consul" 内で token を参照

可用性・パフォーマンス設計（レイテンシとチューニング）

Vault が Consul をストレージに使う場合、性能のボトルネックは Vault→Consul の往復レイテンシです。基本方針は、各 Vault ノードのローカルに Consul エージェントを配置し、エージェントからサーバへは LAN 内で冗長接続すること。WAN 越えは避けます。

リーダー選出は Consul のセッションとロックに依存します。セッションの TTL/lock-delay は Consul 側の挙動に左右されるため、デフォルトで問題ないかを負荷試験で確認します。過度に短くするとフラッピング、長すぎるとフェイルオーバ遅延が増えます。また、Consul サーバ台数は奇数（3 または 5）で、書き込みクォーラムを満たす構成が必須です。

• レイテンシの目安: Vault→ローカル Consul agent はサブミリ秒、agent→server は数ms 程度
• エージェント: retry_join と TLS を正しく設定し、gossip 暗号化も有効化
• サーバ: 3〜5 台の奇数。I/O と CPU は Vault のスループットに直結
• 監視: Consul の RPC レイテンシ、セッション数、Vault の storage エラー率を可視化

Consul エージェント設定（Vault 同居ノードの例）

datacenter = "dc1"
server = false
retry_join = ["provider=aws tag_key=consul tag_value=server"]
ca_file   = "/etc/consul.d/ca.pem"
cert_file = "/etc/consul.d/agent.pem"
key_file  = "/etc/consul.d/agent-key.pem"
encrypt   = "<gossip_key>"   # gossip 暗号化
verify_incoming = true
verify_outgoing = true
verify_server_hostname = true

# ローカルバインド
bind_addr   = "0.0.0.0"
client_addr = "127.0.0.1"
ports { http = 8500, https = 8501, grpc = 8502 }

acl { enabled = true default_policy = "deny" enable_token_persistence = true }

バックアップ/DRと移行戦略（安全策を最優先）

Consul ストレージのバックアップは Consul 側で行います。計画停止なく取得できるスナップショット（consul snapshot save）を定期実行し、別ストレージに保管します。リストアは同等バージョン/トポロジの Consul に対して実施し、その後 Vault を起動してバリア復号を行います。バックアップ/リストア手順は必ず演習し、復旧時間目標(RTO)と復旧時点目標(RPO)を検証してください。

統合ストレージ（Raft）へ移行する場合は、利用中の Vault/Consul のバージョンにより推奨手順が異なることがあります。オフライン移行（メンテナンス時間を確保し新クラスタを初期化→データ移送→切替）と、バージョンが対応していればツールを用いた移行のいずれかを選びます。いずれにせよ、テスト環境での事前リハーサルとロールバック計画を用意するのが実務の正解です。

• RPO/RTO を満たすスナップショット頻度と保管先の冗長化
• Consul と Vault は互いに独立して監視・アラートを構成
• 移行は段階的に: 新環境の構築→データ移送検証→読み取り専用で整合確認→本番切替

バックアップ/リストア例（Consul 側）

# バックアップ（Consul サーバに対して実行）
consul snapshot save /backups/consul-$(date +%F-%H%M).snap

# リストア（メンテナンス中に実施）
consul snapshot restore /backups/consul-YYYYMMDDHHMM.snap

# 参考: 統合ストレージ(Raft)のスナップショットは Vault 側で実行（比較用）
# vault operator raft snapshot save raft-$(date +%F-%H%M).snap
# vault operator raft snapshot restore raft-*.snap

試験対策チェックリスト（Ops）

資格試験（Ops）では、ストレージ選定の根拠、障害時の挙動、バックアップ/復旧、セキュアな接続設定が頻出です。Consul ストレージの特性を、統合ストレージとの対比で言語化できるようにしておきましょう。

• Vault は保存前に暗号化するため、ストレージ側は暗号化境界外。通信路の TLS は必須
• Consul ダウン時: Vault はストレージ書込不可となり可用性を失う（既存トークンでの一部操作も失敗）
• バックアップ手順: Consul スナップショットで取得し、復旧は Consul→Vault の順に行う
• レイテンシ: Vault↔Consul は低レイテンシ必須。ローカルエージェント経由が定石
• 比較観点: 運用対象、HA 方式、バックアップ、依存、障害ドメイン、導入容易性

運用確認コマンド（ヘルスと依存の可視化）

# Vault の状態
vault status

# Consul メンバーとリーダー
consul members
consul operator raft list-peers

# Vault から Consul への疎通（ローカルエージェント）
curl -sS --cacert /etc/ssl/consul/ca.pem https://127.0.0.1:8500/v1/status/leader

問題で確認

よくある質問