Modern AI- és adatplatformok több, egymással együttműködő eszközből és klaszterből állnak: egy felhasználó belép egy központi portálra, megnyit egy szabályozott adatcsoportot, elindít egy notebookot, majd meghív egy asszisztenst, amely másik klaszter szolgáltatásait használja. A felhasználói élmény egységesnek tűnik, de az identitás a control‑plane és a data‑plane határain átívelve mozog — és itt válik a hagyományos single sign‑on (SSO) elégtelenné.
SSO igazolja a felhasználót a beléptetésnél, de a platformcsapatoknak megbízható módra van szükségük ahhoz, hogy ezt a felhasználói kontextust biztonságosan átadják a szétosztott végrehajtási környezeteknek. Nem cél a nyers tokenek szétszórása minden alkalmazásnak (ami növeli a kockázatot és gyengíti a visszavonást), illetve az sem, hogy minden klaszter külön implementálja az identitás‑provider logikát.
Különösen az AI- és adatplatformoknál fontos ez a kérdés: adatok és számítás gyakran ott maradnak, ahol keletkeznek vagy ahol szabályozva vannak — regionális klaszterekben, külön felhőfiókokban, on‑premise környezetekben vagy specializált execution plane‑eken. A felhasználók viszont egységes platformélményt várnak notebookok, katalógusok, lekérdező eszközök, dashboardok és asszisztensek között.
A központi identitáskapu mint megoldás
A központi identitáskapu mintája úgy működik, hogy egyetlen szolgáltatás birtokolja a platform‑szintű munkamenetet. A data‑plane (regionális) gatewayek nem folytatják le maguk a teljes OIDC‑folyamatot minden kérésnél: ehelyett egy megosztott API‑n (például /gateway/userinfo) keresztül validálják a központi munkamenetet, és a visszaadott, megbízható identitásadatok alapján injektálnak helyi, standardizált azonosító fejléceket a backend kérésekbe.
Az architektúra fő elemei:
- Központi session‑tulajdonos, amely kezeli az OIDC autorizációs kód folyamatát, session létrehozást, refresh‑t és logoutot
- Megosztott session‑tároló (például Redis) opaque session‑ID‑vel és HTTP‑only cookie‑val a platform domain alatt
- Stateless regionális gatewayek, amelyek a /gateway/userinfo hívással kérdeznek rá a sessionre és ez alapján végrehajtanak helyi engedélyezést
- Egy kis, jól definiált identity‑validation API, amelyet a szolgáltatások megbíznak
Ezzel a modellel az alkalmazásoknak nem kell közvetlenül tokeneket feldolgozniuk vagy közvetlen OIDC‑flow‑t futtatniuk: a validáció egy gyors session‑lekérdezés, nem minden kérésnél egy teljes OIDC csere.
Működés — három alapfolyamat
Bejelentkezés
Ha a böngészőben nincs érvényes platform munkamenet, a regionális gateway átirányítja a felhasználót a központi identitáskapuhoz. A központi gateway végrehajtja az OIDC autorizációs kód cserét a szervezet identitás‑providerével, a sessiont a megosztott tárolóba menti TTL‑lel, és beállít egy HTTP‑only cookie‑t, amely a platform hitelesítőjévé válik a munkamenet idejére.
Per‑request validáció
Minden későbbi kérésnél a regionális gateway elküldi a session cookie‑t a központi /gateway/userinfo végpontra. A központi gateway visszaadja az identitásigényeket (például user ID, email, csoportok, szerepek, munkamenet‑metaadatok). A regionális gateway ezeket a megbízható adatok használva hozzáadja a standardizált identitás fejléceket, és továbbítja a kérést a backendnek.
Token‑refresh és kijelentkezés
Amikor egy access token a lejárathoz közelít, a központi gateway használja a tárolt refresh‑tokent és frissíti a session rekordot a megosztott store‑ban, így minden regionális gateway ugyanazt az állapotot látja. Kijelentkezéskor a központi gateway törli a session rekordot: a következő kérésnél minden regionális gateway érvénytelen session‑t észlel, és letiltja a hozzáférést vagy átirányít a belépéshez.
Miért jobb ez, mint a széttagolt munkamenet‑modell?
A hagyományos, „minden gateway saját sessiont birtokol” modellnél:
- Minden eszköznél külön kell bejelentkezni (felhasználói oldalról kellemetlenség)
- A kijelentkezés helyi marad, így aktív sessionök maradhatnak más klaszterekben
- Token‑frissítés minden gateway‑en külön történik, ami megnöveli az upstream IdP terhelését
- Az identitáskontekstusok eltérőek és duplikálódhatnak
- Új szolgáltatások gyakran újraépítik ugyanazt az auth logikát
Központosított session‑tulajdonlásnál e problémák nagyrészt megszűnnek: a felhasználó egyszer jelentkezik be a platformra, a logout platform‑szintű, a token‑refresh koordinált, és a downstream identitás egységesített.
Biztonsági és megbízhatósági irányelvek
A központosítás növeli a központi gateway kritikus szerepét, ezért fontos a következők betartása:
- Használjunk biztonságos szolgáltatás‑kiszolgáló autentikációt (mutual TLS, workload identity vagy aláírt belső tokenek) a regionális gatewayek és a központi gateway között
- Töröljük a kliens által küldött identitás fejléceket, és csak a gateway által injektált fejléceket bízzuk meg
- Csak a szükséges adatokat tároljuk a session rekordban; rövid access‑token élettartamok, explicit TTL, refresh‑token védelme és titkosítás legyen
- Határozzuk meg egyértelműen a kiesési viselkedést (fail‑closed vagy rövid ideig cache‑elt validáció), a platform kockázati profilja szerint
- Naplózzuk a validációs, refresh és logout eseményeket auditálhatóság céljából
Üzemeltetési előnyök és skálázás
Egy kevésbé nyilvánvaló előny: csökken az upstream identitás‑infrastruktúra terhelése. A központosított modellben az IdP‑t egyszer hívjuk be bejelentkezéskor, regionális gatewayek csak a megosztott sessiont validálják. Ahogy nő a klaszterek és eszközök száma, az IdP‑terhelés közelebb áll a tényleges aktív felhasználók számához, nem pedig a felhasználó×eszköz×klaszter kombinációkhoz.
AI‑asszisztensek és egységes platformélmény
A modell lehetővé teszi, hogy egy platform‑asszisztens a felhasználó nevében hívjon meg backend eszközöket anélkül, hogy széleskörű szolgáltatói jogosultságokra lenne szüksége. Az asszisztens a platform‑sessiont lekérdezve megkapja a felhasználó identitását, és a backend kérésekben a felhasználó RBAC‑körét örökíti tovább — ez egyszerűbb auditálhatóságot és követhetőbb jogosultságkezelést eredményez.
Alkalmazás és migráció
A bevezetés lépései:
- Készítsünk leltárt: hol jönnek létre most sessionök, mely gatewayek futtatnak OIDC‑t, mely szolgáltatások dolgoznak fel tokeneket, milyen fejléceket bíznak meg a downstream komponensek, hogyan működik a logout ma
- Határozzuk meg a központi szerződést: melyik szolgáltatás birtokolja a sessiont, mit ad vissza a /gateway/userinfo, mely gateway réteg injektálhat identitás fejléceket, mennyi legyen a munkamenet élettartama, hogyan auditáljuk a refresh/logout eseményeket, mi történik session‑store kiesés esetén
- Migráljunk fokozatosan: vegyünk egy gatewayet vagy szolgáltatást, és cseréljük le a lokális validációt a központi validációra. Tartsuk változatlanul az alkalmazások felé mutató identitás‑interfészeket, hogy a backendek minimális módosítással működjenek tovább
Az eszköztár nem igényel zárt köztes szoftvert: szabványos OIDC‑könyvtárak, Redis (vagy más alacsony késleltetésű session‑store), és az ismert Kubernetes ingress vagy service‑mesh integrációk elegendők lehetnek.
Tapasztalatok
NVIDIA belső fejlesztői platformjainak implementációja szerint a minta 55%‑kal csökkentette az ismétlődő bejelentkezési eseményeket az AWS és OCI klaszterekre kiterjedő környezetekben. A szerkezet emellett egységes platform‑shellt, konzisztens kijelentkezést, csökkent upstream IdP‑terhelést és azonosított, delegált felhasználói identitással működő AI‑asszisztenseket tett lehetővé.
Záró gondolat
A széttagolt session‑állapot egy lassan felgyülemlő architekturális technikai adósság: először ismételt belépési kérdések jelentkeznek, később duplikált auth‑logika, inkonzisztens logout, felesleges IdP‑terhelés és darabolt felhasználói kontextus. A központi identitáskapu megoldja az alapok okát: a session tulajdonlását különválasztja a kérés‑ellenőrzéstől, így egy szolgáltatás kezeli a bejelentkezést, refresh‑t, validációt és logoutot, míg a regionális gatewayek helyi szabályokat hajtanak végre a központi session‑igény alapján.
Ha a cél egy federált Kubernetes‑, adat‑ vagy AI‑platform egységes, auditálható és skálázható identitáskezelése, érdemes megvizsgálni, hol él ma a munkamenet‑állapot, és hány komponens hoz helyi identitásdöntést — innen egy egyszerű, lépésenkénti migrációs útvonal indulhat el.
