Kubernetesで広く使われるIngress Controller「ingress-nginx」に、Nginxの設定生成プロセスを悪用される可能性がある脆弱性が報告されています。IngressなどKubernetesリソースの入力値により、意図しないNginxディレクティブが設定へ混入する「Nginx構成注入」が起点です。
Ingress Controllerはクラスタの入口に位置するため、侵害や設定改ざんが外部公開面全体へ波及しやすい点が特徴です。条件次第では任意コード実行（RCE）に至る恐れもあり、単一アプリの脆弱性よりも被害半径が大きくなりがちです。
情シス・運用担当としては、単なるバージョン更新に加えて「誰がIngressを変更できるか」「危険な入力をどう遮断するか」「侵害時にどこまで到達できるか」をセットで見直す必要があります。特にマルチテナントや共通Ingress運用では優先度が上がります。
ingress-nginxは、Ingressリソースやアノテーションを基にNginx設定を自動生成します。脆弱性の本質は、この変換・テンプレート処理や入力値の取り扱いを突いて、攻撃者がNginx設定断片を混入させる点にあります。
攻撃成立の鍵は、攻撃者が「設定生成の入力」を操作できることです。つまり、Ingressの作成・編集権限（RBAC）を持つユーザー、または侵害されたCI/CDサービスアカウントが悪性Ingressを投入できると危険度が一気に上がります。
また、共通Ingress Controllerがクラスタ全体のIngressを集約している場合、あるNamespaceの悪性定義が他チームの公開サービスへ影響し得ます。修正版としては系統別にv1.13.9、v1.14.5、v1.15.1が示されており、まずは自組織の導入経路（Helm、マネージドKubernetesのアドオン等）に沿って適用判断が必要です。
構成注入が起きると、ルーティングやリダイレクト、ヘッダ操作など外部公開面の挙動が攻撃者に握られる可能性があります。これにより正規通信の改ざん、認可回避、想定外の内部宛てプロキシなどが発生し得ます。
さらにIngressでTLS終端や認証連携を担っている場合、設定改ざんはセッションや機密情報の保護に直結します。ログやサブリクエスト、変数展開などNginxの機能が絡むと、情報漏えいから権限境界の突破まで連鎖し、条件次第でRCEに至る恐れがあります。
運用面では、Ingressは変更頻度が高く「通常の変更」に悪性変更が紛れやすい点がリスクです。したがって、緊急対応としては(1)アップデート、(2)Ingress権限の最小化、(3)危険なアノテーション／スニペット系機能の統制、(4)NetworkPolicy等で侵害時の到達範囲を最小化、(5)監査・検知の整備を同時に進める必要があります。
今回の論点は「外部公開面の設定が動的生成される」こと自体が攻撃面になる点です。明日から実施する優先順は、まずingress-nginxを修正版（v1.13.9/v1.14.5/v1.15.1）へ更新し、導入形態に応じた回避策の有無も確認します。
次に、Ingress作成・更新権限を最小権限へ是正し、CI/CDサービスアカウントの権限過多を解消します。加えてスニペット注入や危険なアノテーションを原則禁止とし、Admission（OPA/Gatekeeper、Kyverno等）で危険定義を拒否できる状態にします。
最後に、NetworkPolicyでIngress Controllerからの到達先を必要最小限に絞り、監査ログでIngress/ConfigMap等の変更を追跡・アラート化します。パッチ＋権限＋入力制御＋分離＋可視化をワンセットで回すことが、再発と横展開を防ぐ現実的な対策です。
ingress-nginxの深刻な脆弱性とは？Nginx構成注入によるコード実行リスクとKubernetes運用で取るべき対策
