Röviden: A pipeline a titkok egyik leggyakoribb szivárgási pontja. Az OIDC-alapú, rövid életű hitelesítés kiváltja a tartós kulcsokat — és ezzel a legnagyobb kockázatot.
A CI/CD pipeline az a hely, ahol a kód, a hitelesítő adatok és a külső hálózat összeér — és pont ezért a titkok egyik leggyakoribb szivárgási pontja. Egy tartós hozzáférési kulcs, ami egy pipeline-változóban pihen, csendben ott marad hónapokig, és ha valaha kikerül — egy logból, egy kompromittált függőségből, egy hibás jogosultságból —, akkor közvetlen kaput ad a rendszeredhez.
A gyökérprobléma: a tartós kulcs
A klasszikus minta az, hogy a pipeline egy hosszú életű hozzáférési kulcspárt kap, amit valaki egyszer beállított, és azóta senki nem forgatott. Ez a kulcs mindig érvényes, széles jogokkal, és sokszor több pipeline is osztozik rajta. Ha kiszivárog, nincs időablak, ami korlátozná a kárt — addig érvényes, amíg valaki észre nem veszi és le nem tiltja.
A megoldás: rövid életű, föderált hitelesítés
A modern válasz az OIDC-alapú föderáció. A lényeg: a CI-rendszer egy rövid életű, kriptográfiailag igazolt tokent mutat fel, amiért cserébe a felhő ideiglenes, szűk jogú hitelesítést ad — csak arra a futtatásra. Nincs tartós kulcs, amit ellopni lehetne, mert a hitelesítés a futtatás végén lejár.
- A CI-rendszer és a felhő között bizalmi kapcsolat épül (a felhő megbízik a CI OIDC-kibocsátójában).
- Minden futtatás egyedi, rövid életű tokent kap.
- A token szigorúan korlátozható: melyik repo, melyik ág, melyik környezet használhatja.
- A futtatás után a hitelesítés érvénytelen.
Ahol még szivárog
Az OIDC a legnagyobb kockázatot leveszi, de nem az egyetlen. Néhány gyakori szivárgási pont, amit külön kezelni kell:
- Logokba írt titkok — egy debug kiírás, ami véletlenül a tokent is kinyomtatja. A titkokat maszkolni kell a logban.
- Build artifactba ragadt titok — egy konfigurációs fájl, ami a kimenetbe kerül. Az artifactokat is ellenőrizni kell.
- Külső függőségek — egy kompromittált csomag futásidőben kiolvashatja a környezeti változókat. Ezért is jobb a rövid életű, szűk jogú token.
- Pull request forgalom — külső PR-ok soha ne férjenek hozzá a titkokhoz.
A titkok tárolása, ahol muszáj
Ahol mégis kell tárolt titok (például egy külső, OIDC-t nem támogató szolgáltatás kulcsa), ott menedzselt titoktár a helye, nem egy sima pipeline-változó. A menedzselt tár rotálható, auditálható, és a hozzáférés szűkíthető. A cél mindig ugyanaz: minél kevesebb tartós titok, minél rövidebb élettartammal, minél szűkebb jogokkal.
Az OIDC bevezetésének lépései
Az OIDC-alapú, tartós kulcs nélküli hitelesítés bevezetése nem bonyolult, de figyelmet igényel. Először a felhő és a CI-rendszer között kell felépíteni a bizalmi kapcsolatot: a felhő megbízik a CI OIDC-kibocsátójában. Ezután a bizalmi feltételt a lehető legszűkebbre kell szabni — ne csak a szervezetre, hanem a konkrét repóra és lehetőleg az ágra vagy környezetre is.
- Építsd fel a bizalmi kapcsolatot a CI OIDC-kibocsátójával.
- Szűkítsd a bizalmi feltételt konkrét repóra és ágra.
- Adj a felvehető szerepkörnek a lehető legszűkebb jogokat.
- Iktasd ki a régi, tartós kulcsokat, miután az OIDC működik.
A titkok maszkolása és izolálása
Az OIDC a legnagyobb kockázatot leveszi, de a titkok kiszivárgásának más útjait is le kell zárni. A logokban a titkokat maszkolni kell, hogy egy debug kiírás ne fedje fel őket. A build artifactokat ellenőrizni kell, nehogy titok ragadjon beléjük. És a külső pull requestek soha ne férjenek hozzá a titkokhoz — ez a leggyakrabban kihasznált rés a publikus projekteknél.
A maradék tartós titkok kezelése
Ahol az OIDC nem alkalmazható (például egy külső szolgáltatás, ami nem támogatja), ott továbbra is lesz tartós titok. Ezeket menedzselt titoktárban tartsd, ne sima pipeline-változóban: a menedzselt tár rotálható, auditálható, és a hozzáférés szűkíthető. A cél mindig ugyanaz — minél kevesebb tartós titok, minél rövidebb élettartammal, minél szűkebb jogokkal, és ami marad, az a lehető legjobban védve.
Mit jelent ez neked?
A pipeline titkainál a legnagyobb kockázat a tartós, széles jogú kulcs. Váltsd ki OIDC-alapú, rövid életű, föderált hitelesítéssel, és a bizalmi feltételt szűkítsd a konkrét repóra és ágra. Maszkold a titkokat a logban, óvd az artifactokat, és soha ne engedd a külső PR-forgalmat a titkokhoz. Ahol muszáj tárolni, ott menedzselt, rotálható titoktár legyen — nem egy évek óta érintetlen pipeline-változó.