SSO kullanıcıyı platformun giriş noktasında doğrular. Fakat federasyonlu bir yapıda süreç burada bitmez. Platform, Kubernetes kullanıcı kimliğini iş yüklarının çalıştığı ortamlara güvenli biçimde taşır.

Ekipler ham erişim token’larını her uygulamaya dağıtmak istemez. Ayrıca her cluster için ayrı Identity Provider entegrasyonu kurmak yönetimi zorlaştırır. Platform büyüdükçe logout, token yenileme ve yetki kontrolü de daha karmaşık hale gelir.

“

Notebook bir cluster’da çalışır, katalog API’si başka bir cluster’da yer alır. AI asistanı ise üçüncü bir ortamda sorgu motoruna erişir. Buna rağmen tüm bileşenlerin aynı soruyu yanıtlaması gerekir: Bu kullanıcı kim ve burada ne yapmaya yetkili?

SSO nerede biter, veri düzlemi kimliği nerede başlar?

SSO kullanıcıya tek bir giriş noktası sağlar. Ancak bu giriş, kontrol düzlemindeki kimliği otomatik olarak veri düzlemine taşımaz. Platform kullanıcı bağlamını çalışma ortamlarına kontrollü biçimde aktarır.

Ortak bir kimlik taşıma modeli yoksa farklı sorunlar ortaya çıkar. Her gateway claim yapılarını farklı yorumlar. Her servis kendi token mantığını geliştirir. Ayrıca logout ve iptal işlemleri bütün cluster’lara aynı anda ulaşmaz.

• Bir gateway’in oluşturduğu oturumu başka bir gateway tanımayabilir. Bu nedenle kullanıcı servisler arasında geçerken tekrar giriş yapar.
• Bir uygulamadaki logout işlemi yalnızca yerel session’ı kapatır. Diğer servislerdeki oturumlar açık kalır.
• Her gateway kendi refresh sürecini yürütür. Böylece Identity Provider daha fazla istek alır.
• Downstream servisler token ve claim yapılarını farklı yorumlar. Sonuç olarak ekipler aynı kimlik mantığını birçok uygulamada tekrar yazar.
• Platform ekibi yeni bir servis eklediğinde authentication entegrasyonunu tekrar kurar.

Kullanıcı bu sorunu çoğunlukla tekrar eden login ekranlarıyla fark eder. Platform ekibi açısından asıl sorun daha büyüktür. Kimlik durumu gereksiz şekilde birçok bileşene dağılır.

Dağıtık ve merkezi session modeli arasındaki fark

Federasyonlu platformlarda iki temel session modeli öne çıkar. Dağıtık modelde her gateway kendi login, session, token refresh ve logout sürecini yönetir. Merkezi modelde ise Identity Gateway bu görevlerin merkezinde yer alır.

• Dağıtık modelde kullanıcı her araç veya gateway için yeniden login yapar.
• Merkezi modelde kullanıcı platform genelinde tek bir session kullanır.
• Dağıtık modelde her gateway token refresh işlemini kendi başına yürütür.
• Merkezi modelde Identity Gateway refresh sürecini tek noktadan koordine eder.
• Dağıtık modelde logout yalnızca ilgili servis veya cluster’ı etkiler.
• Merkezi modelde Identity Gateway tek session kaydı üzerinden platform genelindeki logout sürecini yönetir.

Merkezi session modeli her uygulama için gerekli değildir. Ancak kullanıcı aynı iş akışında birçok araç, cluster veya bölge arasında geçiş yaptığında bu yaklaşım daha fazla değer sağlar.

Kubernetes kullanıcı kimliği için merkezi Identity Gateway modeli

Merkezi Identity Gateway modeli session sahipliği ile request enforcement görevlerini birbirinden ayırır. Merkezi servis platform session’ını yönetir. Bölgesel gateway’ler kendi cluster’larındaki servisleri korur ve yerel erişim politikalarını uygular.

Merkezi Identity Gateway üç temel görev üstlenir. İlk olarak OIDC authorization code akışıyla platform session’ını oluşturur. Ardından gateway’lerin kullanıcı kimliği sorgularını yanıtlar. Son olarak token refresh ve logout süreçlerini platform genelinde koordine eder.

Bölgesel gateway’ler sistemde kalır. Ancak session durumunu kendi içlerinde tutmazlar. Bunun yerine kullanıcı kimliğini merkezi servis üzerinden doğrularlar.

İlk login nasıl çalışır?

Kullanıcı geçerli bir platform session’ı olmadan sisteme geldiğinde bölgesel gateway tarayıcıyı merkezi Identity Gateway’e yönlendirir. Merkezi servis daha sonra kurumsal Identity Provider ile OIDC authorization code akışını yürütür.

