GKE Gateway'a yerel CORS desteği geldi: cross-origin politikası artık load balancer'da

Ne oldu

dev.to'da yayımlanan bir yazıya göre Google, GKE Gateway ve Inference Gateway için yerel CORS desteğini Önizleme sürümü olarak sunmuş oldu. Bu özellik, Ingress-Nginx'ten Kubernetes Gateway API'sine geçiş yapan ekiplerin en sık dile getirdiği eksikliklerden birini kapatıyor; önceden cross-origin politikasının uygulama kodu içinde yer alması gerekiyordu.

Tarayıcılar varsayılan olarak Same-Origin Policy'i uygular ve script'lerin farklı bir origin'den sunulan yanıtları okumasını engeller. Modern uygulamaların çoğu — single-page app'ler, mobil istemciler, gömülü widget'lar ve giderek artan biçimde yapay zeka çıkarım (inference) endpoint'leri — etki alanları arası iletişim kurmak zorunda olduğundan, bu yolları güvenli biçimde açmak için Cross-Origin Resource Sharing'e güvenir. Ingress-Nginx'te ekipler bunu enable-cors annotation gibi controller annotation'larıyla hallediyordu. Gateway API'de buna karşılık gelen bir yapı yoktu ve bu eksiklik, geçişler sırasında tekrarlanan bir şikayet konusuydu. Yeni sürüm, GKE'nin Gateway ve Inference Gateway uygulamalarına, HTTPRoute manifest'lerinde bildirimsel olarak tanımlanan bir CORS filter'ı ekliyor.

CORS neden edge'de ele alınmalı

dev.to yazısı, CORS'un servis bazında ele alınmasının üç sorununu tespit ediyor. Birincisi, her backend — ister Node.js, FastAPI, Spring olsun ister vLLM gibi bir inference sunucusu — gelen header'ları inceleyip preflight isteklerini yanıtlamak için kendi middleware'ine ihtiyaç duyuyor. İkincisi, preflight OPTIONS çağrıları hiçbir iş yükü taşımalarına rağmen uygulama container'larında bellek, CPU ve bant genişliği tüketiyor. Üçüncüsü, düzinelerce mikroservis kendi politikasını sürdürdüğünde, izin verilen header'lardaki veya origin doğrulamasındaki küçük farklar zamanla birbirinden uzaklaşıyor; bu da hem güvenlik açıkları hem de bozuk istemci entegrasyonları yaratıyor.

Yeni filter ile Google Cloud Load Balancing, OPTIONS isteklerini edge'de sonlandırıyor ve Access-Control-Allow-Origin, Access-Control-Allow-Methods ile Access-Control-Allow-Headers yanıtlarını kendisi ekliyor. Backend'ler yalnızca doğrulanmış istekleri görüyor; bu da koddaki boilerplate'i kaldırıyor ve protokol müzakere yükünü azaltıyor.

Filter nasıl yapılandırılır

CORS, açık kaynak Gateway API spesifikasyonunu izleyerek bir HTTPRoute'un rules bölümünde bir filter olarak yapılandırılıyor. Kullanılabilir ayarlar şunlar:

• allowOrigins: açık URL'ler, bir partner subdomain eşleşmesi gibi wildcard pattern'leri veya her şeyi kapsayan yıldız işareti
• allowMethods: izin verilen HTTP fiilleri veya hepsi için bir wildcard
• allowHeaders: istemcilerin gönderebileceği istek header'ları
• exposeHeaders: tarayıcının script'lere görünür kıldığı yanıt header'ları
• allowCredentials: cookie'lerin ve kimlik doğrulama header'larının isteklere eşlik edip edemeyeceğini belirler
• maxAge: tarayıcının preflight yanıtını kaç saniye önbelleğe alabileceği; varsayılan beş saniye olup tekrarlayan OPTIONS trafiğini ciddi biçimde azaltıyor

Wildcard'larla ilgili güvenlik tuzakları

Yazı, wildcard'ların credentials ile nasıl etkileştiğine dair keskin bir noktaya dikkat çekiyor. Access-Control-Allow-Origin bir yıldız işareti (asterisk) olduğunda tarayıcılar credentials içeren yanıtları reddeder. Ancak GKE Gateway, wildcard origin pattern'lerini isteği yapan origin'i dinamik olarak eşleştirip yansıtarak işlediğinden, tarayıcı açık bir origin görür ve yanıtı kabul eder.

Bu, her şeyi kapsayan bir origin'in allowCredentials etkinleştirilmiş biçimde yapılandırılmasının, rastgele bir web sitesinin kimliği doğrulanmış kullanıcı yanıtlarını okuyabilmesi anlamına gelir. Kimlik doğrulaması yapılan API'ler için önerilen uygulama, geniş wildcard'lar yerine açık domain listeleri tanımlamaktır.

Kullanılabilirlik ve sınırlar

Önizleme, üç GatewayClass kapsamında tek kümelilik GKE Gateway dağıtımlarını kapsıyor: gke-l7-rilb (bölgesel dahili Application Load Balancer), gke-l7-regional-external-managed ve gke-l7-global-external-managed. Inference Gateway dağıtımları da filter'ı kazanıyor; böylece tarayıcı tabanlı sohbet arayüzleri ve istemci SDK'ları, sunulan modellere origin'ler arası doğrudan sorgu gönderebiliyor.

Birtakım kısıtlar geçerli. Çok kümeli gateway'ler olan gke-l7-gmc-* sınıfları henüz CORS filter'ını desteklemiyor. Bir CORS filter, aynı route rule içinde bir RequestRedirect filter ile birleştirilemiyor. Wildcard origin'ler ise alttaki Cloud Load Balancing URL map'lerinde regular-expression kotasını tüketiyor: global harici sınıfta sınır Gateway listener başına bir regex, ayrıca wildcard origin'ler PathPrefix eşleşmeleriyle hiçbir şekilde birleştirilemezken, bölgesel sınıflar hostname başına beş regex'e kadar izin veriyor. Kesin origin'ler ve her şeyi kapsayan girişler bu kotalara dahil edilmiyor.

Neden önemli

CORS, tarihsel olarak orantısız dert yaratmış küçük bir yapılandırma parçasıdır: servislere dağılmış haldedir, yanlış yapılması kolaydır ve debug'lanması pahalıdır. Bunun yönlendirme katmanına taşınması, platform ekiplerinin cross-origin politikasını, TLS ve yönlendirme kurallarını merkezileştirdikleri gibi merkezileştirmesini, backend kodundan protokol boilerplate'ini kaldırmasını ve preflight trafiği için container işlem maliyetleri ödemeyi bırakmasını sağlıyor. Ingress'ten Gateway API'ye geçişin ortasındaki ekipler için bu, eski controller'ı tutmanın son işlevsel nedenlerinden birini ortadan kaldırıyor. Önizleme durumu ve çok kümeli boşluk, üretim dağıtımlarında dikkatli olmayı işaret ediyor; ancak yön net: cross-origin politikası, uygulama kodu olmaktan çıkıp altyapı yapılandırması haline geliyor.