ingress-nginx emekliye ayrılırken eğitim yazısı OAuth2 Proxy kimlik doğrulamasını Gateway API ve Traefik üzerinde yeniden kuruyor

Kılavuzun kapsadığı konular

dev.to üzerinde yayımlanan bir eğitim yazısı, dahili Kubernetes servisleri için tarayıcı tabanlı bir kimlik doğrulama yığınını yeniden kuruyor ve ingress-nginx annotation'larından Kubernetes Gateway API'sine taşıyor. Yazar, ingress-nginx'in emekliye ayrıldığını ve yeni trafik yönetimi çalışmalarının Gateway API üzerinde olması gerektiğini, bu yüzden ingress-nginx çevresinde kurulmuş aynı kılavuzun önceki sürümünün yeniden yazılması gerektiğini belirtiyor.

Ortaya çıkan kurulum, tek bir wildcard alan adı altında üç HTTPS hostname'ini ortaya çıkarıyor: Pocket ID kimlik sağlayıcı arayüzü, OAuth2 Proxy endpoint'leri ve korunmuş bir demo servisi. Her şeyin tek bir üst alan adı altında tutulması, OAuth2 Proxy'nin dar kapsamlı bir paylaşılan oturum cookie'si yayınlamasını sağlıyor; yazar ayrıca, ilgisiz uygulamalar üst alan adını paylaşıyorsa bu cookie alan adının genişletilmemesi konusunda uyarıyor.

Gateway API'nin bıraktığı boşluk

Gateway API, Gateway ve HTTPRoute yönlendirme kaynaklarını standartlaştırıyor; ancak kılavuzun da işaret ettiği gibi, tarayıcı tabanlı OIDC oturum açmayı veya harici bir kimlik doğrulama denetimini standartlaştırmıyor. Yazar bu boşluğu Traefik'in Middleware özel kaynaklarıyla dolduruyor. Bunun sonucu şöyle: Envoy Gateway, Kong, Cilium veya başka bir implementasyonla, standart Gateway ve HTTPRoute nesneleri değişmeden taşınabilir; ancak kimlik doğrulama adaptörünün o implementasyonun karşılığıyla değiştirilmesi gerekir.

Davranışsal fark da önemli. Yeni akışta Traefik, OAuth2 Proxy'nin /oauth2/auth endpoint'ine danışıyor; bu endpoint, oturum geçerliyken 202, değilse 401 yanıtı veriyor; Traefik'in Errors middleware'i ise bu 401'i tarayıcıyı oturum açma sayfasına yönlendirmeye dönüştürüyor. Yazar, bu ayrı yönlendirme adımını, eski annotation tabanlı yaklaşımdan en önemli fark olarak nitelendiriyor.

CRD'lerden çalışan bir gateway'e

Kılavuz yerel bir K3s kümesinde doğrulanmış olsa da, standart kubectl ve Helm komutlarına dayanıyor. Gateway API, kümenin yerleşik bir parçası değil bir eklenti olarak geldiği için ilk adım, standart kanaldaki CRD'leri — Gateway, GatewayClass ve HTTPRoute — kurmaktır; yazar bunları, herhangi bir implementasyon kurmadan önce v1.6.1 sürümünden uygular.

Ardından Traefik, Kubernetes Gateway sağlayıcısı etkinleştirilmiş ve Service'i LoadBalancer tipine ayarlanmış Helm chart'ı ile kurulur. Kılavuz, sorumlulukların ayrımı konusunda açık olur: Gateway kaynağı yalnızca yönlendirme yapılandırmasıdır ve trafiği asıl kabul eden Traefik'in Service'idir. Yönetilen kümelerde bu bir bulut yük dengeleyici anlamına gelir; bare metalde yazar MetalLB'ye veya mevcut harici bir yük dengeleyiciye işaret eder.

TLS, çalışan bir ClusterIssuer'ın halihazırda var olduğu varsayılan cert-manager tarafından yönetilir. Bir wildcard sertifika, 443 portunda TLS'i sonlandıran bir HTTPS listener'ına bağlanır; okuyucular, Certificate Ready=True bildirene ve Gateway Programmed=True bildirene kadar devam etmemeleri konusunda uyarılır.

OIDC sağlayıcı ve istemci kurulumu

Kimlik için kılavuz Pocket ID'yi kullanır; passkey'ler küçük bir kişisel veya ekip dağıtımını basit tuttuğu için seçilmiştir; yazar, başka herhangi bir OIDC sağlayıcının da işe yarayacağını ve yalnızca OAuth2 Proxy'nin sağlayıcı ayarlarının değişeceğini belirtir. Pocket ID, anza-labs Helm chart'ından kurulur ve bir Ingress yerine düz bir HTTPRoute üzerinden ortaya çıkarılır.

İlk kurulumdan sonra yazar, passkey'e ve doğrulanmış bir e-posta adresine sahip bir kullanıcı, bir developers grubu ve yönlendirme URL'si OAuth2 Proxy callback'ine işaret eden bir OIDC istemcisi oluşturur. İki gereksinim özellikle vurgulanır: Pocket ID groups claim'ini göndermelidir, çünkü OAuth2 Proxy yalnızca developers grubunun üyelerini kabul eder; ayrıca e-postanın doğrulanmış olması gerekir, aksi halde OAuth2 Proxy Pocket ID'nin ID token'ını reddeder. Yayımlanan metin, yazar istemci kimlik bilgilerini içeren bir Kubernetes Secret ile OAuth2 Proxy kurulumuna başladığı sırada sona erer.

Neden önemli

ingress-nginx'in emekliye ayrılması, ona dayanan her annotation tabanlı kurulumu bir geçiş projesine dönüştürüyor; kimlik doğrulama ise controller'a özgü davranışlara dayandığı için en zor durumlardan biri. Bu kılavuz böyle bir geçişin şeklini çiziyor: yönlendirme taşınabilir, standartlaştırılmış Gateway ve HTTPRoute nesnelerine taşınırken, standardın kapsamadığı her şey — burada OIDC oturum açma yönlendirmesi — implementasyona özgü kalır ve her controller için yeniden çözülmesi gerekir. Geçiş planlayan ekipler buna göre bütçe yapabilir: route'lar taşınır, middleware yapıştırıcısı taşınmaz. Kılavuz ayrıca Gateway API'nin varsayılan olarak kurulu olmadığı ve DNS, sertifikalar ile yük dengeleyici erişiminin hangi implementasyonu seçerseniz seçin ön koşul olmaya devam ettiği konusunda faydalı bir hatırlatma.