A fürt hitelesítés és autorizáció a Kubernetesben: OpenID Connect és a többiek

A mai felhőalapú világban a Kubernetes az alkalmazások üzemeltetésének de facto szabványává vált. Azonban egy ilyen dinamikus, konténerizált környezetben a biztonság garantálása – különösen a hitelesítés és autorizáció – elengedhetetlen. A Kubernetes API szerver a fürt szíve, és minden interakció (legyen az emberi felhasználó, másik szolgáltatás vagy maga a Kubernetes komponens) ezen keresztül történik. Ennek megfelelően kritikus, hogy csak az arra jogosult felhasználók és szolgáltatások férjenek hozzá, és ők is csak a számukra engedélyezett műveleteket végezhessék el.

Miért Kritikus a Hitelesítés és Autorizáció a Kubernetesben?

Képzeljen el egy épületet, ahol bárki, bármikor bemehet, és bármilyen szobába beléphet. Ez lenne egy Kubernetes fürt hitelesítés és autorizáció nélkül. Káosz, adatszivárgás, rosszindulatú támadások és a rendszer integritásának sérülése – ezek a közvetlen következmények. Egy megfelelően konfigurált hitelesítési és autorizációs rendszer biztosítja, hogy:

Csak az azonosított entitások (felhasználók, alkalmazások) férjenek hozzá a fürthöz.
Minden entitás csak a minimálisan szükséges jogosultságokkal rendelkezzen a feladatai elvégzéséhez (a legkevesebb jogosultság elve).
Nyomon követhető legyen, ki, mikor és milyen műveletet hajtott végre a fürtben.
Megelőzhetők legyenek a jogosultsági eskallációk és a biztonsági rések kihasználása.

A Kubernetes az alapoktól kezdve úgy épült fel, hogy rugalmasan kezelje ezeket a kihívásokat, számos beépített és bővíthető mechanizmussal.

Hitelesítés (Authentication) és Autorizáció (Authorization): A Két Alappillér

Mielőtt mélyebbre ásnánk, fontos tisztázni a két fogalom közötti különbséget:

Hitelesítés (Authentication): Ez a folyamat válaszolja meg a „Ki vagy te?” kérdést. Annak ellenőrzése, hogy egy felhasználó vagy szolgáltatás valóban az, akinek mondja magát. A hitelesítés sikeres befejezése után az API szerver tudja, kivel van dolga.
Autorizáció (Authorization): Ez pedig a „Mit tehetsz?” kérdésre ad választ. Miután az API szerver sikeresen hitelesítette az entitást, az autorizáció dönti el, hogy az adott entitás milyen műveleteket végezhet el (pl. podok létrehozása, logok olvasása, titkok módosítása).

A Kubernetes API szerver először mindig hitelesít, majd autorizálja a bejövő kéréseket.

A Hitelesítés Megoldásai a Kubernetesben: Ki Vagy Te?

A Kubernetes számos beépített hitelesítési mechanizmust kínál, lehetővé téve a fürt üzemeltetőinek, hogy a környezetüknek legmegfelelőbbet válasszák.

X.509 Kliens Tanúsítványok

Ez az egyik legrégebbi és legrobúsztusabb hitelesítési módszer. A felhasználók egy kliens tanúsítvánnyal mutatkoznak be az API szervernek, amelyet egy, az API szerver számára megbízható tanúsítványkiadó (CA) írt alá.

Működés: A felhasználó `kubeconfig` fájlja tartalmazza a kliens tanúsítványt és a hozzá tartozó privát kulcsot. Az API szerver ellenőrzi a tanúsítvány érvényességét, és ha megbízható CA írta alá, hitelesíti a felhasználót. A tanúsítvány tárgya (Subject) mezőjében lévő Common Name (CN) általában a felhasználónévként, míg az Organization (O) mező a csoportként kerül értelmezésre.
Előnyök: Erős, kölcsönös TLS-en alapuló hitelesítés.
Hátrányok: A tanúsítványok manuális kiosztása, visszavonása és kezelése nagyméretű környezetben bonyolult lehet.

Szolgáltatásfiók (Service Account) Tokenek

A szolgáltatásfiókok nem emberi felhasználók számára készültek, hanem a Kubernetes fürtben futó alkalmazások és komponensek számára. Minden pod alapértelmezetten egy szolgáltatásfiókhoz kapcsolódik, és a hozzá tartozó JWT (JSON Web Token) automatikusan beillesztésre kerül a pod fájlrendszerébe.

