Amazon EKSのNetworkPolicy回避を修正 同居Podへの着信制限を確認

AWSは米国時間2026年11月4日（日本時間11月5日）、Amazon EKSのNetwork Policy Agentで、同じノード上にあるPodへの着信制限を回避され得る脆弱性CVE-2026-122266を公表しました。対象はAmazon VPC CNIでNetworkPolicyの強制を有効にしている構成です。AWSが示す修正版は、マネージドアドオンが1.22.3、Network Policy Agentが1.3.7です。対象環境では互換性のある修正版へ更新し、各ノードで切り替わったことと、本来拒否される通信が拒否されることを確かめてください。

AWS Security Bulletin 2026-170-AWSは回避策なしとしています。NetworkPolicyの定義を追加するだけでは、定義を適用する側にある今回の不備は直りません。複数チームのアプリや利用者が持ち込むコードを同じノード群で動かしている場合は、共有ノード上でどの内部サービスを着信ルールだけで守っているかを先に洗い出します。更新前後の確認手順は本稿の運用提案であり、AWS環境での実測結果ではありません。

同じノードにいるPodの着信ルールが対象

KubernetesのNetworkPolicyは、Podを選び、許可する通信元や宛先、ポートなどを指定する仕組みです。Amazon VPC CNIでこれを利用する場合、Network Policy Agentがノード側で適用します。今回の問題では、エージェントが使うeBPFの接続追跡情報の分離が不十分でした。AWSのNetwork Policy Agent個別勧告によると、一定の条件を満たすワークロードから加工したフレームが送られると、共有される接続追跡の情報が汚染され、同じノード上にある別のPodへの着信ルールが適用されなくなる可能性があります。

攻撃の前提は、認証された隣接ユーザーが関係するワークロードから通信を送れることです。インターネットから公開URLを開くだけで成立するとは、AWSは説明していません。一方で、攻撃元と宛先が異なる名前空間にあっても、同じノードで動く場合は影響し得ます。名前空間でリソースを分け、Kubernetes APIへの権限を制限していても、稼働中の内部サービスへの着信が同じ境界で守られるとは限りません。管理APIの権限と、アプリがネットワークから到達できる範囲を別々に確認してください。

AWSの開発元勧告では深刻度はHigh、CVSS 3.1の基本値は8.7です。勧告はエージェントやPod自体の可用性には影響しないとしています。Podが正常に動き続けていることや、再起動が増えていないことから、着信制限が守られていたとは判断できません。また、着信ルールの回避は到達性の問題です。到達した先でアプリの認証まで突破できるかは、サービスの構成に依存します。AWSの勧告本文から実環境での悪用は確認できません。

稼働中の版と適用条件をクラスターごとに確認する

点検対象は、Kubernetes本体の版だけでは絞れません。クラスターごとに、VPC CNIの管理方式、実際に稼働中のアドオンとエージェント、NetworkPolicyを強制しているかを記録します。設定ファイルの記述と稼働状態に差があることを想定し、Git上の定義だけで判定しません。たとえば、複数リージョンで同じテンプレートを使っていても、一部のアドオンの更新が保留されたり、独自イメージの参照先が残ったりしていることがあります。過去にクラスターへ適用した定義と、現在のコントローラーが同期する定義の両方を確認します。

AWSのEKSネットワークポリシーガイドによると、Amazon VPC CNIによるネットワークポリシーはAmazon EC2のLinuxノードが対象で、FargateやWindowsノードでは適用できません。混在するクラスターでは、クラスター全体を一つのラベルで片付けず、対象サービスがどのノードで動くかを確認します。また、別のプラグインでポリシーを実装する構成に、この勧告の影響をそのまま当てはめないでください。ポリシーのYAMLが同じでも、適用する実装が異なります。

調査の起点には、次の読み取りコマンドを使えます。リージョンやクラスター名を自分の環境に置き換え、AWS CLIとkubectlが同じ対象を指すことを確認してから実行します。管理APIが返す版と、DaemonSetが指定するイメージは別の観測点です。

aws eks describe-addon --region REGION --cluster-name CLUSTER \
  --addon-name vpc-cni --query 'addon.{Version:addonVersion,Status:status}' --output table
kubectl -n kube-system get daemonset aws-node \
  -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\t"}{.image}{"\n"}{end}'
kubectl get networkpolicy -A

アドオンの問い合わせに失敗した場合は、権限、リージョン、名前の指定を切り分けます。APIのエラーだけで自己管理と断定せず、導入台帳やGitOpsの管理対象を参照します。NetworkPolicyの一覧にリソースが出ても、それは定義の存在を示すだけです。どの実装が処理しているか、各環境で強制設定が有効か、実際に選ばれるPodが想定どおりかを確認します。逆に一覧が空でも、取得権限が足りない場合やクラスター単位のポリシーを利用する場合があるので、一覧出力の意味を構成と照合します。