Merkezi servis authorization code’u sunucu tarafında işler. Ardından platform session’ını oluşturur. Session bilgisini Redis gibi paylaşılan bir store içinde tutar. Sistem ayrıca session için açık bir TTL değeri tanımlar.

Tarayıcı tarafında platform güvenli ve HTTP-only bir session cookie kullanır. Böylece tarayıcı raw access token yerine platform session kimliğini taşır.

Her istekte kullanıcı kimliği nasıl doğrulanır?

İlk login işleminden sonra merkezi gateway ana uygulama trafiğine girmez. Bölgesel gateway isteği yerel uygulamaya göndermeden önce merkezi servise hafif bir doğrulama çağrısı yapar.

NVIDIA örneğinde bu görev için /gateway/userinfo gibi minimal bir endpoint kullanır. Bölgesel gateway session cookie bilgisini bu endpoint’e gönderir.

Merkezi servis session store içinde ilgili kaydı bulur. Ardından kullanıcı ID’si, e-posta adresi, grup bilgileri, roller ve gerekli session metadata’sını döndürür.

Bölgesel gateway bu bilgileri standart identity header’larına dönüştürür. Daha sonra isteği uygulamaya iletir.

Bu yaklaşım downstream uygulamaların işini önemli ölçüde sadeleştirir. Uygulamalar access token ayrıştırmaz. Refresh token yönetmez. Identity Provider ile doğrudan entegrasyon da kurmaz. Bunun yerine gateway katmanından gelen güvenilir kimlik bilgisini kullanır.

Merkezi Identity Gateway logout ve token yenilemeyi yönetir

Access token süresi sona yaklaşırken merkezi Identity Gateway refresh token üzerinden yeni token alır. Ardından güncel session bilgisini paylaşılan store’a yazar.

Bütün bölgesel gateway’ler aynı session kaynağını kullanır. Bu nedenle her gateway güncel oturum durumunu aynı şekilde görür. Böylece farklı cluster’larda birbirinden kopuk token durumları oluşmaz.

Logout sırasında merkezi Identity Gateway session kaydını siler. Kullanıcının sonraki isteğinde bölgesel gateway geçerli session bulamaz. Gateway erişimi reddeder veya kullanıcıyı yeniden login akışına yönlendirir.

Bu yapı logout işlemini yerel bir servis davranışı olmaktan çıkarır. Sonuç olarak tek bir logout işlemi platform genelindeki oturum durumunu etkiler.

Identity Provider üzerindeki yük neden azalır?

Merkezi session modeli upstream Identity Provider üzerindeki yükü azaltır. Bu avantaj özellikle platform büyüdükçe daha görünür hale gelir.

Dağıtık modelde her bölgesel gateway Identity Provider, token secret store ve authorization policy engine ile ayrı ayrı iletişim kurar. Kullanıcı üç farklı araca geçtiğinde sistem üç farklı token exchange ve refresh süreci çalıştırır.

Merkezi modelde Identity Provider esas olarak login sırasında devreye girer. Bölgesel gateway’ler sonraki isteklerde paylaşılan session bilgisini kontrol eder. Böylece her araç geçişinde yeni bir OIDC akışı başlamaz.

Sonuç olarak platform büyüdüğünde identity altyapısındaki yük kullanıcı–araç–cluster kombinasyonlarına göre artmaz. Yük daha çok aktif kullanıcı sayısına bağlı kalır.

Kubernetes kullanıcı kimliği güvenliği için temel kurallar

Merkezi Identity Gateway kritik bir platform bileşenidir. Bu nedenle ekip güvenlik sınırlarını, hata senaryolarını ve audit gereksinimlerini tasarımın başında ele alır.

• Bölgesel gateway’ler merkezi Identity Gateway ile güvenli bir servis kimliği üzerinden iletişim kurar. Ekip bunun için mTLS, workload identity veya imzalı servis token’ları kullanır.
• Gateway istemciden gelen identity header’larını doğrudan güvenilir kabul etmez. Önce mevcut header’ları temizler. Ardından doğruladığı bilgileri kendisi ekler.
• Session store yalnızca platformun gerçekten ihtiyaç duyduğu bilgileri tutar.
• Platform kısa access token süreleri kullanır. Ayrıca session için açık TTL değerleri tanımlar.
• Ekip refresh token’larını korur ve session store iletişimini şifreler.
• Platform session store ve Identity Gateway için uygun erişim kontrolleri uygular.

Identity Gateway çalışmazsa ne olur?

Merkezi yapı yönetimi kolaylaştırır. Ancak merkezi servis kritik bir rol üstlenir. Bu nedenle ekip hata davranışını tasarım aşamasında tanımlar.

Bazı platformlar Identity Gateway veya session store hizmet vermediğinde bütün istekleri reddeder. Mimari ekipleri bu yaklaşımı fail-closed modeli olarak adlandırır.

