2026年3月、全Kubernetesクラスターの約半数で使われているトラフィックルーティングコントローラー「Ingress NGINX」がKubernetesコミュニティによって正式に廃止されました。今後、バグ修正もセキュリティパッチも提供されません。
この記事では、実際に何がEOL（サポート終了）になったのか、そのままにしておくリスク、すべての移行先の比較、そして自分のペースで移行しながらセキュリティを維持する方法を完全に解説します。
TL;DR（要約）
| 項目 | 内容 |
|---|---|
| EOLになったもの | コミュニティ管理の kubernetes/ingress-nginx コントローラー（2026年3月にアーカイブ化・読み取り専用） |
| EOLでないもの | Kubernetes Ingress API本体・NGINXウェブサーバー・F5/NGINX Inc.が管理する nginxinc/kubernetes-ingress（別プロジェクト） |
| リスク | EOL後に発見された脆弱性はアップストリームで修正されない。SOC 2・PCI DSS・HIPAA・ISO 27001の監査でも指摘対象になる |
| 選択肢 | Gateway API や他コントローラー（Traefik・HAProxy・F5 NGINX・Envoy）への移行、または商用サポートで継続利用しながら計画的に移行 |
「サポート終了」が何を意味するのかを正確に理解する
この移行で最も混乱しやすいのがプロジェクト名の似ている2つのコントローラーの混同です。
-
Ingress NGINX（
kubernetes/ingress-nginx）：Kubernetes SIG Networkが管理するコミュニティ版。2026年3月にEOL。本記事の対象。 -
NGINX Ingress Controller（
nginxinc/kubernetes-ingress）：F5/NGINX Inc.が管理するオープンソース＋商用版。別のコードベースであり、今回の廃止とは無関係。
さらに2点の重要な区別があります。
- Kubernetes Ingress API自体は廃止されていません。 引き続き利用可能ですが、機能追加は凍結されており、今後の開発はGateway APIに移行しています。
- NGINXウェブサーバー自体も無関係です。 廃止はあくまで1つのKubernetesコントローラーの話であり、NGINXエコシステム全体には影響しません。
タイムライン
- 2025年11月11日：Kubernetes SIG NetworkとSecurity Response Committeeが廃止を正式発表
- 2026年1月：Kubernetes Steering CommitteeとSecurity Response Committeeが緊急性を強調する共同声明を発表
- 2026年3月：ベストエフォートメンテナンスが終了（予定通り）
廃止は突然の決定ではなく、長年にわたる構造的な問題の積み重ねによるものです。
- メンテナーの疲弊：実質的に1〜2名のボランティアが、膨大なバグ報告・機能要望の山に対応し続けていた
-
技術的負債：
configuration-snippetアノテーションによる任意のNGINX設定注入は、メンテナンスの負担とセキュリティリスクの両方を生んでいた - 後継プロジェクトの失敗：予定されていた後継コントローラー「InGate」は成熟せず、こちらも廃止に
- IngressNightmare（CVE-2025-1974）の発覚：クラスター全体に影響するRCE脆弱性が発見され、持続可能でない状況が誰の目にも明らかになった
Ingress NGINX をEOL後もそのまま使い続けるリスク
既存のデプロイはメンテナンス終了後もすぐに動かなくなるわけではありません。インストール済みのアーティファクトは残り、クラスターはトラフィックを処理し続けます。リスクはすぐにシステムが壊れることではなく、時間とともに積み重なるリスクの複利です。
セキュリティリスク
これが最大のリスクです。Ingress NGINXはレイヤー7のリクエストパスに位置し、TLSを終端して外部トラフィックをサービスにルーティングします。つまりクラスター内でもっともセキュリティ上重要なコンポーネントの一つです。EOL後は、新たに発見された脆弱性に対するアップストリームの修正は一切提供されません。
これは仮定の話ではありません。2026年5月には廃止済みのIngress NGINXビルドに影響するヒープバッファオーバーフロー（NGINX Rift）が公開されました。
コンプライアンスリスク
規制要件のある組織にとっては、セキュリティより先にコンプライアンスの問題が来ることもあります。リクエストパス上にEOLソフトウェアが存在すると、以下の規格の監査で指摘を受けます。
- SOC 2
- PCI DSS
- HIPAA
- ISO 27001
特定のCVEが悪用される前から、本番環境への昇格がブロックされたり、顧客のセキュリティレビューが遅延したりする可能性があります。
運用上のドリフト（環境のズレ）
セキュリティ問題を抜きにしても、更新が止まったコントローラーは進化し続けるエコシステムの中で徐々に「ズレ」ていきます。Kubernetesの新しいマイナーバージョンへのアップグレードで互換性問題が発生したり、cert-manager や external-dns などの周辺ツールがサポート済みコントローラーを中心に進化し続けることで、次のクラスターアップグレード時に予期せぬ障害が発生するリスクがあります。
移行先の選択肢を正直に比較する
「ドロップイン」とは、既存のIngressリソースをアノテーションの書き換えなしにそのまま使い続けられることを指します。
| 移行先 | ドロップイン | 移行コスト | 向いているケース | 注意点 |
|---|---|---|---|---|
| Gateway API（Envoy Gateway / Istio / NGINX Gateway Fabric / Cilium / kgateway） | ✗ | 高 | 長期的にトラフィック管理を刷新したいチーム | 新しいリソースモデル（GatewayClass・Gateway・HTTPRoute）への全面移行が必要 |
| Traefik | 部分的 | 中 | スムーズなコントローラー乗り換えを求めるチーム | Ingress-NGINXプロバイダーで多くのアノテーションを変換できるが、すべてをカバーしているわけではない |
| HAProxy Kubernetes Ingress | 部分的 | 中 | パフォーマンス重視のワークロード | 設定モデルが異なるため、再設定とテストが必要 |
| F5 / NGINX Ingress Controller | 部分的 | 中 | NGINXエコシステムに留まりたい組織 | 別プロジェクトであり、独自のアノテーション・CRD（VirtualServer等）・ConfigMapモデルを持つ |
| Envoy Gateway | ✗ | 高 | EnvoyやService Meshに標準化するチーム | Gateway APIのみ対応。ルーティング設定の全面移行が必要 |
| NES for Ingress NGINX（HeroDevs） | ✓ | 最小 | 安全な移行が完了する前にリスクウィンドウが開いてしまうチーム | 商用サブスクリプションが必要。移行の代替ではなく、「安全に移行するための時間を買う」サービス |
Gateway API：長期的な移行先
Gateway APIはKubernetesプロジェクトが指定したIngressの後継であり、戦略的に最もクリーンな移行先です。コントローラー固有のアノテーション乱立を、ポータブルでロールを意識したリソースモデル（GatewayClass・Gateway・HTTPRoute）に置き換えます。公式の ingress2gateway ツールで既存設定の多くを自動変換できます。
ただし、Gateway APIへの移行は「コントローラーの入れ替え」ではなく「真の移行作業」です。 アノテーションで表現されていたすべての挙動を再設定・検証し、段階的なトラフィックカットオーバーが必要です。シンプルなIngressリソースが少数なら現実的ですが、数百のリソースに何年分ものアノテーションが蓄積されている場合は、計画・テスト・変更ウィンドウを要する本格的なプロジェクトです。
ドロップイン代替コントローラー
Gateway APIへの全面移行がタイムライン的に困難な場合、別のアクティブメンテナンス済みIngressコントローラーに乗り換えることで時間を稼ぐことができます。
- Traefik：既存アノテーションを変換するIngress-NGINXプロバイダーがあり、最もスムーズな乗り換えがしやすいと評されています。Gateway APIへの移行パスも用意されています。
- HAProxy：生のパフォーマンスが重要なケースに強い選択肢です。
- F5 NGINX Ingress Controller：サポートや調達上の理由でNGINXエコシステムに留まる必要がある組織に最適です。
共通の注意点：いずれも真のドロップイン代替ではありません。 独自の設定モデルを持つため、マニフェストを単純に差し替えるのではなく、再設定とテストを行うことを前提にしてください。
商用サポートでIngress NGINXを継続利用する
多くの場合、問題は「どこに移行するか」ではなく「いつ移行できるか」です。セキュリティ・コンプライアンスの締め切りが、安全な移行が現実的に完了する前に到来してしまうケースがあります。
NES for Ingress NGINX（HeroDevs） はその「ギャップ」のために存在します。
- EOLになったIngress NGINXコントローラーバージョンの商用サポート付きドロップイン代替
- OCI ImageとHelmチャートとして提供。GitOps・ArgoCD・Fluxワークフローとそのまま統合可能
- 新たなCVEが発見された場合、HeroDevsが検証・パッチを適用し新リリースを提供
- 既存のIngressリソース・アノテーション・ルーティング設定はそのまま維持
ポイントは「セキュリティの締め切り」と「移行プロジェクト」を切り離すことです。 今すぐコンプライアンスを維持しながら、チームに十分なキャパシティができたタイミングで計画的にGateway APIや他のコントローラーに移行できます。
EOL後のIngress NGINXに影響するCVE一覧
EOL後も、廃止済みIngress NGINXビルドに影響する脆弱性は新たに発見され続けています。
| 深刻度 | CVE番号 | 概要 |
|---|---|---|
| Critical | CVE-2026-42945 | ヒープバッファオーバーフロー（NGINX Rift） |
| High | CVE-2026-40890 | DoS（依存関係） |
| High | CVE-2026-35205 | 暗号署名の不正検証（依存関係） |
| High | CVE-2026-35204 | パストラバーサル（依存関係） |
| Medium | CVE-2026-32282 | ファイルアクセス前の不正リンク解決（依存関係） |
| Medium | CVE-2024-44337 | DoS（依存関係） |
| Critical | CVE-2025-1974 | IngressNightmare（クラスター全体でRCE） |
どの選択肢を選ぶべきか：判断フロー
-
Ingressリソースが少なく、シンプルで、今すぐエンジニアリングキャパシティがある
→ Gateway APIに移行する（戦略的に正しいゴール） -
EOLコントローラーから早急に脱却したいが、API全面移行にはまだコミットできない
→ Traefikなどのアクティブメンテナンス済みコントローラーに乗り換え、その後Gateway APIへ -
セキュリティ・コンプライアンスの締め切りが移行完了より先に来る
（リソース数が多い・アノテーションが複雑・変更ウィンドウが制限されている・監査プレッシャーがある）
→ NES for Ingress NGINXで今すぐパッチを適用しながら、移行を別プロジェクトとしてスケジューリング
「何もしない」は選択肢として成り立ちません。 既存クラスターはそのまま動き続けますが、メンテナンスされていないコントローラーをリクエストパスに置き続ける毎週が、セキュリティ・コンプライアンス両面のリスクを複利で積み増し続けます。
アクションプラン
- インベントリの取得：クラスター全体でIngress NGINXが動いている箇所、バージョン、使用中のアノテーションを一覧化する
- スケール・タイムライン・コンプライアンス要件に合った移行パスを選択する
- セキュリティ・コンプライアンスのギャップを今すぐ埋める必要がある場合はNES for Ingress NGINXを検討する（SLAバックのCVEパッチ、HelmチャートとOCI Imageとして提供、監査対応のためのVEXステートメント・SBOM付き）
元記事：HeroDevs Blog - Ingress NGINX End of Life (March 2026): Risks, Migration Paths, and Support Options