マネージドと自己管理で変更先を分ける

マネージド環境ではAWSのEKSアドオン更新手順に沿い、現在のKubernetesバージョンとリージョンで選択できるアドオン版をdescribe-addon-versionsで調べます。1.22.3は勧告が示す修正の境界です。EKSの配布ではビルド番号を含む版を指定するため、手元のクラスターで返る完全な文字列から修正済みの版を選びます。既存設定がある場合は、変更前の設定を記録し、競合解決方法を確認します。既定値での上書きは、ネットワークポリシーや別のVPC CNI設定を変える可能性があるため、検証環境で差分を確認してください。

自己管理の場合はAWSの自己管理VPC CNI更新手順を基に、実際に配備を管理するマニフェストやデプロイ設定を更新します。ミラーしたコンテナイメージや独自ビルドを使う場合は、名前やタグだけで修正を判断せず、元リリースや修正取り込みの記録を照合します。管理外でDaemonSetだけを手動変更すると、同期が動いて旧版へ戻ることがあります。新規クラスターを作るテンプレートや、災害復旧時に使う配備定義にも版指定がある場合は、そこにも修正済みの版を反映します。

導入順序は、共有ノードで機密性の高い宛先を守るクラスターを優先します。ただし、疎通が止まると復旧手段まで失われる環境では、先に別の管理経路を確認しておきます。修正前に影響を抑える必要があるなら、信頼境界をまたぐワークロードの同居を減らし、宛先サービス側の認証を確認する方法が考えられます。これらは本稿の露出低減策です。AWSが示す修正の代わりにはならず、再スケジュールで配置が変わることも考慮します。

更新後は許可と拒否の両方を検証する

マネージド環境ではアドオンの状態がACTIVEになったことを確認し、続けてDaemonSetのロールアウトと、各対象ノードの実際のPodを確認します。テンプレート上のイメージが修正版でも、旧Podが置き換わる途中や、特定ノードで新Podが準備できていない場合があります。ノード名、稼働中のイメージ、準備状態を一覧にし、確認対象から漏れたノードがないかを見ます。後で追加するノードにも修正版が配備されることを、検証環境のノード追加で確かめると、更新時点だけの確認を避けられます。

疎通テストでは、検証用の宛先を用意し、許可される送信元と拒否される送信元から同じ宛先の同じポートへ新規接続します。先に許可側が成功していれば、拒否側の失敗を宛先自体の停止と混同しにくくなります。今回の条件に合わせて、送信元と宛先が同じノードに配置されたことをPodの情報で確認します。別ノードの場合も比較用に記録できますが、別ノード間だけの結果で今回の着信制限を確認したとは扱いません。独立した検証用のDeploymentを使い、実データや実際の攻撃フレームは持ち込まない方法で十分です。

接続試験は、通常のポリシー適用と更新後の回帰を確認するためのものです。成功結果だけで脆弱性の悪用が再現できなくなったことを証明するものではありません。拒否すべき経路が通った場合は、まず対象Podを選ぶラベル、名前空間の条件、同じPodを選ぶほかのポリシー、実際の接続先を点検します。許可される通信まで止まる場合は、宛先の準備状態と、ポートの指定や名前解決、送信側の制限を順に切り分けます。版、ポリシー、疎通の三つを分けて記録しておくと、問題が起きた際にどの変更を戻すべきかを判断できます。

以前の到達を調べるときはアプリ側の記録も見る

更新は以後の脆弱な挙動を修正する作業で、過去の到達の有無までは分かりません。懸念があるクラスターでは、保存済みのPodの配置履歴や監査ログが利用できるなら、どのワークロードが重要な宛先と同居し得たかを調べます。さらに、宛先サービスのアクセスログやアプリ認証の失敗、想定外の内部接続などを照合します。PodのIPが変更される環境では、現在のIPだけで以前の通信主体を決めず、時刻とその時点の配置を合わせます。

ログがなければ、過去の到達を否定できない範囲を残します。すべての内部通信を記録しているとは限らず、ポリシーの拒否ログがないことも安全の証明にはなりません。更新の完了記録には、影響対象、配備した版、正常系と拒否系の結果、調査できた過去の範囲を分けて記載してください。将来のアドオン更新で同じ比較ができるよう、許可される経路と拒否される経路の組み合わせも残しておくと、今回の対応を次の点検に使えます。

関連記事

AWS Private CAのKubernetes連携を更新するときの確認点