Contents
Consul KV ストアの概要と活用シーン
Consul が提供するキー/バリュー（KV）ストアは、分散環境において構成情報や短期的なシークレットを共有できる軽量データベースです。マイクロサービスが起動時に設定を取得したり、機能フラグのオン／オフをリアルタイムで反映させたりする場面で頻繁に利用されます。本セクションでは、Zero Trust が求める「認証・暗号化・最小権限」の観点から、代表的な活用パターンと留意点を整理します。
- 設定データ：サービス起動時や再デプロイ時に
consul kv getで取得し、環境ごとの差分だけを上書きできる。 - シークレット：短期間の API キーや DB パスワードを保存し、必要に応じて HashiCorp Vault と連携して自動ローテーションを実装できる。
- ランタイムキャッシュ／Feature Toggle：フラグ情報を KV に置き、Watch 機能で変更を検知すればアプリ側の再デプロイなしに機能切り替えが可能になる。
Consul KV は「認証・暗号化・アクセス制御」の三層防御と組み合わせることで、機密情報の安全な共有基盤として活用できます（参考: HashiCorp Developer – Consul）。
TLS 設定で通信を暗号化する方法
TLS はエージェント間およびクライアント–サーバー間のトラフィックを保護し、盗聴や改ざんからシステム全体を守ります。このセクションでは、内部 CA を用いた相互 TLS（mTLS）構成と、実際に使用できる設定例・検証手順を示します。
証明書の発行と管理
まずは内部 CA を作成し、サーバー証明書とクライアント証明書（エージェント用）を生成します。以下は OpenSSL による最小構成例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# 1. 内部 CA の作成 openssl genrsa -out ca.key 4096 openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \ -subj "/CN=Consul-CA" -out ca.crt # 2. サーバー証明書の生成（FQDN は実際のノード名に置き換える） openssl genrsa -out server.key 4096 openssl req -new -key server.key -subj "/CN=consul-server.example.com" \ -out server.csr openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -days 365 -sha256 -out server.crt # 3. クライアント証明書（エージェント）も同様に作成 openssl genrsa -out client.key 4096 openssl req -new -key client.key -subj "/CN=consul-agent" -out client.csr openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -days 365 -sha256 -out client.crt |
運用ヒント：cert‑manager や Vault PKI シークレットエンジンと組み合わせると、証明書の自動更新が容易になります。
Consul の TLS 設定例
以下はサーバーノード向けの HCL 形式設定ファイルです。tls {} ブロックに CA と証明書パスを指定し、verify_* オプションで相互認証を有効化します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# server.hcl（サーバー側） datacenter = "dc1" server = true bootstrap_expect = 3 tls { defaults = true # 全通信で TLS を必須化 ca_file = "/etc/consul/tls/ca.crt" cert_file = "/etc/consul/tls/server.crt" key_file = "/etc/consul/tls/server.key" verify_incoming = true # 相手の証明書を検証 verify_outgoing = true verify_server_hostname = true } |
クライアント（エージェント）側も同様に tls {} を追加しますが、verify_server_hostname はサーバー名と一致するかどうかだけ確認すれば十分です。
設定を反映したら以下のコマンドで Consul を再起動し、TLS が有効になっていることを確認します。
|
1 2 3 4 5 6 7 8 9 |
# 設定ファイルの検証 consul validate server.hcl # サービス起動（systemd 例） systemctl restart consul # TLS が有効かどうかは `consul info` の出力で確認 consul info | grep -i tls |
注意：
consul version -tlsは存在しないコマンドです。TLS の有無はconsul info、もしくは API の/v1/status/leaderに対して HTTPS でアクセスできるかどうかで判断します。
ACL と最小権限ポリシーの実装
ACL は Consul の認可レイヤーとして機能し、トークンごとにキー操作やサービス登録の権限を細かく制御できます。Zero Trust では「最小特権」の原則が重要です。本節ではトークンの種類、ライフサイクル管理、および実装例を示します。
トークン種別と推奨 TTL
| 種類 | 用途 | 推奨有効期限 |
|---|---|---|
| Management（管理者） | ACL・サービス定義全般の操作 | 手動ローテーションのみ、長期保存は非推奨 |
| Agent（エージェント） | サービス登録・ヘルスチェック | 30 日程度で自動更新 |
| Application（アプリケーション） | KV の読み取り／書き込み | 7〜14 日で短期化 |
トークン作成は CLI または API から行います。以下は管理者トークンの初回ブートストラップ例です。
|
1 2 3 4 5 6 7 8 9 |
# 初回インストール時に管理者トークンを生成 consul acl bootstrap # アプリケーション向け読み取り専用トークン（ポリシー名は後述） consul acl token create \ -description "app-readonly" \ -policy-name kv-read-only \ -ttl 14d |
ポリシー定義のベストプラクティス
ポリシーは HCL ファイルで管理し、Git にコミットしてバージョンコントロールします。以下は「全キーの読み取り＋特定パスだけ書き込み」を許可する例です。
|
1 2 3 4 5 6 7 8 9 |
# kv-read-only.hcl key_prefix "" { policy = "read" } key_prefix "service/config/" { policy = "write" } |
ポリシーを登録し、トークンに紐付ける手順は次の通りです。
|
1 2 3 4 5 6 7 8 |
consul acl policy create -name kv-read-only -rules @kv-read-only.hcl # 上記で作成したポリシーを利用してトークンを生成 consul acl token create \ -description "service-config-writer" \ -policy-name kv-read-only \ -ttl 7d |
ポイント：
key_prefix ""は全キーの読み取り権限です。書き込みは必要最小限のパスに限定することで、漏洩時の影響範囲を大幅に減らせます。
Check‑And‑Set (CAS) を利用した安全な更新
KV の同時書き込みが頻発すると競合が起こりやすく、設定の不整合につながります。Consul が提供する CAS（Check‑And‑Set）機能はインデックスを用いた楽観的ロックで、原子的に更新できる仕組みです。
CAS の基本フロー
- キーの取得：
consul kv get -index <key>で現在のModifyIndexを取得。 - 新しい値の作成：アプリケーションロジックで変更内容を生成。
- CAS 書き込み：
consul kv put -cas=<ModifyIndex> <key> <value>を実行。インデックスが一致すれば更新成功、違えば失敗として再取得・リトライする。
シェルスクリプトでの実装例
以下は Feature Flag の有効化を CAS で安全に行うサンプルです。最大 5 回までリトライし、最終的に手動確認が必要になるよう設計しています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
#!/usr/bin/env bash set -euo pipefail KEY="service/config/feature-flag" MAX_RETRY=5 RETRY=0 while (( RETRY < MAX_RETRY )); do # 1. 現在値とインデックス取得 RESULT=$(consul kv get -recurse -decode -index "$KEY") VALUE=$(echo "$RESULT" | head -n1) INDEX=$(consul kv get -keys -separator= "" "$KEY" | tail -n1) # 実際は API で Index を取得 # 2. 新しいフラグ値を決定（例: true に変更） NEW_VALUE="true" # 3. CAS 書き込み if consul kv put -cas="$INDEX" "$KEY" "$NEW_VALUE"; then echo "CAS 成功：$KEY を $NEW_VALUE に更新" exit 0 else echo "CAS 失敗：競合検出、再取得してリトライ..." (( RETRY++ )) sleep 1 fi done echo "最大リトライ回数に達しました。手動で確認してください。" >&2 exit 1 |
実務ヒント：CI/CD パイプラインから KV を更新する際は必ず
-casオプションを付与し、失敗時は自動リトライロジックを組み込むことでデプロイの安定性が向上します。
Zero Trust 環境でのサービスディスカバリと KV アクセス制御
Zero Trust では「すべての通信を検証」し、最小権限でリソースにアクセスさせることが求められます。Consul Connect のサイドカー方式は mTLS による相互認証とプロキシ機能を提供し、サービスディスカバリと KV への安全なアクセスを同時に実現します。
アーキテクチャ上の統合ポイント
| 項目 | 実装例 |
|---|---|
| エージェント認証 | connect { sidecar_service {} } と TLS 設定で自動 mTLS を有効化 |
| サービス間通信 | サイドカーがプロキシとして機能し、すべてのリクエストを暗号化 |
| KV 参照 | アプリはローカルサイドカー経由で http://127.0.0.1:8500/v1/kv/... にアクセス。トークンは環境変数や Vault 注入で供給 |
| ポリシー統合 | ACL ポリシーに service_prefix "" { policy = "read" } と KV の読み取り権限を組み合わせ、サービスが必要なキーだけ参照できるよう制御 |
実装手順の概要
-
Connect 設定の有効化
hcl
connect {
enabled = true
} -
サイドカー用サービス定義（例：Web アプリ）
hcl
service {
name = "web-app"
port = 8080connect {
sidecar_service {}
}# ACL 用トークンは環境変数 CONSUL_HTTP_TOKEN に設定
}
-
ACL ポリシーで KV の読み取りを限定
hcl
service_prefix "" {
policy = "read"
}
key_prefix "web-app/config/" {
policy = "read"
}
参考情報：Microsoft Zero Trust ガイドラインでも「明示的な検証と最小特権アクセス」が推奨されています。Consul の ACL と Connect がこの要件を満たす基盤となります。
シークレット管理・ローテーション、監査ログの運用手順
KV に保存したシークレットは暗号化と定期的なローテーションが必須です。また、変更履歴は外部 SIEM へ転送し、インシデント対応を迅速に行えるようにします。
Vault Transit と組み合わせた暗号化フロー
-
Transit エンジンの有効化
bash
vault secrets enable -path=transit transit
vault write -f transit/keys/consul-kv -
平文を Vault で暗号化し KV に保存（CLI）
bash
PLAINTEXT=$(echo -n "my-db-pass" | base64)
CIPHERTEXT=$(vault write -field=ciphertext transit/encrypt/consul-kv plaintext=$PLAINTEXT)
consul kv put secret/db/password "$CIPHERTEXT" -
アプリ側で復号
アプリは Vault の/transit/decrypt/:keyAPI を呼び出し、取得した平文を使用します。
定期ローテーションスクリプト
以下は毎日 02:00 に実行する Cron ジョブのサンプルです。新しいパスワードを生成し、Vault で暗号化後に CAS で KV を安全に更新します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
#!/usr/bin/env bash set -euo pipefail KEY_PATH="secret/db/password" # 新しいランダムパスワード生成（32 バイト Base64） NEW_PASS=$(openssl rand -base64 32) # Vault で暗号化 CIPHERTEXT=$(vault write -field=ciphertext transit/encrypt/consul-kv \ plaintext=$(echo -n "$NEW_PASS" | base64)) # 現在の ModifyIndex を取得 INDEX=$(consul kv get -index "$KEY_PATH" | grep '^Index:' | awk '{print $2}') # CAS による安全な更新 if consul kv put -cas="$INDEX" "$KEY_PATH" "$CIPHERTEXT"; then echo "$(date) : Secret rotated successfully" else echo "$(date) : CAS conflict – rotation aborted" >&2 exit 1 fi |
crontab -e に以下を追加して自動化します。
|
1 2 |
0 2 * * * /usr/local/bin/rotate-secret.sh >> /var/log/secret-rotation.log 2>&1 |
監査ログの有効化と SIEM 連携
Consul の監査機能は JSON 形式で出力でき、外部のログ集約基盤に転送可能です。
|
1 2 3 4 5 6 |
# audit.hcl audit { sink = "file:/var/log/consul/audit.json" format = "json" } |
有効化コマンド：
|
1 2 |
consul audit enable -config-file=audit.hcl |
Fluent Bit を使った転送例
|
1 2 3 4 5 6 7 8 9 10 11 12 |
[INPUT] Name tail Path /var/log/consul/audit.json Parser json [OUTPUT] Name http Host siem.example.com Port 443 TLS On Header Authorization Bearer ${SIEM_TOKEN} |
運用チェックリスト（実務での確認項目）
| カテゴリ | 確認ポイント |
|---|---|
| 構成管理 | Consul の config.hcl、ACL ポリシーは Git でバージョン管理されているか |
| TLS | CA 証明書の有効期限が残り 30 日以上あり、自動更新パイプラインが稼働中か |
| ACL | トークンの TTL が適切に設定され、長期トークンが残存していないか |
| CAS | KV 更新スクリプトは必ず -cas オプションを使用しているか |
| シークレット暗号化 | すべての機密キーが Vault Transit で暗号化され、平文保存が無いか |
| ローテーション | 自動ローテーションジョブが成功した履歴を監視し、失敗時にアラートが上がるか |
| 監査ログ | JSON 形式の監査ログが SIEM にリアルタイムで転送されているか |
| バックアップ | consul snapshot save が定期実行され、安全なオフサイトへ保存されているか |
| 障害復旧 | スナップショットからのリストア手順がドキュメント化・テスト済みか |
まとめ
- Consul KV は機密情報や設定を安全に共有できる基盤です。TLS、ACL、CAS の三層防御で Zero Trust 要件を満たします。
- TLS 設定は内部 CA と相互認証（mTLS）を必ず導入し、
consul infoで有効性を確認してください。 - 最小権限の ACL ポリシーはコード化して Git 管理し、トークンは短期間 TTL のものだけを運用します。
- CAS による原子的更新とリトライロジックで競合による設定破壊を防止できます。
- Zero Trust 環境では Consul Connect とサイドカーが通信暗号化の中心となり、KV へのアクセスは ACL トークンで細かく制御します。
- Vault Transit と組み合わせたシークレット暗号化・ローテーション、監査ログの外部 SIEM 転送により、運用リスクを最小限に抑えられます。
- 最後に示した チェックリスト を導入すれば、構成管理から障害復旧まで一貫したセキュリティ体制が整います。
これらの手順とベストプラクティスを自組織の要件に合わせて適用し、Consul KV ストアで安全かつ可用性の高い機密情報管理を実現してください。