この記事は、 HashiCorp Japan Advent Calendar 2025 の 25 日目の記事です！
最終日ですが、特段何を語るわけでもなく、淡々と HashiCorp プロダクトに関する記事を書いていきます！！！
はじめに
Consul とは HashiCorp が中心に開発をする OSS の Servcie Discovery や Service Mesh を実現するためのツールです。
Service Discovery やヘルスチェックなどの基本的な機能に加えて mTLS, L7 Traffic Management やコンフィグレーション管理など様々な機能を提供しています。
Consul はマルチプラットフォームでかつ全ての機能を HTTP API で提供しているため、環境やクライアントを問わず利用することができます。
Consul KVS
Consul は North-South 通信を司る API Gateway の機能や 分散 KVS としての機能など、中核となる Service Discovery, Service Mesh の機能の他にも、アプリケーションの動性をサポートするための様々な機能が提供されています。
Consul KVS はとてもシンプルに利用することが可能で、Terraform や Vault など他の HashiCorp プロダクトとの親和性も非常に高く設計されています。
そのため、Terraform の State ファイルの配置場所（backend）や、Vault の Storage Backend として Consul を利用することもできます。
例えば、hello=world という key-value 形式のデータを Consul KVS に追加し確認する場合、以下のように put/get で操作をします。
% consul kv put hello world
Success! Data written to: hello
% consul kv get hello
world
なお、Consul はクラスタ構成とすることが可能で、シングルバイナリから agent として起動することで Server または Client としての役割を持ち、ノード上にプロセスとして常駐することでクラスタとしてデプロイすることが可能です。
Consul KVS は agent の役割を問わず、Consul プロセスが稼働しているすべてのノード（Consul クラスタを構成するすべてのノード）上で利用することができます。
ACL Policy
Consul は Service Mesh や Service Discovery を実現する上で、Gossip プロトコル および、内部的に利用している Raft の mTLS による通信でセキュリティを担保しています。
一方で、Gossip プロコトルと mTLS ではカバーされないような Consul の操作に対しては、ACL Policy による RBAC でセキュリティを高めることができます。
ACL Policy を利用する際には、Consul agent の起動時に設定ファイルより明示的に有効化する必要があり、ACL Policy が有効になっている Consul クラスタにアクセスする際には、CONSUL_HTTP_TOKEN（HTTP ヘッダーの場合には X-Consul-Token）を利用することでセキュアなアクセスを実現することができます。
それでは、ACL Policy を有効化した Consult サーバを起動し、実際に試してみましょう。
# KVS データが格納されるストレージ領域を作成する
% mkdir -p .consul-data
% cat >> consul.hcl <<EOF
license_path = "./consul.hclic"
server = true
bootstrap = true
bootstrap_expect = 1
acl {
enabled = true
default_policy = "deny"
}
ui_config {
enabled = true
}
addresses {
http = "0.0.0.0"
}
datacenter = "dc1"
data_dir = ".consul-data/"
EOF
% consul agent -config-file=consul.hcl &
# ...
ACL Policy を有効化している際には、Consul に対する操作は原則的にブロックされているため、初期トークンを払い出すための Bootstrap を行う必要があります。
% consul acl bootstrap
AccessorID: a6ef73f4-ecf2-cb44-d48e-5969f0bf413f
SecretID: 4c990f1c-88ac-ddc8-804c-7f7992b9dc13
Partition: default
Namespace: default
Description: Bootstrap Token (Global Management)
Local: false
Create Time: 2025-12-27 22:50:46.491426 +0900 JST
Policies:
00000000-0000-0000-0000-000000000001 - global-management
出力からも分かる通り、Consul における ACL Policy では、トークンに対してポリシーを割り当てることにより RBAC を実現していることがわかります。
上記の Boostrap により発行された初期トークン（Boostrap Token）の場合、global-management と呼ばれる管理者相当のポリシーが割り当てられていることが確認できます。
Sentinel との連携
Sentinel は HashiCorp が中心に開発を行っている PaC（Policy as Code）のフレームワークで、HashiCorp プロダクトの連携を念頭に開発が行われています。
Consul では前述の ACL Policy により KVS パスに対して RBAC を実現することができますが、Sentinel との連携により ACL Policy の仕組みを拡張する形でより高度なポリシー制御を実現することが可能です。
ACL Policy による RBAC が有効化されているため、先ほど Bootstrap した際に発行された初期トークンを利用して Consul KVS に対する操作権限を持つトークンを発行し、そのトークンに対して ACL Policy および Sentinel ポリシーを適用します。
これにより、ACL Policy では KVS 操作自体が許可され、Sentinel では KVS 操作に対するより高度なポリシーチェックを実施することが可能です。
Consul ではトークン発行時に紐づけるポリシーを選択するため、まずは ACL Policy の作成を行い、Consul へ登録します。
% export CONSUL_HTTP_TOKEN='4c990f1c-88ac-ddc8-804c-7f7992b9dc13'
# redis/config/* に write 操作を許可する ACL Policy を作成
% cat >> kvs-redis-config.hcl <<EOF
key_prefix "redis/config/" {
policy = "write"
}
partition_prefix "" {
namespace "default" {
node_prefix "" {
policy = "write"
}
agent_prefix "" {
policy = "write"
}
}
}
EOF
% consul acl policy create -name="redis-config-writer" \
-description="Allow write operations under redis/config/" \
-rules=@kvs-redis-config.hcl
ID: 15009bd7-d2aa-f9b0-386a-09dfbaa7a489
Name: redis-config-writer
# ...
次に、Sentinel ポリシーを記述し、ACL Policy 同様に Consul への登録を行います。
# redis/config/maxmemory への key への書き込み時には value が "1gb" 以外を許可しない
% cat >> ensure-kvs-redis-maxmemory.hcl <<EOF
key "redis/config/maxmemory" {
policy = "write"
sentinel {
enforcementlevel = "hard-mandatory"
code = <<EOC
main = rule {
value == "1gb"
}
EOC
}
}
EOF
% consul acl policy create -name="ensure-redis-maxmemory" \
-description="Ensure Redis maxmemory under redis/config/maxmemory" \
-rules=@ensure-kvs-redis-maxmemory.hcl
ID: d930a9ac-9f0f-c53c-3d06-c2803f55abb2
Name: ensure-redis-maxmemory
# ...
ポリシーの登録ができたら、Consul KVS へアクセスするためのトークンを発行します。
この時、先ほど登録した ACL Policy redis-config-writer と Sentinel Policy ensure-redis-maxmemory の policy-id を指定します。
% consul acl token create -description="Limited client access of Consul KVS" \
-policy-id=15009bd7-d2aa-f9b0-386a-09dfbaa7a489 \
-policy-id=d930a9ac-9f0f-c53c-3d06-c2803f55abb2
AccessorID: dd458c5f-1dee-290b-441c-dd2be9a379a7
SecretID: 11ad44e6-663a-4b32-2175-f9e1fc24d241
Partition: default
Namespace: default
Description: Limited client access of Consul KVS
Local: false
Create Time: 2025-12-27 23:14:20.090814 +0900 JST
Policies:
15009bd7-d2aa-f9b0-386a-09dfbaa7a489 - redis-config-writer
d930a9ac-9f0f-c53c-3d06-c2803f55abb2 - ensure-redis-maxmemory
出力の通り、２つのポリシーが適用されたトークンを払い出すことができました。
このトークンを利用して Consul KVS への操作を行います。
ポリシー評価を確認する
さっそく、ACL Policy および Sentinel Policy が適切に評価されているかを確認してみます。
ACL Policy では Consul KVS のパス redis/config/ への write 処理のみが許可されているため、異なるパスへの操作を行ってみます。
% export CONSUL_HTTP_TOKEN='11ad44e6-663a-4b32-2175-f9e1fc24d241'
% consul kv put mysql/config/version 8.0.0
Error! Failed writing data: Unexpected response code: 403 (Permission denied: token with AccessorID 'dd458c5f-1dee-290b-441c-dd2be9a379a7' lacks permission 'key:write' on "mysql/config/version" in partition "default" in namespace "default")
ACL Policy で許可されていないポリシーのため、ブロックされたことがわかります。
続いて、Senitnel ポリシーの方も確認してみます。
% consul kv put redis/config/maxmemory 1gb
Success! Data written to: redis/config/maxmemory
% consul kv get redis/config/maxmemory
1gb
ACL Policy により許可された操作であり、Sentinel ポリシーに準拠する場合には問題なく KVS 操作できることがわかります。
今度は、Sentinel ポリシーにだけ違反するようなケースの処理を行います。
redis/config/maxmemory の値は 1gb しか許可されていないため、異なる値で put 処理を行います。
% consul kv put redis/config/maxmemory 128mb
Error! Failed writing data: Unexpected response code: 403 (Permission denied: token with AccessorID 'dd458c5f-1dee-290b-441c-dd2be9a379a7' lacks permission 'key:write' on "redis/config/maxmemory" in partition "default" in namespace "default")
Sentinel ポリシーが適用され、put した値によって操作がブロックされたことがわかります。
出力こそ同じですが、Consul サーバのログを見ると以下のように Sentinel による評価が実行されているのを確認することができます。
2025-12-27T23:25:56.041+0900 [ERROR] agent.sentinel: Sentinel policy evaluation error:
error=
| Sentinel Policy Evaluation Failed
|
| Sentinel Result: false
|
| Sentinel evaluated to false because one or more Sentinel policies evaluated
| to false. This false was not due to an undefined value or runtime error.
|
| 1 policies evaluated.
|
| ## Policy 1: 166ee90eb924ac1437f72329888d8f0526a7c91f012bbfa5fa93da0341a54712 (hard-mandatory)
|
| Result: false
|
2025-12-27T23:25:56.041+0900 [ERROR] agent.http: Request error: method=PUT url=/v1/kv/redis/config/maxmemory from=127.0.0.1:56042 error="Permission denied: token with AccessorID 'dd458c5f-1dee-290b-441c-dd2be9a379a7' lacks permission 'key:write' on \"redis/config/maxmemory\" in partition \"default\" in namespace \"default\""
最後に
今回は Consul に Sentinel ポリシーを連携させ、Consul KVS に対するより高度な RBAC を試してみました。
今回は KVS 機能にフォーカスをしましたが、Consul では Serivice Discovery や Service Mesh などクラウドネイティブ環境における強力な機能を数多く持っており、Sentinel だけでなく HashiCorp プロダクトの連携によってセキュアで柔軟なクラウドインフラストラクチャを実現することが可能です。
Consul だけでなく Sentinel にも、この記事を読んで興味を持った方はぜひ実際に試してみてください！
これにて HashiCorp Japan 2025 Advent Calendar は終了となりますが、引き続き HashiCorp プロダクトに関する技術情報については発信をしていきます。
HashiCorp プロダクトに関する技術情報は多くが英語のドキュメントですが、日本語コンテンツ の拡充も鋭利取り組み中のため、興味がある方はぜひそちらもチェックしてみてください！
それではみなさま、よい年末年始をお過ごしください！