Kubernetes Ingress NGINXが2026年3月にEOL——“クラスタの表玄関”が無保守化する前に移行計画を走らせるべきです

今日の深掘りポイント

• コミュニティ版 Ingress NGINX が2026年3月にサポート終了。以降は新リリース・バグ修正・セキュリティ更新なしという「無保守のインターネット向きミドルウェア」を抱えるリスクが現実化します。
• Datadogの観測では、クラウドネイティブ環境の約半数が Ingress NGINX に依存。影響面積が大きく、優先度は最上位に引き上げるべきです。
• 直近で高深刻度の脆弱性が報告された点も相まって、放置は脅威アクターに“入口”を無期限で開放するのと同義です。
• 代替は Gateway API に準拠したコントローラーを第一候補に。段階的な二重運用・トラフィックミラーリング・アノテーション移行の設計が成否を分けます。
• 本件の緊急性と実行可能性は高く、新規性は限定的でも、広範かつ即時の行動が必要なタイプのリスクです。CISO/運用責任者はリスク台帳で“経営アテンション”に格上げすべきです。

参考: Datadog Security Labs による引退警告の分析と利用状況データ Datadog Security Labs です。

はじめに

プロダクションの“表玄関”である L7 リバースプロキシが、ある日を境に修正もパッチも届かなくなる——この種のEOLは、ゼロデイの到来と同等、もしくはそれ以上の重さを持ちます。攻撃者は脆弱性の「棚卸し」を始め、運用現場は仕様差とアノテーションに縛られた設定をほどきながら、交通整理をやり直すことになります。遅らせるほど、セキュリティもSLAも、説明責任のハードルも上がります。今日のPickUpでは、事実関係と移行設計の勘所、そして現実的な脅威シナリオまで一気に整理します。

深掘り詳細

事実（確認できていること）

• Kubernetesコミュニティの Ingress NGINX は2026年3月で引退し、以後はリリース、バグ修正、セキュリティ更新が提供されない見通しです。Datadogはそのリスクを警告しています。出典: Datadog Security Labs です。
• Datadogのテレメトリでは、クラウドネイティブ環境の約50%が Ingress NGINX を使用しているとされます。同記事は、直近で高深刻度のCVEが報告されたことも指摘し、無保守ソフトの継続運用リスクの高さを強調しています。同上 です。
• 重要な補足として、コミュニティの「Ingress NGINX」と、ベンダー提供の「NGINX Ingress Controller（F5 NGINXの商用/OSS版）」は別プロジェクトです。名称が似ており現場で混同が起きやすいため、資産棚卸しで正体の切り分けが必須です（本稿の事実確認は前者に関するものです）。

インサイト（運用・リスクの読み解き）

• EOLは「脆弱性が見つかる確率」だけでなく「見つかった後の封じ込め不能性」を跳ね上げます。特にエッジに位置するIngressは攻撃面が広く、露出時間の長さがそのまま期待損失を押し上げます。仮に既知脆弱性が“まだ”顕在化していなくとも、移行を先送りするほど将来の一括移行コストと停止リスクは累積します。
• Gateway API 準拠コントローラーへの移行は、アノテーション依存からポータブルなCRDモデルへの脱皮を意味します。長期的には運用の一貫性が増し、テスト可能性も向上します。短期的には「アノテーションの意味論」をどう移植・代替するかが難所です。とくに server-snippet 等の機能的“抜け道”は、セキュリティ上の負債になりやすく、Admissionでの明示的な制御と併走が必要です。
• スコアの示唆を総合すると、これは「広い適用範囲 × 今すぐ動ける × 定性的には厳しめ」という案件です。新規性は中程度でも、運用と監査の双方に直撃します。よって、技術移行の話に閉じず、SLA、監査適合、委託・再委託の境界（CDN/クラウドLB/マネージドIngress等）を含む“サービス境界の再定義”を同時に進めるのが肝心です。

脅威シナリオと影響

以下は、Datadogの警告と一般的な運用実態を踏まえた仮説シナリオです。MITRE ATT&CKの観点も添えます（技法名で記載、実態は各環境で異なるため要チューニングです）。

• シナリオ1: 未適用の高深刻度脆弱性を突いた入口突破

  • 仮説: コントローラがインターネットに面し、既知/未知のRCE脆弱性を悪用され、コントローラPod内で任意コード実行に至る。誤ったRBAC/ServiceAccount設計により、APIサーバへの広範アクセスに横滑りする。
  • ATT&CK: Initial Access（Exploit Public-Facing Application）、Privilege Escalation（Exploitation for Privilege Escalation）、Credential Access（Unsecured Credentials）、Lateral Movement（Valid Accounts/Remote Services）、Impact（Data Manipulation/Service Stop）です。
  • 影響: 機密データの窃取、内部サービスの無許可公開、WAF/レート制御の形骸化、SLA違反です。

• シナリオ2: アノテーション悪用によるポリシーバイパス

  • 仮説: 開発チームにIngress編集権限があり、server-snippet 等でNginxディレクティブを注入。意図せぬリクエストフォージェリやロギングの無効化、社内のみ想定のパス露出が生じる。
  • ATT&CK: Defense Evasion（Modify Configuration）、Command and Control（Web Protocolsの悪用）、Exfiltration（Application Layer経由）です。
  • 影響: 監査証跡の欠落、境界監視の死角化、データ流出リスクの増大です。

