Kubernetes連携のconsul-k8sに認可不備｜別名前空間からの権限取得を防ぐ

KubernetesでConsulを運用する環境に、別の名前空間のServiceAccountからConsulコンポーネントの権限を取得され得る脆弱性CVE-2026-110720が公表された。対象はconsul-k8sでシステムACLの自動管理を有効にした構成。修正版への更新に加え、過去に無効化したコンポーネントの古いACLルールが残っていないかを確認する必要がある。

本件は10月28日に国内で報じられた脆弱性ニュースで、開発元HashiCorpの告知HCSEC-2026-50の初回公表日は2026年10月26日。Kubernetes本体のすべての構成に影響する問題ではなく、Consulとの認証・認可を接続するconsul-k8sの問題として、自社の導入有無と設定から判断したい。

影響する設定と攻撃者に必要な条件

consul-k8sは、Kubernetes上のコンポーネントがConsulトークンを取得できるよう、認証方式とACLのbinding ruleを構成する。binding ruleは、認証されたServiceAccountをConsulのロールなどへ関連付けるルールだ。Kubernetes側のアカウントが存在することと、その主体へConsulの権限を与えてよいことは別々に判断する必要がある。

今回の不備では、コンポーネント向けルールがServiceAccountの所属する名前空間を一貫して制限していなかった。攻撃者が別の名前空間でServiceAccountを作成してそのトークンを取得でき、さらにConsul APIへネットワーク経由で到達できる場合、正規コンポーネントとして認証され、関連するConsul権限を得る可能性がある。

開発元が示す対象設定はglobal.acls.manageSystemACLs=true。システムACLの自動管理を無効にした配置は、本件の対象ではないと告知されている。公式Helm設定リファレンスでも、この設定がConsulとconsul-k8sのコンポーネント用トークン・ポリシーの自動管理を行うものだと確認できる。

global:
  acls:
    manageSystemACLs: true

このYAMLは影響条件を照合するための設定例であり、新たに有効化する推奨設定ではない。手元のvaluesファイルだけでなく、実際にデプロイしたリリースの設定と突き合わせる。独自の設定上書き、別チームが管理するリリース、過去の変更があれば、リポジトリ上の一つのファイルだけでは現在の状態を確定できない。

公式CVEレコードの評価はCVSS v3.1で9.9（Critical）、分類はCWE-863の不適切な認可。攻撃者にはKubernetes上の権限が必要であり、インターネット上の誰もが無条件に実行できる問題とは異なる。得られるのは該当コンポーネントに関連するConsul権限で、これだけでKubernetesのcluster-admin取得や任意コード実行が確定するわけではない。

同じアカウント名でも名前空間が違えば別の主体

開発元の修正PR #5749は、従来のルールがServiceAccount名だけを照合し、別の名前空間にある同名アカウントでもログインできたと説明している。修正ではConsulリリースの名前空間も条件へ加える。名前の一致を、所属先を含めた主体の一致と取り違えたことが、今回の権限境界の崩れにつながった。

たとえば、アプリ用の名前空間をチームへ委任し、Consulの管理用コンポーネントを別の名前空間に置く運用がある。このとき、アプリ側の作成権限を渡しても管理側の権限は渡していない、という設計が前提になる。本件ではその分離がConsul側のロール割り当てで失われ得る。名前空間を分けている事実だけで対象外にはできない。

優先度は、複数チームや自動デプロイ基盤へServiceAccount作成・トークン取得の権限を委任しているか、そこからConsul APIへ到達できるかで変わる。外部公開していないConsulでも、クラスタ内部の利用者や侵害された自動化資格情報からの経路を確認したい。単にAPIの公開ポートだけを点検して調査を終えない。

修正版の選択ではConsul本体と連携部品を分ける

HCSEC-2026-50は、影響版をconsul-k8s 0.42.0から2.0.4までと記載し、修正版として1.8.18と2.1.0を案内している。1.8.18は修正済みの例外なので、数字の大小だけで0.42.0以上2.0.4以下をすべて同じ状態と扱わない。運用している系列に対応する修正版を選ぶ。

なお、確認したCVE JSONの版情報には上限が「2.0.4未満」と記述され、告知の「2.0.4まで」と表現に差がある。2.0.4を安全と判断する根拠にはせず、開発元告知が指定する修正版へ進む方針を取る。表現差のある境界版を使用している場合は、開発元への確認も併せて行いたい。

更新ではconsul-k8s、Helm chart、Consul本体の版を区別する。公式のKubernetes向け更新手順は、chartの更新とConsul本体の更新を分け、互換性表と途中の変更履歴の確認を求めている。Consulのサーバーイメージだけを変更して、連携部品の修正まで反映したと判断しない。

helm list --filter consul --namespace consul
helm search repo hashicorp/consul --versions

これは公式手順にある版確認の例。リリース名や名前空間が異なる環境では実際の値に置き換える。表示されるCHARTとAPP VERSIONを同一視せず、更新対象となる連携部品のイメージも確認する。chartの更新を実行する際は対象版を明示し、手元のキャッシュの最新値に任せた意図しない系列移行を避ける。

