IstioのmTLS・認可回避などを修正｜1.31.4への更新と構成別の暫定策

Istioは2026年11月6日、サービス間通信の認証・認可回避、制御プレーン停止、クラスタをまたぐ秘密情報の開示などを修正したISTIO-SECURITY-2026-009を公表しました。上流Istioの1.31.0〜1.31.3と1.30.0〜1.30.7が対象で、利用者はそれぞれ1.31.4以降、1.30.8以降への更新を進めてください。

WebアプリやAPIをIstioのメッシュで保護している運用者が対象です。ambientを使っていない場合でも、sidecarのTPROXY設定やistiodへの接続経路によって影響します。「mTLSをSTRICTにした」「DENYを置いた」という設定の存在だけで安全とは判断できません。本記事は11月10日に確認した上流Istioの勧告を整理したもので、各社のマネージド製品へ上流版番号をそのまま当てはめるものではありません。

まずモードとポリシーの組み合わせを確認する

今回の修正は単一の入口を塞ぐ更新ではありません。ambient、sidecar、waypoint、マルチクラスタで成立条件が違います。台帳にはIstioの版だけでなく、制御プレーンのrevision、データプレーンの実行版、対象namespace、PeerAuthenticationとAuthorizationPolicy、TPROXYの利用有無を記録します。複数revisionを運用している場合、更新した制御プレーンと実際のワークロードの接続先を対応付けることが出発点です。

開発元が示す最大のCVSSは8.2ですが、これはambientのmTLS回避であるGHSA-rr2c-p22p-6r9rのCVSS v3.1値です。以下の全問題に同じスコアが付くわけではありません。取得した上流勧告には実環境での悪用確認の記載がなく、公開された再現例と実際の侵害は区別します。また、個別GHSAでCVE未割り当てとされる問題へ、別資料のCVE番号を推定で結び付けません。

ambientのポート単位STRICTが効かない条件

ambientのmTLS回避の個別勧告によると、メッシュ全体がSTRICT、namespace側にはSTRICT設定がなく、ワークロード側はPERMISSIVEまたはDISABLEで特定ポートだけSTRICTにする組み合わせで、ポート単位の制約が抜けます。設定を変換する論理式の優先順位に誤りがあり、ztunnelへ必要な拒否ポリシーが送られず、平文の接続を受け入れる可能性があります。sidecarでは同じ設定でもSTRICTが適用されるため、モード間の差が重要です。

開発元の暫定策は、ワークロード全体をSTRICTにし、平文が必要なポートだけPERMISSIVEへ例外化する方法、または対象namespaceへSTRICTのPeerAuthenticationを置く方法です。既存サービスが平文を必要とする場合、変更で正規通信も止まるため、依存関係を確認してから適用します。更新後の確認では、許可されたmTLS通信が通ることと、対象ポートへの平文が拒否されることを別々に記録してください。

Hostと送信元IPのルールを分けて点検する

Hostの大文字・小文字による認可回避は、AuthorizationPolicyのwhenでrequest.headers[:authority]またはrequest.headers[host]を判定する構成に影響します。ルーティング側はホスト名を大文字・小文字を区別せず扱う一方、当該条件は区別するため、同じ宛先へ到達してもDENYが一致しない場合があります。HTTP/1.1とHTTP/2の両方が対象です。暫定策はto.operation.hosts／notHostsを使うことで、既にhostsを使っているポリシーと混同しないようにします。

IP条件の認可不備は、ambient waypointとHBONEを受信するsidecarで、ipBlocks、notIpBlocks、source.ipがクライアントIPではなくEnvoy内部アドレスに対して評価される問題です。DENYの不一致だけでなく、notIpBlocksによる正規通信の拒否や、CUSTOMで外部認可が呼ばれない場合もあります。開発元はremoteIpBlocks、notRemoteIpBlocks、remote.ipへの置き換えを暫定策として示しています。通常のgatewayはこの問題の対象外です。

本サイトでは、各ポリシーについて「どのプロキシが評価するか」「期待するIPは何か」「ALLOW・DENY・CUSTOMのどれか」を表にすることを提案します。キー名だけを一括置換せず、プロキシを通った実際のアドレスと、許可・拒否双方の結果を検証環境で確認します。Host条件も、正規の小文字表記だけを試すのではなく、大文字を交ぜた同一ホストに対する拒否結果まで確認します。

TPROXYのsidecarでは再接続時の経路が問題になる

