A natív Kubernetes Secrets valójában csak base64-encodolva van, nem titkosítva, ami komoly biztonsági sebezhetőségeket okozhat GitOps workflow-k bevezetésekor. Érdemes tehát referenciaalapú megközelítést alkalmazni, amelyben a Git csak a secretre mutató hivatkozást tárolja, míg a tényleges secret a külső rendszerben marad. Ebben a cikkben konkrét implementációs példákon keresztül mutatok be három alternatívát a sebezhetőség elhárítására, beleértve a natív Kubernetes Secrets „megerősítését” (hardening) is.
1. megközelítés: Natív Kubernetes Secrets hardeninggel
2. megközelítés: Secrets Store CSI Driver
3. megközelítés: External Secrets Operator
A referencia-architektúra
A példákhoz egy meglehetősen standard architektúrát használunk:
- Kubernetes cluster (AKS, EKS, GKE vagy self-managed)
- PostgreSQL adatbázis
- Webalkalmazás microservice-ekkel
- Külső secret store
Ez az architektúra egy tipikus felépítés, ahol az alkalmazásoknak biztonságos hozzáférésre van szükségük külső erőforrásokhoz, miközben betartják a biztonsági best practice-eket.
1. megközelítés: Natív Kubernetes Secrets hardeninggel
A natív Kubernetes Secrets komoly korlátokat állít, mivel az értékek base64-encodolva (nem titkosítva) tárolódnak az etcd-ben. Megfelelő hardening lépésekkel azonban biztonságosabbá tehetők bizonyos use case-ek számára.
Encryption at rest engedélyezése az etcd számára
Az első kritikus hardening lépés az „encryption at rest” engedélyezése az etcd-hez. Titkosítás nélkül a secretek plaintext formában tárolódnak a cluster etcd adatbázisában.
A Kubernetes Secrets megfelelő védelméhez az encryption at rest engedélyezése kötelező. A hivatalos Kubernetes dokumentáció alapján így valósítható meg:
Erős titkosítási kulcs generálása
Az első lépés egy biztonságos 32-byte kulcs generálása és base64-enkódolása:
head -c 32 /dev/urandom | base64
EncryptionConfiguration fájl létrehozása
Ezután hozz létre egy EncryptionConfiguration Kubernetes erőforrást:
A részletekért lásd az alábbi dokumentációt:
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data
A megfelelő encryption provider kiválasztása
A Kubernetes több encryption providert támogat, melyeknek mind megvannak az előnyei, hátrányai és korlátai. Bővebb részletekért lásd:
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers
Lokális vs. KMS titkosítás
Ha lokálisan kezelt kulcsot használsz titkosításra (ahogy a fenti példa mutatja), az csak az etcd kompromittálása ellen véd, a host kompromittálása ellen nem. Mivel az EncryptionConfiguration YAML fájl tartalmazza a titkosítási kulcsot, egy támadó, aki hozzáfér a control plane node-okhoz, ki tudja olvasni ezt – ne feledd: a base64 csak kódolás, nem titkosítás.
Nagyobb biztonság érdekében fontold meg a KMS provider használatát, amely az erőforrásokat egy data encryption key (DEK) segítségével, majd – ezt a data keyt – egy key encryption key (KEK) kulccsal titkosítja, amit egy külső key management service kezel. Ez az etcd és a harmadik féltől származó KMS provider együttes függőségét hozza létre, ami lényegesen biztonságosabbá teszi a megoldást.
API Server konfigurálása
A static pod manifest szerkesztésével mountold az encryption configurationt a kube-apiserverhez:
Az encryption működésének ellenőrzése
Az encryption at rest beállítása és az API server újraindítása után ellenőrizheted, hogy a secretek titkosítva vannak-e az etcd-ben.
Lépésről lépésre itt: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#verifying-that-data-is-encrypted
Meglévő secretek titkosítása
Fontos: a titkosítás bekapcsolása előtt létrehozott secretekhez további lépések szükségesek, hogy biztosan titkosítva legyenek. A Kubernetes dokumentáció átfogó útmutatót tartalmaz arról, hogyan gondoskodj róla, hogy minden releváns adat titkosítva legyen, beleértve azokat a parancsokat is, amelyek frissítik a meglévő secretek állapotát a tartalom megváltoztatása nélkül. Lásd az „Ensure all relevant data are encrypted” részt.
RBAC kontrollok megvalósítása
Kötelező korlátozni, ki férhet hozzá és ki kezelheti a secreteket. Itt egy példa RBAC konfigurációra a „least privilege” elv szerint:
Ezzel az RBAC konfigurációval biztosítjuk, hogy csak a myapp-service ServiceAccount olvashassa a db-credential secretjét, és csak a get műveletet hajthassa végre. Ez jelentősen csökkenti az illetéktelen hozzáférés kockázatát.
Fájlok titkosítása Git-ben
Ha Kubernetes manifesteket Git repositorykban tárolsz, az érzékeny adatok titkosítása kötelező. Olyan eszközök, mint a Mozilla SOPS, Sealed Secrets és git-crypt használhatók arra, hogy a titkosított secretek biztonságosan, az alkalmazáskód mellett legyenek tárolhatók.
Kommunikációk védelme TLS/SSL-lel
A Kubernetes-kommunikáció teljes körű TLS titkosítása alapvető az átfogó biztonsághoz. Ez érinti az API server, etcd és kubelet kommunikációját, valamint az alkalmazás szintjén is szükséges. A cert-managerhez hasonló certificate management eszközök segíthetnek az automatizálásban.
Mindkét téma elég összetett ahhoz, hogy önálló, dedikált útmutatót érdemeljen; javasolt a hivatalos Kubernetes dokumentáció tanulmányozása az adott környezethez igazítva.
2. megközelítés: Secrets Store CSI Driver
Ahogy az 1. részben bemutattam, a Secrets Store CSI Driver azzal kínál biztonságosabb megközelítést, hogy a secretek külső providerektől, közvetlenül volume-ként vannak a podokba mountolva, teljesen megkerülve az etcd tárolást (kivéve, ha a sync engedélyezve van).
Secrets Store CSI Driver telepítése
A legtöbb cloud provider kínál egyszerűsített telepítési módszert. Például AKS-en:
az aks enable-addons –addons azure-keyvault-secrets-provider –name myAKSCluster –resource-group myResourceGroup
Más környezetekben jellemzően Helm-et használunk:
helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts
helm install csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver \
–namespace kube-system \
–set syncSecret.enabled=true # ONLY IF YOU WOULD LIKE TO ENABLE SYNC!
A SSCSI sikeres telepítése után (Helm Charttal vagy a cloud provider megoldásával) definiálnunk kell a resource-t. A SecretProviderClass egy custom resource, amely meghatározza, mely secretek legyenek mountolva a külső providerből.
Ez a konfiguráció két fontos dolgot csinál:
- Meghatározza, mely secretek mountolódjanak az Azure Key Vaultból
- Beállítja az opcionális sync funkciót, amely a mountolt secretekből Kubernetes Secreteket hoz létre
Ne feledd: ha a sync funkciót használod, a secretek az etcd-ben is tárolódnak, ezért ebben az esetben is engedélyezd az encryption at restet, ahogy az 1. megközelítésben!
Deployolás CSI Driverrel közvetlen mounttal
A legbiztonságosabb megközelítés, ha az alkalmazás közvetlenül a mountolt volume-ról olvassa a secreteket. Ezzel a konfigurációval az alkalmazás fájlokból olvas, nem environment variable-ökből — ez biztonságosabb, de alkalmazás-módosítást igényelhet. Azokhoz az alkalmazásokhoz, amelyek nem tudnak egyszerűen fájlból olvasni, használható a sync funkció Kubernetes Secret létrehozására.
Bal oldalt példák vannak Kubernetes Secret Sync nélkül, jobb oldalt pedig a syncelt megoldásra.
Megjegyzés: még ha environment variable-öket is használunk, a volume mountolása akkor is szükséges, mert a CSI Driver csak azután hozza létre a Kubernetes Secretet, miután sikeresen mountolta a secreteket a külső providerből.
3. megközelítés: External Secrets Operator
Az External Secrets Operator (ESO) más megközelítést alkalmaz. A secretek volume-ként történő mountolása helyett külső providerekből szinkronizálja azokat Kubernetes Secretekkel.
External Secrets Operator telepítése
Az ESO telepíthető Helmmel:
helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets \
–namespace external-secrets \
–create-namespace
Azure autentikáció konfigurálása
Azure Key Vault integrációhoz az ESO több autentikációs módszert támogat. 2025. december állapot szerint AKS clustereknél a Workload Identity a javasolt megközelítés.
Azure autentikáció Workload Identityvel
Követelmények:
- AKS cluster engedélyezett Workload Identityvel
- Azure Key Vault releváns secrettel
- Azure AD Application (Enterprise App), amely rendelkezik Key Vault hozzáféréssel, és a cluster ServiceAccountjához van federálva
Első lépésként annotálnod kell a Kubernetes ServiceAccountot, hogy társítsd az Azure AD Applicationhöz.
Ezután konfigurálnod kell a SecretStore erőforrást Workload Identityhez.
Hozd létre az ExternalSecret erőforrást.
Amint az ExternalSecret erőforrás létrejött és a sync lefutott, létrejön egy Kubernetes Secret erőforrás. Ellenőrizheted ezzel a paranccsal:
kubectl get secret myapp-azure-secret -n external-secrets -o yaml
Ha a sync nem sikerül, nézd meg az operator logokat:
kubectl logs deployment/external-secrets -n external-secrets
Összegzés
Ebben a bejegyzésben több implementációt és példát jártunk végig a Kubernetes secret management témájában, a következő kulcsmegközelítésekre fókuszálva:
- 1. megközelítés: Natív Kubernetes Secrets hardeninggel – Könnyű használni, alap use case-ekhez megfelelő lehet, de production környezetben nem ajánlott.
- 2. megközelítés: Secrets Store CSI Driver – Külső secret store-okat integrál CSI volume-okon keresztül, lehetővé téve a secretek dinamikus mountolását anélkül, hogy az etcd-ben maradnának; ugyanakkor az alkalmazásnak fájlokból kell olvasnia a secreteket, ami kódmódosítást igényelhet.
- 3. megközelítés: External Secrets Operator (ESO) – Közvetlenül szinkronizál Azure Key Vaulthoz hasonló providerekből Kubernetes Secretekbe, támogatva a natív secret workflow-kat és az automatizálást. Általában ez a leginkább ajánlott.
A fenti példákat követve kiválaszthatod és implementálhatod azt a secret management mintát, amely a legjobban illeszkedik az igényeidhez. Ha lehetséges, használj olyan biztonságos módszert, mint az External Secrets Operator.
Források
https://kubernetes.io/docs/concepts/configuration/secret
https://kubernetes.io/docs/concepts/security/secrets-good-practices
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data