既存のvaluesを保持した更新計画を作り、検証環境で認証、サービス登録、ゲートウェイ、通常のアプリ通信を確認してから本番へ進める。修正済みの版名を設定したことと、そのイメージで必要な処理が実際に完了したことは別だ。管理用Jobの結果と稼働中の構成を読み戻し、未反映のリリースを取り残さない。

無効化済みコンポーネントの古いルールを残さない

公式リリースノートには、更新前に無効化されていたコンポーネントのbinding ruleは書き換えられない、という重要な注意がある。以前にsync-catalog、mesh-gateway、gatewayなどを有効化し、後から止めた構成では、現在の有効コンポーネントだけを見ると古いルールを見落とす可能性がある。

開発元は、そのコンポーネントの認証方式に残る古いルールを削除するか、コンポーネントを一度再び有効にして更新を実行し、ルールを書き換える方法を示している。どちらを選ぶ場合も、使用中のルールとの対応を確認する。名前が似ているという理由だけで削除せず、対象の認証方式、ロール、利用履歴を特定してから変更する。

また、リリースの名前空間の外で動作するコンポーネントは、その名前空間へ移す必要があると案内されている。修正後に認証できなくなったからといって、照合条件から名前空間を外すと保護が失われる。配置を分けた独自構成がある場合は、更新前に移行の要否を洗い出し、標準構成との差を確認する。

ACLルールの読み戻しで更新の成否を確認する

既存ルールの確認にはConsulのbinding-rule listコマンドを使える。読み取りにはacl:readが必要だ。承認済みの読み取り用資格情報とTLS設定を利用し、トークンの秘密値をコマンド履歴や調査資料へ貼り付けない。次は一覧をJSONで取得する読み取り操作である。

consul acl binding-rule list -format=json

結果ではAuthMethod、Selector、BindType、BindNameを照合する。コンポーネント用のルールがどの認証方式に属し、どのロールを与え、ServiceAccount名に加えてConsulリリースのKubernetes名前空間も限定しているかを確認する。一般ワークロード向けのルールと混ぜず、今回のコンポーネント認証用ルールを特定することが先になる。

Consul EnterpriseのCLIにあるnamespaceオプションはConsul側の名前空間を選ぶものであり、KubernetesのServiceAccountの所属先を照合する条件そのものではない。別の名前空間を指定して一覧が空になったことを、安全になった証拠にはしない。認証方式やデータセンターなど、調査している管理範囲が正しいことも記録しておく。

一覧取得が権限エラーになる場合は、修正の失敗ではなく調査用資格情報の権限不足かもしれない。接続できない場合は通信経路やTLS設定を先に切り分ける。エラーをなくすために管理トークンを広く配ったり、証明書検証を無効にしたりせず、調査担当者が必要な範囲だけ読める状態を整える。

拒否されることと通常運用が続くことを分けて試す

以下は本サイトによる検証計画の提案であり、実環境での実測結果ではない。検証用の隔離環境で、正規の名前空間のコンポーネントが必要な処理を継続できることと、別の名前空間の同名ServiceAccountにコンポーネントの権限を与えないことを別々に確かめる。成功する管理者操作だけでは境界の修復を確認できない。

拒否試験では、本番の管理トークンや機密情報を使わず、試験用の役割と到達先を準備する。タイムアウトと認可拒否は意味が異なるため、ネットワーク的に到達できなかった試験をACLの修正確認として数えない。取得したトークンや試験用アカウントを残さず、期待値と実際の結果を対応付けて記録する。

更新待ちの間に、不要なServiceAccount作成・トークン取得の権限を減らし、Consul APIへ到達できる主体を制限することは露出低減の選択肢になる。ただし、これは本サイトの運用上の提案で、開発元が保証した完全な回避策ではない。manageSystemACLsを単にfalseへ変えても、既存ルールの除去や安全な移行を済ませたことにはならない。

不審な認証や権限利用が疑われる場合は、ルールを変更する前に利用可能な認証記録、Kubernetesの操作記録、設定差分を保全する。今回確認した告知には実環境での悪用確認は記されていない。侵害がないと断定せず、想定外の主体へ発行された権限があれば、そのトークンと実行可能だった操作を調査対象にする。

完了条件は、修正版の稼働、対象ルールへの名前空間制約、無効化済みコンポーネントの残存ルール処理、正規処理の継続、越境する主体の拒否を確認できた状態に置きたい。Kubernetes側の委任権限とConsul側のロールを同じ台帳で対応付けると、今回の修正を単なるイメージ更新で終わらせずに済む。

関連記事

Consul本体の別件であるサービスメッシュ登録でEnvoy設定の権限チェックを回避できる脆弱性も公表されている。そちらはサービス登録権限とmesh writeの境界が主題で、本件のKubernetes認証ルールとは影響条件と更新対象が異なる。