Működés: Az alkalmazás ezt a tokent használja az API szerverrel való kommunikációhoz. Az API szerver ellenőrzi a token érvényességét és hitelesíti a podot, mint a hozzá tartozó szolgáltatásfiókot.
Előnyök: Egyszerűen kezelhető az alkalmazások számára, automatikus rotáció a 1.21-es verziótól kezdve.
Hátrányok: A token kiszivárgása biztonsági kockázatot jelenthet.

OpenID Connect (OIDC): Az Identitáskezelés Modern Megközelítése

Az OpenID Connect (OIDC) a Kubernetes egyik legrugalmasabb és legmodernebb hitelesítési mechanizmusa, különösen emberi felhasználók számára. Lehetővé teszi, hogy a Kubernetes egy külső identitásszolgáltatóra (IdP) támaszkodjon a felhasználók hitelesítéséhez. Gondoljon olyan szolgáltatókra, mint az Azure AD, Google Workspace, Okta, Auth0 vagy Keycloak.

Hogyan Működik az OIDC a Kubernetesben?

Az OIDC alapja az OAuth 2.0 protokoll, amelyre egy identitásréteg épül. Lényegében a Kubernetes delegálja a felhasználói hitelesítést egy külső szolgáltató felé.

Amikor egy felhasználó megpróbál csatlakozni a Kubernetes API szerverhez (pl. `kubectl` segítségével), a `kubeconfig` fájlja úgy van konfigurálva, hogy egy OIDC flow-t kezdeményezzen.
A felhasználó böngészője átirányításra kerül az IdP bejelentkezési oldalára, ahol megadja a hitelesítő adatait (pl. felhasználónév, jelszó, MFA).
Sikeres hitelesítés után az IdP visszaküld egy ID tokent (és opcionálisan egy access tokent) a `kubectl`-nek.
A `kubectl` ezután az ID tokent mint bearer tokent küldi el a Kubernetes API szervernek.
Az API szerver ellenőrzi az ID token aláírását (a konfigurált OIDC issuer CA tanúsítványával), a kiállítót (issuer URL) és a célközönséget (audience – client ID). Ha minden érvényes, az API szerver kinyeri a felhasználónevet és csoportokat az ID tokenből (pl. `preferred_username` és `groups` claim-ekből) és hitelesíti a felhasználót.

Az OIDC Előnyei és Beállításai

Centralizált Identitáskezelés: A felhasználók ugyanazokkal a hitelesítő adatokkal jelentkezhetnek be a Kubernetesbe, mint más vállalati rendszerekbe.
Egyszeri Bejelentkezés (SSO): Ha a felhasználó már be van jelentkezve az IdP-be, azonnal hozzáférhet a Kuberneteshez.
Fokozott Biztonság: Kihasználhatóak az IdP fejlett biztonsági funkciói, mint a többfaktoros hitelesítés (MFA).
Egyszerűbb Felhasználókezelés: A felhasználók és csoportok kezelése az IdP-ben történik, nem közvetlenül a Kubernetesben.

Az API szerver konfigurálásához meg kell adni az OIDC issuer URL-t, a kliens ID-t, a CA tanúsítványt, valamint a felhasználónév és csoport claim-ek nevét. Például:
`kube-apiserver –oidc-issuer-url=https://accounts.google.com –oidc-client-id=kubernetes –oidc-username-claim=email –oidc-groups-claim=groups`

Webhook Hitelesítés

A Webhook hitelesítés egy rugalmas mechanizmus, amely lehetővé teszi a hitelesítési döntés delegálását egy külső szolgáltatásra. Amikor az API szerver egy kérést kap, elküldi a felhasználó bearer tokenjét egy konfigurált külső webhook szolgáltatásnak. Ez a szolgáltatás válaszolja meg, hogy a token érvényes-e, és ha igen, milyen felhasználóhoz és csoportokhoz tartozik.

Proxy-alapú Hitelesítés

Néha a Kubernetes API szerver elé egy proxy réteget (pl. egy API gateway-t vagy reverz proxyt) helyeznek. Ebben az esetben a proxy végzi a hitelesítést, és hozzáadja a hitelesített felhasználó adatait (általában HTTP fejlécekként) a Kubernetes API szerver felé továbbított kérelemhez. Az API szerver ezután konfigurálható arra, hogy megbízzon ezekben a fejlécekben (`–requestheader-client-ca-file`, `–requestheader-username-headers`, stb.).

Autorizáció (Authorization) a Kubernetesben: Mit Tehetsz?