• シナリオ3: 引退後のソフトウェア供給網リスク

  • 仮説: プロジェクト凍結後、非公式ミラーや同名イメージのタイポスクワッティングが横行。自動更新や手動pullの誤誘導でマルウェア化したコントローラを展開してしまう。
  • ATT&CK: Initial Access（Supply Chain Compromise）、Defense Evasion（Signed Binary Proxyの悪用含む）、Persistence（新たなコンポーネントの常駐化）です。
  • 影響: インシデント特定の遅延、複数クラスタへの汚染拡大、レピュテーション毀損です。

• シナリオ4: 可用性攻撃と運用過負荷の誘発

  • 仮説: 既知バグやTLSネゴシエーション周りの未修正不具合を突いたDoS、あるいは設定ドリフトによりキャパシティ計画が破綻。SRE/CSIRTの疲弊を狙う持久戦。
  • ATT&CK: Impact（Denial of Service）、Discovery（Service Discovery）、Command and Control（Traffic Flooding/Protocol Abuse）です。
  • 影響: 広範なサービス停止、エスカレーションの乱発、復旧SLO逸脱です。

なお、上記はあくまで仮説であり、各環境の実装・RBAC・ネットワーク分離の度合いにより成立性は変動します。自環境の脅威モデリングで妥当性を検証すべきです。

セキュリティ担当者のアクション

「止血」「橋渡し」「置換」の3フェーズで、時間軸を明確化して動くべきです。

• 0〜48時間（止血）

  • 資産棚卸し: 稼働中のIngressコントローラーを同定し、コミュニティ版 Ingress NGINX（kubernetes/ingress-nginx）か、他実装かを切り分けます。イメージ名、Helmリリース、namespace（例: ingress-nginx）で機械的に棚卸しします。
  • 露出確認: コントローラの外部公開パス、管理UI/メトリクスの露出有無、許容していないポート/TLS設定を確認します。
  • ガードレール強化: Admission（OPA Gatekeeper/Kyverno等）で危険アノテーション（server-snippet等）を暫定ブロックします。RBACを見直し、Ingress編集の権限を最小化します。
  • 可能な限り最新安定版へ更新し、既知CVEの回避と監査ログ（アクセスログ/エラーログ）の保持を強制します。

• 2週間以内（橋渡し）

  • 移行方針の決定:
    • 第一候補として Gateway API 準拠コントローラー（クラウドLB統合型/Envoy系/商用NGINX製品等）を比較評価します。要件はTLS終端、mTLS、WAF/RateLimit、Canary/TrafficSplit、Observability、CRDサポート範囲です。
    • ベンダー選定では、サポートSLA、セキュリティ修正のリードタイム、CVE対応実績、署名/サプライチェーン（SBOM/イメージ署名）を重視します。
  • 二重運用の設計: 旧Ingressと新Gatewayを併設し、ドメイン単位で段階的にルーティングを切替えます。トラフィックミラーリングやHeaderベースのカナリアで段階移行を可能にします。
  • 意味論の移植: アノテーション由来の機能をCRDポリシーへ写像し、代替不能なものは撤廃/設計変更を判断します。ここはセキュリティレビューとセットで進めます。
  • コンフォーマンステスト/回帰試験: 主要パス（認証・認可・リダイレクト・ヘッダ透過・TLS/証明書ローテーション）を自動化テスト化し、再現性を担保します。

• 90日以内（置換）

  • 段階的カットオーバー: SLOクリティカルな系統から順にルートを移行し、旧コントローラー配下のトラフィック比率を定期的に可視化します。
  • ハードニングの標準化: 新コントローラーに対し、Pod Security、ネットワークポリシー（東西/南北）、イメージ署名検証、最小権限RBAC、監査ログの集約・改ざん耐性を標準化します。
  • 廃止と衛生管理: 旧Ingressリソース/CRD/ConfigMap/ClusterRoleを削除し、イメージキャッシュやCI定義、IaCからの参照も除去します。非公式ミラー参照の残骸がないかCIログまで遡って検証します。
  • 監査適合/説明責任: リスク台帳、移行計画、例外申請、残留リスクの受容/回避判断を文書化し、利害関係者と合意します。

• 監視・検知（継続）

  • 検知ユースケース: Ingress/HTTPRouteの急激な変更、危険アノテーションの付与、コントローラPodのexec/イメージ差替え、証明書の不正ローテーション、5xx/429の異常増加をアラート化します。
  • MITREに沿ったプレイブック:
    • Exploit Public-Facing Application（初期侵入）兆候の早期検知と遮断、
    • Exploitation for Privilege Escalation（権限昇格）の監査ログ相関、
    • Valid Accounts/Remote Services（横展開）封じのネットワーク制御、
    • Denial of Service（影響）時の自動スケール/RateLimitのセーフモードなどを整備します。

• KPI/リスク指標

  • 旧Ingress配下のトラフィック比率、移行済みルート数/総数、危険アノテーション検出件数、CVE対応リードタイム、Ingress関連インシデントのMTTD/MTTRをダッシュボード化します。

最後に、名称の紛らわしさは実務を誤らせます。自社が使っているのが「コミュニティ版 Ingress NGINX」なのか、クラウド提供のGateway/ベンダーの別実装なのかを、まず正確に見極めることが第一歩です。エッジの置換は怖い作業ですが、恐る恐る後回しにするより、今日から静かに精度高く進めるほうが、結果的に安全で安く済みます。

参考情報

• Datadog Security Labs: Kubernetes Ingress NGINX retirement warning（利用率や引退警告の背景）https://securitylabs.datadoghq.com/articles/kubernetes-ingress-nginx-retirement-warning/ です。