Diğer platformlar kısa süreli doğrulama cache’i kullanır. Böylece geçici bir servis kesintisi sırasında kullanıcı mevcut doğrulama bilgisinden yararlanır.

Platform ekibi seçimi kendi risk modeline göre yapar. Burada önemli olan nokta nettir: ekip bu davranışı açık bir mimari kararla tanımlar.

Merkezi kimlik modeli audit takibini kolaylaştırır

Merkezi session modeli validation, refresh ve logout olaylarını ortak bir noktada toplar. Böylece platform ekibi daha güvenilir bir audit trail oluşturur.

Ekip hangi kullanıcının hangi servise ne zaman eriştiğini takip eder. Ayrıca session durumundaki değişiklikleri ve logout işlemlerini merkezi noktadan izler.

AI asistanları için neden daha önemli?

AI asistanları kullanıcı adına veri sorgular, metadata getirir ve farklı backend araçlarını çağırır. Bu nedenle platform, asistanın hangi kullanıcı adına işlem yaptığını bilmelidir.

Merkezi session doğrulaması burada önemli bir avantaj sağlar. AI asistanı kullanıcı kimliğini mevcut platform session’ından çözer. Ardından güvenilir kullanıcı bağlamını backend servislere aktarır.

Bu yaklaşım geniş yetkili ortak servis hesaplarına olan ihtiyacı azaltır. Ayrıca ekip her araç için ayrı login akışı kurmaz.

Asistan kullanıcının RBAC kapsamını devralır. Böylece platform hangi işlemi hangi kullanıcının yetkisiyle gerçekleştirdiğini daha kolay takip eder.

NVIDIA bu yaklaşımda ne sonuç elde etti?

NVIDIA bu modeli AWS ve OCI üzerindeki Kubernetes cluster’larını kapsayan dahili geliştirici platformlarında kullandı. Şirketin paylaştığı sonuca göre yaklaşım tekrar eden login olaylarını yüzde 55 azalttı.

Aynı mimari birleşik platform arayüzleri için de ortak bir temel oluşturdu. Ayrıca tutarlı logout davranışını destekledi ve kullanıcı kimliğiyle çalışan AI asistanlarının işini kolaylaştırdı.

Ekip bu mimariye nasıl geçer?

Ekip mevcut Kubernetes altyapısını tek seferde değiştirmez. Bunun yerine geçişi aşamalı biçimde yürütür.

1. Ekip önce mevcut session’ların hangi servislerde oluştuğunu belirler.
2. Ardından OIDC akışı çalıştıran gateway’leri listeler.
3. Doğrudan token ayrıştıran uygulamaları tespit eder.
4. Downstream uygulamaların hangi identity header’larına güvendiğini belirler.
5. Mevcut logout davranışını analiz eder.
6. Daha sonra /gateway/userinfo endpoint’inin hangi claim’leri döndüreceğini tanımlar.
7. Ekip hangi gateway katmanının identity header ekleyeceğine karar verir.
8. Session TTL, refresh ve audit kurallarını belirler.
9. İlk aşamada tek bir bölgesel gateway’i merkezi doğrulama modeline taşır.
10. Ekip mimariyi test eder. Ardından diğer gateway ve araçları aşamalı biçimde aynı modele geçirir.

Buradaki amaç bütün bölgesel gateway’leri kaldırmak değildir. Asıl amaç her enforcement noktasının aynı session kaynağını kullanmasını sağlamaktır.

Sonuç

Federasyonlu Kubernetes ve AI platformlarında asıl problem yalnızca kullanıcının giriş yapması değildir. Platform aynı kullanıcı kimliğini farklı cluster, araç ve execution plane’ler arasında güvenilir biçimde taşır.Dağıtık session yapısı ilk aşamada basit görünür. Ancak platform büyüdükçe tekrar eden login akışları ortaya çıkar. Tutarsız logout davranışı ve farklı authentication mantıkları da yönetimi zorlaştırır.

Merkezi Identity Gateway modeli session sahipliği ile erişim uygulamasını birbirinden ayırır. Merkezi servis login, validation, refresh ve logout süreçlerini yönetir. Bölgesel gateway’ler ise kendi cluster’larında erişim politikalarını uygular.Böylece platform kullanıcıya tek bir oturum deneyimi sunar. Aynı zamanda Identity Provider üzerindeki yükü azaltır. Audit süreçlerini sadeleştirir ve AI asistanlarının kullanıcı kimliğiyle daha güvenli çalışmasına yardımcı olur.

NVIDIA’nın paylaştığı sonuçlar bu yaklaşımın pratik faydasını da gösteriyor. Şirket, dahili platformlarında tekrar eden login olaylarında yüzde 55 azalma bildirdi.

Bu mimariyi değerlendirirken şu soruyla başlayın: Platform bugün session durumunu nerede tutuyor? Ayrıca hangi servisler aslında kendi başına vermemesi gereken kimlik kararlarını veriyor?