A sikeres hitelesítés után az API szervernek el kell döntenie, hogy az adott felhasználó vagy szolgáltatás elvégezheti-e a kért műveletet. Ez az autorizáció feladata.

RBAC (Role-Based Access Control): Az Autorizáció Gerince

A RBAC (Role-Based Access Control) a Kubernetes autorizációjának elsődleges és ajánlott módszere. Lehetővé teszi a jogosultságok részletes és rugalmas szabályozását a szerepekhez való kötésen keresztül.

Szerepek (Roles) és FürtSzerepek (ClusterRoles)

Role: Egy Role egy névtéren belüli erőforrásokhoz való hozzáférést definiálja. Például egy „dev-role” engedélyezheti a podok létrehozását és törlését a „development” névtérben.
ClusterRole: Egy ClusterRole vagy névtér-agnosztikus erőforrásokhoz (pl. node-ok) való hozzáférést, vagy minden névtérre kiterjedő hozzáférést definiál. Például egy „admin-clusterrole” engedélyezheti az összes erőforrás kezelését az összes névtérben, vagy egy „node-reader” csak a node-okkal kapcsolatos információkat olvashatja.

A szerepek és fürt szerepek YAML definíciója tartalmazza az API csoportokat, erőforrásokat és a megengedett műveleteket (verbs: get, list, watch, create, update, delete, patch).

Szerepkötések (RoleBindings) és FürtSzerepkötések (ClusterRoleBindings)

A szerepek önmagukban nem adnak jogosultságot. Ahhoz, hogy egy szerep hatályba lépjen, azt egy felhasználóhoz, csoporthoz vagy szolgáltatásfiókhoz kell kötni egy RoleBinding vagy ClusterRoleBinding segítségével:

RoleBinding: Egy Role-t köt össze felhasználókkal, csoportokkal vagy szolgáltatásfiókokkal egy adott névtéren belül. Például a „dev-role” RoleBinding köti a „dev-role”-t a „developers” csoporthoz a „development” névtérben.
ClusterRoleBinding: Egy ClusterRole-t köt össze felhasználókkal, csoportokkal vagy szolgáltatásfiókokkal, és ez a kötés az egész fürthöz érvényes. Például a „admin-clusterrole” ClusterRoleBinding köti az „admin-clusterrole”-t az „operations” csoporthoz az egész fürtre nézve.

Az RBAC a legkevesebb jogosultság elvét követve építhető fel, ami alapvető fontosságú a biztonságos Kubernetes környezet kialakításában.

Egyéb Autorizációs Módok

Bár az RBAC a domináns, más autorizációs módok is léteznek:

Node Autorizáció: Ez egy speciális autorizátor, amely kizárólag a kubelet-ek jogosultságait kezeli, biztosítva, hogy csak a saját node-jukhoz és azokon futó podokhoz férjenek hozzá.
Webhook Autorizáció: Hasonlóan a webhook hitelesítéshez, ez a módszer is egy külső szolgáltatásra delegálja az autorizációs döntést. Az API szerver elküldi a kérést (ki, mit akar csinálni) egy külső webhooknak, amely eldönti, hogy engedélyezi-e a műveletet.
AlwaysAllow/AlwaysDeny: Ezek egyszerű, de extrém módok. Az AlwaysAllow mindent engedélyez (csak fejlesztési/tesztelési környezetben javasolt), az AlwaysDeny pedig mindent megtilt.

Szolgáltatásfiókok (Service Accounts): Az Alkalmazások Identitása

Mint korábban említettük, a szolgáltatásfiókok (Service Accounts) kulcsszerepet játszanak a Kubernetesben futó alkalmazások hitelesítésében és autorizációjában.
Minden pod egy szolgáltatásfiók környezetében fut. Ha nincs explicit módon megadva, az alapértelmezett (default) szolgáltatásfiókot használja az adott névtérben. A szolgáltatásfiók JWT tokenje a pod fájlrendszerébe kerül (alapértelmezés szerint a `/var/run/secrets/kubernetes.io/serviceaccount/token` elérési úton), és ezt használja az alkalmazás az API szerverrel való kommunikációhoz.
A szolgáltatásfiókokhoz is lehet RBAC szerepeket kötni, így pontosan szabályozható, hogy egy adott alkalmazás milyen API műveleteket hajthat végre a fürtben.

Admission Controllers: A Biztonsági Lánc Utolsó Szeme