sidecarのTPROXY回避では、切断済み接続のconntrack状態が残る間に同じ送信元・宛先IPとポートを使って再接続すると、Envoyを経由せずアプリへ直接届く可能性があります。その場合はmTLSとAuthorizationPolicyの評価が抜けます。既定のREDIRECTではなくTPROXYを使うsidecarが個別勧告の対象で、iptablesとnftablesの両経路を確認します。

開発元の暫定策はREDIRECTへの切り替えですが、この方式では元のクライアント送信元IPが保持されません。IPベースの監査や制御に依存するサービスでは、この副作用も判断材料です。更新後は長く接続したままの正常性だけでなく、接続プールや再接続が発生する経路も試験対象にします。ネットワークルールの変更を伴うため、既存Podを含む反映方法は利用中のインストール方式に合わせて確認してください。

istiodの再起動だけでは解消しない停止経路

istiodのdebug xDS要求によるDoSは、有効なメッシュIDを持つワークロードから細工した要求を受けると、制御プレーンが停止する問題です。単なるインターネット上の匿名アクセスとは条件が違いますが、Podやサービスアカウントトークンを作成できる利用者の範囲が影響します。開発元は設定だけの回避策はないとし、作成権限の制限を挙げています。再起動しても要求が繰り返されれば再発します。

空のto／fromによるambientのDoSは、検証Webhookを通過しなかった空要素のAuthorizationPolicyが保存される構成で、istiodが再起動を繰り返す問題です。こちらは問題のポリシーを除去しないと復旧しません。開発元の暫定策はglobal.configValidationを有効にし、default revisionまたはdefault revision tagにより検証Webhookが存在する状態を保つことです。単にプロセスを再起動する運用では、この二つの原因を見分けられません。

制御プレーン停止時は、アプリの既存通信が残っていても対応を後回しにしないでください。構成・エンドポイントの更新、証明書発行、Admission Webhookなどへ影響します。運用上はistiodの再起動回数、構成配信の停滞、新規ワークロードの起動失敗をまとめて確認し、障害の開始時刻とポリシー変更時刻を対応付けると、通常のアプリ障害との切り分けに役立ちます。

マルチクラスタとHBONEには別の確認が必要

クラスタをまたぐTLS秘密情報の開示では、認証したクラスタとプロキシが申告するCLUSTER_IDの不一致が許され、別クラスタのkubernetes://秘密情報を取得できる場合があります。同じnamespace名とサービスアカウント名を各クラスタのgatewayに使う構成が重要です。単一クラスタは対象外です。暫定策としてクラスタごとにgatewayのnamespaceまたはサービスアカウント名を分ける方法があります。remote credentials controllerの停止だけではconfig clusterの秘密情報は残るため、全面的な解決とは扱えません。

ztunnelのtraceparent解析による停止は、不正な形式のtraceparentを受けるとHBONE接続タスクが終了し、同じ接続へ多重化された他のストリームも切れる問題です。有効なメッシュIDが必要ですが、gatewayやwaypointが外部のヘッダーをそのまま転送する経路も確認します。開発元は信頼できるIDだけにHBONEを限定することや、該当経路でtraceparentを除去・上書きする緩和策を示しています。後者はトレース伝播を失う点に注意が必要です。

更新と再確認を一つの作業として進める

上流の更新先は1.31系列が1.31.4以降、1.30系列が1.30.8以降です。1.31.4のリリースノートでは、これらに加えてJWKSの定期取得結果の検証修正も説明されています。サポート外の系列を、この影響版一覧にないことだけで安全とは判断しません。配布元が独自に修正を提供する製品は、その告知とビルド番号で判断します。

以下は本サイトが提案する確認順です。最初にモードと影響ポリシーを棚卸しし、次に互換性と復旧手順を確認した上で制御プレーン・データプレーンを更新します。その後、mTLSが必要なポート、Host条件、送信元IP条件、再接続、マルチクラスタの資格情報という順に、自社で使う境界を確認します。攻撃用の異常要求を本番へ送って合否を判定するのではなく、隔離した検証環境で拒否側の試験を準備してください。

完了記録には更新前後の版、対象revision、Podやztunnelの反映状況、適用した暫定策、許可・拒否の試験結果を残します。暫定策を外す場合も、修正版の反映と正規通信を確認してから行います。一般的な段階展開と切り戻しの考え方は、本文を確認した既存記事「緊急パッチを安全に適用する実務ランブック」も参考になります。設定ファイルが意図を示していても、実際の通信経路で制約が働くことまで確認するのが今回の対応の要点です。