핵심 요약
Kubernetes 가장 인기 있는 인그레스 컨트롤러였던 Ingress-NGINX가 2026년 3월 24일 공식 EOL 처리된 지 한 달. Censys가 4월 25일 발표한 스캔 결과, 인터넷에 노출된 미마이그레이션 인스턴스가 2,400개 이상으로 확인됐다.
- EOL 일자: 2026-03-24 (CNCF SIG Network 결정)
- 기준 시점: 2026-04-25 Censys 인터넷 광역 스캔
- 발견 인스턴스: 2,432개 (인터넷 라우팅 가능 IP 기준)
- 주요 노출 CVE: CVE-2026-24513 (RCE, CVSS 8.8) 등 3종
- 대안: Gateway API (kubernetes-sigs/gateway-api)
왜 EOL이 됐나
Ingress-NGINX의 retire 결정은 단일 사건이 아니다. 2026년 3월 발견된 Ingress-Nginx 치명적 RCE 3종 (CVE-2026-24513 외) 이후, SIG Network와 Security Response Committee가 공동으로 retire를 의결했다.
- 유지보수 자원 부족 — 활성 메인테이너 3명 미만
- 아키텍처상 난점 — annotation 기반 설정의 보안 표면이 너무 넓음
- Gateway API 등장으로 표준 대안 존재
"공식 EOL"의 의미
EOL 이후 다음과 같은 변화가 적용된다.
- 새로운 릴리스 없음 — 마이너 버그픽스조차 안 됨
- 새로 발견된 CVE도 패치 안 됨 — 사용자 자체 책임
- Helm chart 저장소는 유지되지만 frozen
- kubectl·CNCF 도구의 기본 templates에서 제거
현재 노출 현황 — Censys 데이터
| 지역 | 노출 인스턴스 | 비율 |
|---|---|---|
| 미국 | 912 | 37.5% |
| 유럽 | 586 | 24.1% |
| 아시아 (한·일·중·대만) | 478 | 19.7% |
| 인도 | 231 | 9.5% |
| 기타 | 225 | 9.2% |
한국 노출 인스턴스는 약 122개로 추정되며, 이 중 절반은 ML/AI 워크로드를 운영하는 GPU 클러스터로 분류됐다.
마이그레이션 옵션
1) Gateway API (권장)
CNCF 표준이며 Kubernetes 1.36에서 1.4 spec이 GA됐다. Ingress와 달리 L4·L7·multi-protocol을 단일 모델로 다룬다.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: api-gw
spec:
gatewayClassName: nginx
listeners:
- name: https
port: 443
protocol: HTTPS
tls:
certificateRefs:
- name: tls-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: api-route
spec:
parentRefs:
- name: api-gw
rules:
- matches:
- path: { type: PathPrefix, value: /api }
backendRefs:
- name: api-svc
port: 80802) NGINX Gateway Fabric
F5/NGINX 측의 공식 후속 프로젝트. Ingress-NGINX 사용자 마이그레이션 문서가 가장 충실하다.
3) Envoy 기반 대안
- Envoy Gateway — CNCF Incubating, 단순 Ingress 교체 용도로 적합
- Istio Gateway — Service Mesh 도입과 함께 갈 때
- Contour — 가벼운 운영 선호 시
4) 클라우드 매니지드
- AWS: ALB Controller
- GKE: GKE Gateway Controller
- AKS: Application Gateway for Containers
마이그레이션 체크리스트
- 현재 Ingress 리소스 모두 export —
kubectl get ingress -A -o yaml > ingress-backup.yaml - annotation 사용 분석 — 50개 이상 사용 시 Gateway API의 PolicyAttachment로 매핑 검토
- TLS 인증서 관리 방식 점검 (cert-manager 호환 여부)
- ratelimit·auth 같은 NGINX-only 플러그인은 OPA·Pomerium 등으로 분리
- Canary·Blue-Green 라우팅 — Gateway API HTTPRoute weight 사용
대형 사용자 동향
- Spotify: 자체 Gateway API 어댑터 오픈소스화 예정 (5월)
- Shopify: Envoy Gateway 채택, 마이그레이션 80% 완료
- 네이버: NGINX Gateway Fabric으로 단계적 전환 — Q3까지 100% 목표
- 카카오: 자체 사내 어댑터 개발 중, 외부 공개 미정
실무 권고
- EOL 이후 발견된 CVE는 사실상 모두 미패치 — 즉시 대응 필요
- 인터넷 노출 클러스터는 1주 이내 마이그레이션 또는 임시 격리
- annotation 의존도가 높은 환경은 Gateway API 전환 시 정책 재설계 시간 충분히 확보
- 표준화 측면에서 Gateway API 채택이 장기적으로 가장 안전
자주 묻는 질문
EOL 이후에도 계속 써도 되나?
기술적으로는 가능. 그러나 새 CVE에 무방비 노출되며, 일부 컴플라이언스(ISO 27001·SOC2)에서는 사용 불가 판정 가능.
Gateway API와 Ingress 차이의 핵심은?
역할 분리. Ingress는 단일 리소스에 모든 설정. Gateway API는 Gateway(인프라 팀)/HTTPRoute(앱 팀)/Policy(보안 팀)로 분리.
마이그레이션이 가장 어려운 시나리오는?
NGINX-only annotation을 100개 이상 사용하는 환경. 이 경우 Helm chart 절반을 다시 작성해야 한다.
댓글 0