Az Admission Controllers (felvételi vezérlők) kulcsszerepet játszanak a Kubernetes biztonsági láncában, bár nem közvetlenül hitelesítési vagy autorizációs mechanizmusok. Ezek a komponensek a Kubernetes API szerverben futnak, és módosíthatják vagy elutasíthatják a kéréseket, miután azok átestek a hitelesítésen és autorizáción.
Két fő típusuk van:

Mutating Admission Controllers: Módosíthatják az objektumokat a létrehozásuk vagy frissítésük előtt. Pl. automatikusan hozzáadhatnak sidecar konténereket vagy biztonsági kontextusokat.
Validating Admission Controllers: Érvényesítik a kéréseket anélkül, hogy módosítanák őket. Elutasíthatnak olyan kéréseket, amelyek megsértik a vállalati vagy biztonsági szabályzatokat.

Példa: A `PodSecurity` admission controller kényszeríti a Pod Security Standards (PSS) betartását, biztosítva, hogy a podok biztonságosan konfiguráltak legyenek. Egyéni webhook alapú admission controllereket is létrehozhatunk, amelyek további, specifikus üzleti logikát vagy biztonsági szabályokat kényszeríthetnek ki.

Legjobb Gyakorlatok és Biztonsági Tippek

Egy biztonságos Kubernetes környezet kialakításához nem elegendő pusztán a hitelesítési és autorizációs mechanizmusok beállítása. Számos bevált gyakorlatot érdemes követni:

A Legkevesebb Jog Elve (Principle of Least Privilege)

Mindig csak a minimálisan szükséges jogosultságokat adja meg a felhasználóknak és szolgáltatásfiókoknak. Kerülje a széleskörű jogosultságok, mint a `cluster-admin`, kiosztását, kivéve ha az abszolút elengedhetetlen.

Audit Naplózás

Engedélyezze és konfigurálja a Kubernetes audit naplókat. Ezek rögzítik az API szerverhez érkező összes kérést, beleértve a felhasználókat, az időbélyegeket, a kért műveleteket és a válaszokat. Az audit naplók kritikusak a biztonsági incidensek kivizsgálásához és a compliance megfelelésekhez.

Folyamatos Felülvizsgálat és Verziókövetés

Rendszeresen vizsgálja felül az RBAC szabályzatokat. Ahogy a fürt és az alkalmazások fejlődnek, a jogosultságoknak is alkalmazkodniuk kell. Használjon verziókövetést (GitOps) az RBAC konfigurációk kezelésére.

Hálózati Szabályzatok (Network Policies)

Bár nem közvetlenül hitelesítés/autorizáció, a hálózati szabályzatok (Network Policies) elengedhetetlenek az in-cluster hálózati forgalom szabályozásához. Ezek segítségével korlátozhatja, hogy mely podok kommunikálhatnak egymással, csökkentve ezzel a laterális mozgás kockázatát egy biztonsági incidens esetén.

Pod Biztonsági Szabványok (Pod Security Standards)

Használja a Pod Security Standards (PSS) segítségével a podok futtatására vonatkozó biztonsági alapelveket. Ezek biztosítják, hogy a podok a lehető legkisebb jogosultsággal fussanak, megakadályozva például a rootként való futtatást vagy a host fájlrendszerhez való hozzáférést.

Konklúzió: Egy Biztonságosabb Kubernetes Jövő

A Kubernetes egy erőteljes platform, de a benne rejlő potenciált csak akkor tudjuk teljes mértékben kihasználni, ha a biztonsági aspektusokra is kiemelt figyelmet fordítunk. A hitelesítés és autorizáció nem csupán technikai követelmények, hanem a bizalom és az integritás alapjai egy felhőalapú környezetben.
Az OpenID Connect bevezetése modern és skálázható megoldást kínál az emberi felhasználók identitáskezelésére, integrálva a Kubernetes-t a meglévő vállalati identitásszolgáltatókkal. Az RBAC pedig robusztus keretet biztosít a jogosultságok finomhangolásához, míg az Admission Controllers és a legjobb gyakorlatok a biztonsági mélységet adják meg.
A folyamatosan fejlődő fenyegetések korában a Kubernetes biztonságának fenntartása állandó éberséget és proaktív megközelítést igényel. A megfelelő hitelesítési és autorizációs stratégiával azonban magabiztosan építhetünk és futtathatunk alkalmazásokat a Kubernetesben. A jövő a biztonságos, automatizált és jól auditálható rendszereké, és a Kubernetes élen jár ennek megvalósításában.