ingress-nginx yamaları durdu ve Envoy Gateway geçişi bir YAML çevirisinden fazlası

Sürekli çalışan bir controller

dev.to'daki bir yazıya göre ingress-nginx, Mart 2026'dan bu yana bir güvenlik yaması almadı. Controller trafiği her zaman yaptığı gibi yönlendirmeye devam ediyor ve yazarın vurguladığı nokta, bu sürekliliğin tam da riskin fark edilmemesinin nedeni olduğu: hiçbir şey bozulmuyor, dolayısıyla hiçbir şey planlanmıyor.

Yazı, çıkışı Kubernetes'in kendisinin önerdiği yol olarak çerçeveliyor. Kubernetes blogundaki Ingress NGINX emeklilik duyurusunu (11 Kasım 2025 tarihli) kaynak gösteriyor ve halefi olarak Gateway API'yi, onun uygulamalarından biri olarak da Envoy Gateway'i işaret ediyor.

Geçiş bir çeviri çalışması değil

Yazara göre baştaki düşünce, bu geçişi sözdizimi dönüşümü olarak görmek: ingress-nginx annotation'larının her birini alıp yeni biçimde yeniden yazmak. Yazı, bu yaklaşımı tehlikeli kılan iki yapısal değişiklik olduğunu savunuyor.

Birincisi sahiplik. nginx'de her uygulama, kendi IP erişim kuralını uygulamanın ekibi tarafından korun bir annotation içinde taşıyordu. Envoy Gateway'de bu kural, rotalar arasında paylaşılan bir Gateway'e eklenen bir SecurityPolicy'e yükseltiliyor. Kural uygulama ekibinden platform ekibine geçiyor ve etki alanı buna göre büyüyor: eskiden tek bir uygulamayı etkileyen bir hata artık o Gateway'in ardındaki tüm rotaları etkiliyor.

İkincisi, kuralın çalıştığı katman. Bir IP allowlist'i, layer 7'de alınan bir layer-3 kararıdır; yani proxy, istemciye ait olduğuna inandığı IP üzerinde hareket eder. Yazıda adı geçen iki hata modu bunun sonucudur. Yol üzerinde herhangi bir noktada SNAT olursa, tüm çağıranlar node'un IP'sine dönüşebilir. X-Forwarded-For doğrulama olmadan kabul edilirse, herhangi bir istemci istediği bir adresi basitçe beyan edebilir.

Belgelerin doğruladığı dört tuzak

Yazar, saf bir annotation'dan-YAML'a dönüşümün yanlış yapacağı, her biri resmi belgelerle desteklenen dört tuzak listeliyor:

• SNAT'ın, istekler proxy'ye ulaşmadan önce istemci adreslerini yeniden yazması.

• Yerine geçme yoluyla öncelik: Envoy Gateway'in SecurityPolicy belgeleri önceliği ve mergeType ayarını ele alıyor; yazar, policy'lerin birbirleriyle birleşmek yerine birbirlerinin yerini alabileceği konusunda uyarıyor.

• Eski kurallardan kopyalanan geniş bir CIDR'nin erişimi, özgün kuralın amaçladığından daha fazla açması.

• API gateway'in, backend servislerin gördüğü tek istemci olarak kalması.

Bu işi yapan ekipler için yazı, somut kaynaklara işaret ediyor: Envoy Gateway'in IP'ye göre erişimi kısıtlama rehberi, X-Forwarded-For ve Proxy Protocol'ü kapsayan Client Traffic Policy belgeleri, öncelik ve mergeType hakkındaki SecurityPolicy materyali; bunların yanı sıra istemci kaynak IP'sini koruma üzerine Kubernetes belgeleri ve AKS'teki Standard Load Balancer üzerine Microsoft belgeleri.

Neden önemli

Güvenlik yaması almayan internete açık bir ingress controller, ayakta duran bir risktir ve geçiş ne kadar ertelenirse hızlı çözüm o kadar cazip hale gelir. dev.to yazısının pratik uyarısı şudur: annotation'ları tek tek yeniden yazmak şeklindeki hızlı çözüm, tam da erişim kurallarının sessizce kaybolduğu ya da sessizce genişlediği yerdir.

Yazarın tarif ettiği değişiklikler, inceleme süreçlerinin genellikle gözünden kaçanlardır; çünkü hiçbiri hata gibi görünmez: bir uygulamanın manifest'inden platforma ait bir policy'ye taşınan kural, layer 3'ten layer 7'ye kayan karar, anlamı istemci adreslerinin proxy'ye nasıl ulaştığına bağlı olan bir allowlist. ingress-nginx'ten uzaklaşan ekipler dönüşüm değil doğrulama için planlama yapmalı: istemci IP'lerinin proxy'ye nasıl ulaştığını teyit etmeli, geçiş sonrası her rotanın etkin allowlist'ini kontrol etmeli ve policy önceliğini bir biçimlendirme detayı değil bir inceleme maddesi olarak ele almalı.

Yazar, tek başına bir kontrol listesi işlevi gören bir soruyla bitiriyor: sadece araç değişimi gibi görünen bir geçişte hangi erişim kuralı kayboldu ya da fazlasıyla açıldı?