consul-k8sに認可のすり抜け CVSS 9.9 1.9系と2.0系は2.1.0へ

1つのKubernetesのクラスタを名前空間で分け、複数のチームで使っている。そこでConsulを動かしているなら、consul-k8sの版を今週のうちに確認しておきたいところです。

HashiCorpは2026年10月26日（米国時間）、consul-k8sの脆弱性CVE-2026-110720を、勧告HCSEC-2026-50で公表しました。別の名前空間でサービスアカウントを作れる人が、Consulの部品になりすまして、その権限を得られるおそれがあります。CVSSv3.1の基本値は9.9です。

部品を見分ける規則が、名前空間を見ていなかった

Helmの設定でglobal.acls.manageSystemACLsをtrueにすると、consul-k8sはConsulのACLを自動で管理します。KubernetesのサービスアカウントでConsulにログインする認証方式を作り、どのサービスアカウントにどのロールを渡すかを、バインディングルールで決める仕組みです。

このルールが、サービスアカウントの名前しか見ていませんでした。

consul-k8sの変更履歴によると、Consulを入れた名前空間の外にあっても、同じ名前のサービスアカウントならログインでき、部品のロールを受け取れたといいます。勧告が挙げる条件は2つです。別の名前空間でサービスアカウントを作り、そのトークンを取れるKubernetesの権限。それに、ConsulのAPIへ届く経路です。

CVSSのベクトルでも、必要な権限は「低」、影響の範囲は「変わる」とされています。一部の名前空間で動ける程度の権限から、Consulの部品の権限へ広がる、という評価でしょう。勧告に、悪用の記載はありません。

ACLの自動管理を使っていなければ対象外

対象はconsul-k8sの0.42.0から2.0.4までで、manageSystemACLsを有効にした環境です。Helmのリファレンスでは、この値の初期値はfalseになっています。

影響が大きいのは、名前空間ごとに別のチームや顧客、CIのジョブへ権限を渡しているクラスタです。開発チームが自分の名前空間でサービスアカウントを自由に作れる運用なら、条件の1つめはもう満たしています。

クラスタの管理者しかサービスアカウントを作れない運用なら、すぐ悪用される場面は限られます。ただ、管理者のアカウントやCIのトークンが奪われれば同じことが起きるので、更新を先送りする理由にはなりにくいでしょう。

修正版は2つの系列だけ、1.9系と2.0系は2.1.0へ

修正版は、10月23日に出た2.1.0と、10月19日に出た1.8.18です。consul-k8sはHelmのチャートと同じ版番号で配られていて、HashiCorpのHelmのリポジトリにも、consulのチャートの2.1.0と1.8.18が載っています。

1.9系と2.0系には、修正の入った版がありません。HashiCorpの互換表と変更履歴では、consul-k8sの2.1系はConsul 2.1系と組み合わせる版です。consul-k8sだけでなく、Consul本体も2.1系に上げる更新になります。

同じ日に、Consul本体にも4件

HashiCorpは同じ10月26日に、Consul本体の勧告も4件出しています。修正版はCommunity Editionの2.1.0と、Enterpriseの2.1.0・1.21.19です。

CVSSの値は、GitHubのアドバイザリーのデータベースに載ったものです。46と47、49の3件は、ACLを有効にした環境が対象とされています。Community Editionの1.21系と1.22系、2.0系には、本体の修正の入った版が出ていません。

46には更新までの回避策も書かれています。エージェントのHTTP APIへの経路を絞るか、http_config.block_endpointsで証明書を返すエンドポイントを止める方法です。止めてよいのは、このエンドポイントを使うものが、そのエージェントに無いときだけです。Connectネイティブのアプリと、consul-templateの設定がこれにあたります。

上げる前に読んでおく注意

更新の作業そのものについても、consul-k8sの変更履歴は注意を書いています。

まず、Consulを入れた名前空間の外で部品を動かしている場合です。直したルールは名前空間も条件にするため、そうした部品はConsulの名前空間へ移す必要があります。

次に、一度有効にしてから無効にした部品のルールです。sync-catalogやメッシュゲートウェイなどがこれにあたり、古いルールは更新しても書き換わりません。残ったルールは手で消すか、その部品を一度有効にしてから更新します。

Consul 2.1.0の変更履歴にも、互換性のない変更が並んでいます。たとえば透過プロキシの通信の振り分けは、iptablesからnftablesに変わりました。カーネルの対応が要り、iptablesへ自動で戻る仕組みも無いとされています。透過プロキシを使っているなら、検証環境で先に通しておくと安心です。

版の確認から更新までの手順

1. Helmで入れたConsulの版を、helm list -Aで確認します。CHARTの列にconsul-2.0.4のように出ます。
2. helm get values <リリース名> -n <名前空間> --allを流し、global.aclsのmanageSystemACLsがtrueかどうかを見ます。trueなら対象です。
3. Consulの名前空間にある部品のサービスアカウントの名前を控え、同じ名前がほかの名前空間に無いかをkubectl get serviceaccounts -Aで探します。
4. 名前空間ごとに、サービスアカウントを作れる人とジョブ、トークンを取れる人とジョブを洗い出します。kubectl auth can-i create serviceaccounts -n <名前空間> --as <利用者>と、--subresource=tokenを付けた同じコマンドで確かめられます。勧告にconsul-k8sの回避策は書かれていないので、更新までの間は、この2つの権限を要る人に絞ります。
5. 系列に合わせて上げます。1.8系は1.8.18へ、1.9系と2.0系はConsul 2.1.0と組み合わせて2.1.0へ上げます。EnterpriseのConsul 1.21系なら、本体は1.21.19です。
6. 更新のあとで、consul acl binding-rule list -method <prefix>-k8s-component-auth-methodでルールを一覧にします。セレクターにConsulの名前空間の条件が入ったことと、無効にした部品の古いルールが残っていないことを確認します。古いルールはconsul acl binding-rule delete -id <id>で消します。

名前空間で分けたクラスタは、名前空間を壁として運用しがちです。今回の件は、その壁の外にあるConsulのルールが、名前空間を見ていなかったという話でした。チームに名前空間を渡すとき、サービスアカウントとトークンをどこまで作らせるかも、この機会に決め直しておきたいところです。

Consulの秘密情報の保存先を、Vaultにしている会社もあるでしょう。Vaultの10月の修正版は、VaultとOpenBaoのRaftのスナップショットの脆弱性の記事にまとめています。