Röviden: A titkos adat és a deklaratív, mindent-a-gitbe elv ellentmond egymásnak. A sealed secret vagy a külső titoktár a híd, ami feloldja a feszültséget.
A GitOps alapelve gyönyörűen egyszerű: minden kívánt állapot a git repóban van, és a rendszer ehhez igazodik. De van egy dolog, ami ezzel az elvvel homlokegyenest szembemegy: a titkok. A jelszavak, kulcsok, tokenek nyilván nem kerülhetnek egyszerű szövegként a repóba — pláne, ha az valaha is szélesebb körben elérhető. Itt feszül egymásnak a „mindent a gitbe” elv és a „titkot sehova, ami olvasható” szabály.
Miért nem mehet a titok a repóba?
A git repo verziózott, sokan olvassák, és a története örökre megőrzi, amit egyszer beletettél. Ha egy titok bekerül — még ha később törlöd is —, a history-ban ott marad. Egy repóba írt kulcs gyakorlatilag kiszivárgott kulcs: bárki, aki valaha hozzáfér a repóhoz vagy a történetéhez, megkapja. Ezért a nyílt szövegű titok a repóban nem opció.
A feloldás iránya
A feszültséget nem úgy oldjuk fel, hogy feladjuk a GitOps-ot, hanem úgy, hogy a titkot titkosítva vagy hivatkozásként tesszük a repóba, a tényleges értéket pedig máshol tartjuk. Két fő megközelítés van, és mindkettő legitim.
1. Titkosított titok a repóban (sealed secret)
Az egyik út, hogy a titkot titkosítva tárolod a repóban. A titkosított formát bárki láthatja, de csak a klaszterben lévő, jogosult komponens tudja visszafejteni. Így a GitOps-elv sértetlen (minden a repóban van), de a nyílt érték soha nem kerül olvasható formában a gitbe. A visszafejtő kulcs a klaszterben él, nem a repóban.
2. Hivatkozás külső titoktárra
A másik út, hogy a repóban csak egy hivatkozás van egy külső, dedikált titoktárra, ahol a tényleges érték biztonságosan, rotálhatóan tárolódik. A rendszer futásidőben, jogosultság alapján oldja fel a hivatkozást és szerzi meg a titkot. A repó így soha nem tartalmaz titkot, csak azt, hogy honnan kell elkérni.
A választás szempontjai
| Szempont | Titkosított titok a repóban | Külső titoktár + hivatkozás |
|---|---|---|
| GitOps-tisztaság | Teljes (minden a repóban) | A titok kívül van |
| Rotáció | Nehezebb (újratitkosítás) | Egyszerűbb, központi |
| Külső függőség | Kevesebb | Egy titoktár-szolgáltatás |
| Audit | A repón át | A titoktáron át, központilag |
A közös alapelv
Mindkét megoldás ugyanazt a célt szolgálja: a nyílt titok soha ne legyen olvasható a repóban, a hozzáférés legyen szűk és jogosultsághoz kötött, és a titkok legyenek rotálhatók. A választás a csapatod igényein múlik — mennyire fontos a teljes GitOps-tisztaság, van-e már külső titoktárad, mennyire gyakori a rotáció.
A két megközelítés
Az egyik út a titkosított titok a repóban (sealed secret): a titkosított formát bárki láthatja, de csak a klaszterben lévő, jogosult komponens tudja visszafejteni. Így a GitOps-elv sértetlen (minden a repóban van), de a nyílt érték soha nem kerül olvasható formában a gitbe. A másik út egy hivatkozás külső titoktárra: a repóban csak az van, honnan kell elkérni a titkot, a tényleges érték biztonságosan, rotálhatóan kívül él.
- Titkosított titok a repóban → teljes GitOps-tisztaság.
- Külső titoktár + hivatkozás → egyszerűbb rotáció, központi audit.
Mit jelent ez neked?
A GitOps és a titkok feszültsége valós, de feloldható: a nyílt titok soha nem mehet a repóba, mert a history örökre megőrzi. Vagy titkosítva tedd be (sealed secret), ahol csak a jogosult klaszter tudja visszafejteni, vagy tarts a repóban csak hivatkozást egy külső titoktárra, ahol a tényleges érték rotálhatóan él. Bármelyiket választod, védd a repo history-t is, és ha valaha nyílt titok került bele, tekintsd kompromittáltnak és rotáld. Így a GitOps-elv és a titokvédelem együtt is megvalósul.