A legjobb Kubernetes Secrets kezelőeszközök 2026-ban: Vault, ESO, Sealed Secrets és egyebek

Minden Kubernetes-fürt egy beépített “Secret” objektumot tartalmaz. Biztonságnak tűnik. Biztonságnak érzi magát. Ez nem biztonság.

A Kubernetes Secret alapértelmezés szerint csak egy base64 kódolású karakterlánc, amely az etcd-ben van tárolva – bárki elolvashatja, aki rendelkezik fürt hozzáféréssel, és triviálisan dekódolható egysoros sorral: echo "c2VjcmV0" | base64 -d. Hacsak kifejezetten nem engedélyezte a titkosítást nyugalmi állapotban (és a legtöbb csapat nem tette), az adatbázis-jelszavak, API-tokenek és TLS privát kulcsok titkosítatlanul helyezkednek el a fürt vezérlősík-adattárában. Tegye fel a ‘Secret’-et tartalmazó Kubernetes-jegyzéket a Gitre, és ez a hitelesítő adat örökre a tárhely történetében marad.

Ez az a probléma, amelynek megoldására a titkok kezelésére szolgáló eszközök új generációja jelent meg – és 2026-ban az ökoszisztéma jelentősen kifejlődött. Ez az útmutató a Kubernetes-környezetekben a titkok kezelésére szolgáló hat legfontosabb eszközt ismerteti: mit csinálnak, mit nem, és melyik illik a csapat érettségi szintjéhez.

Kapcsolódó olvasmányok: Ha aggódik amiatt, hogy titkok szivárognak ki a CI/CD-folyamatban, tekintse meg a legjobb CI/CD-csővezeték-eszközök összefoglalóját. A szélesebb körű konténerbiztonsági képért tekintse meg a [sebezhetőség-ellenőrző eszközök útmutatóját] (/posts/vulnerability-scanning-tools-devops-2026/).

Miért maradnak el a Kubernetes alapértelmezett titkai?

Mielőtt belemerülne az eszközökbe, érdemes pontosan meghatározni, mi hiányzik a Kubernetes Secretsből – mert a hiányosság megértése az, ami lehetővé teszi a megfelelő megoldás kiválasztását.

Alapértelmezés szerint nincs titkosítás nyugalmi állapotban. Az etcd a Kubernetes Secrets fájlt base64-ként tárolja, nem titkosítva. A [Encryption at Rest] (https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) engedélyezése egy fürtszintű konfigurációs lépés, amelyet a felügyelt Kubernetes-szolgáltatók (EKS, GKE, AKE) másképpen kezelnek, és sok önállóan kezelt fürt teljesen kihagyja.

Nincs titkos rotáció. Nincs beépített mechanizmus, amely lehetővé tenné a Kubernetes Secret számára, hogy tudja, hogy a háttér hitelesítő adatai megváltoztak. Külsőleg elforgatja az adatbázis jelszavát, és a pod-ok továbbra is a régit használják, amíg manuálisan nem frissíti a Secretet, és újraindítja az érintett podokat.

Nincs megfigyelési napló a titkos hozzáféréshez. A szabványos Kubernetes naplózási naplózás rögzíti a titkos objektummódosításokat, de a legtöbb konfiguráció nem naplózza az egyes olvasásokat – ami azt jelenti, hogy nem lehet válaszolni arra, hogy „melyik szolgáltatás érte el ezt a tokent, és mikor?”

Kitervezésénél fogva ellenséges a Git. A szokásos tanács: „soha ne kösd el a titkokat a Gitnek”. De egy GitOps-világban, ahol a „minden kódként” a cél, ez egy fájdalmas kivétel, amelyet fenn kell tartani.

Az RBAC mint tompa eszköz. A Kubernetes RBAC lehetővé teszi a titkos objektumokhoz való hozzáférés megadását vagy megtagadását a névtér szintjén. Nem fejezheti ki azt, hogy „Az A szolgáltatás olvassa a titkos X-et, de a titkos Y-t nem”, vagy „ez a titok 24 órán belül lejár”.

Ezek egyike sem ok arra, hogy elhagyjuk a Kubernetes-et – ezek az okok a dedikált titokkezelési eszközök használatára.

TL;DR – Funkció-összehasonlítás

⚠️ = további összetevőket igényel

1. HashiCorp Vault – A vállalati titkok aranyszabványa

A HashiCorp Vault az a viszonyítási alap, amelyhez minden más titokkezelő eszközt mérni kell. Csaknem egy évtizede tesztelték vállalati környezetben, és funkciókészlete ezt a mélységet tükrözi.

A Vault alapvető képessége a dinamikus titkok – a hitelesítő adatok, amelyek igény szerint generálódnak, és automatikusan lejárnak. A Statikus PostgreSQL-jelszó tárolása helyett a Vault egyedi felhasználónév/jelszó párost generál minden egyes kérő szolgáltatáshoz, amely egy konfigurálható bérleti időszakra (például egy óra) érvényes. A bérleti szerződés lejártakor a megbízólevél visszavonásra kerül. Ez kiküszöböli a hitelesítő adatok szétterjedésének egész osztályát, és jelentősen megkönnyíti a jogsértések elleni védekezést.

A Kubernetes esetében a Vault Agent Injector vagy a Vault Secrets Operator az integrációs útvonal. Az injektor mutáló webhookként fut, amely automatikusan egy Vault-ügynököt helyez el a pod-okba, amely hitelesíti a Vaultot a pod Kubernetes szolgáltatásfiókjával, és titkokat ír egy megosztott memóriában lévő kötetre. A Vault Secrets Operator (VSO), az újabb megközelítés, szinkronizálja a Vault titkokat natív Kubernetes Secret objektumokkal – az operátorok számára jobban ismert, az etcd-ben rövid ideig meglévő titkok árán.

A Vault titkos motorjai lenyűgöző tartományt fednek le:

• Adatbázis hitelesítő adatok (PostgreSQL, MySQL, MongoDB stb.)
• AWS, GCP, Azure dinamikus hitelesítő adatok
• PKI és TLS tanúsítvány generálása
• SSH tanúsítvány aláírása
• Kubernetes szolgáltatásfiók-tokenek

Amit jól teljesít a Vault: Dinamikus hitelesítő adatok, részletes hozzáférési házirendek, átfogó auditnapló és kiforrott beépülő ökoszisztéma. Ha megfelelőségi fokozatú titkos kezelésre van szüksége a ki-mit-mikor-hozzáférés teljes nyomon követésével, a Vault gyakran az egyetlen ésszerű lehetőség.

Mire kell figyelni: A Vault működése bonyolult. Magas rendelkezésre állású módban való futtatásához gondos figyelmet kell fordítani a tárolási háttérrendszerekre (most a Raft az ajánlott választás), a lezárási eljárásokra és a frissítési útvonalakra. A tanulási görbe valós. Költségvetés a platform tervezési idejére.

Árak: A nyílt forráskódú verzió ingyenes, és a legtöbb igényt kielégíti. A HashiCorp Cloud Platform (HCP) Vault egy felügyelt ajánlat, amely a fürt órákon és titkos műveleteken alapul. A BSL-licenc-módosítás 2023-tól az OpenTofu fork for Terraformhoz vezetett, de a Vault fork megfelelője (OpenBao) még mindig érlelődik.

📚 Ajánlott olvasmány: Andrew Martin és Michael Hausenblas Hacking Kubernetes – kiváló lefedettség a Kubernetes támadási felületeiről, beleértve a titkos kiszűrési forgatókönyveket.

2. External Secrets Operator (ESO) – A K8s-Native Integration Layer

Az External Secrets Operator alapvetően más építészeti álláspontot képvisel: ahelyett, hogy maga egy titoktár lenne, hidat képez a Kubernetes és a már meglévő külső áruház között. Az ESO szinkronizálja az AWS Secrets Manager, a GCP Secret Manager, az Azure Key Vault, a HashiCorp Vault, az 1Password, a Doppler és más háttérprogramok növekvő listájának titkait natív Kubernetes Secret objektumokkal.

Az alapvető absztrakció az “ExternalSecret” egyéni erőforrás:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: production/db/password

Az ESO figyeli ezt az erőforrást, lekéri a titkot az AWS Secrets Managertől (vagy bárhonnan), és létrehoz egy szabványos Kubernetes Secretet. Az Ön alkalmazása ugyanúgy olvassa a “db-creds” fájlt, mint bármely más Kubernetes Secret – nincs szükség kódmódosításra. Amikor a “refreshInterval” bejelöli, az ESO újra lekéri és automatikusan frissíti a titkos adatot.

Miért olyan népszerű az ESO 2026-ban: Jól illeszkedik a meglévő befektetésekhez. A szervezete már rendelkezik AWS Secrets Managerrel (vagy Vault-tal vagy GCP Secret Manager-rel) – az ESO egyszerűen felhasználhatóvá teszi ezeket a titkokat a Kubernetesben anélkül, hogy módosítaná az alkalmazáskódot vagy a meglévő titkos rotációs munkafolyamatokat.

ESO vagy Vault Secrets Operator? Ha Vaultot futtat, a VSO szorosabb Vault-specifikus integrációval rendelkezik (Vault dinamikus titkok, Vault PKI). Ha egy felhőszolgáltató natív titkos áruházát használja, az ESO a tisztább választás. Sok csapat mindkettőt futtatja – az ESO a felhőben tárolt statikus titkokhoz, a VSO a Vault által kezelt dinamikus hitelesítési adatokhoz.

Árak: Az ESO ingyenes és nyílt forráskódú (Apache 2.0), amelyet egy CNCF sandbox projekt karbantart, erős közösségi támogatással.

3. Lezárt titkok — GitOps-barát titkosított titkok

A Bitnami [Sealed Secrets] (https://github.com/bitnami-labs/sealed-secrets) egy konkrét problémát old meg: hogyan tárolhatja a Kubernetes Secret manifeszteket a Gitben anélkül, hogy a tényleges egyszerű szöveget tárolná? A válasz az aszimmetrikus titkosítás.

A Sealed Secrets vezérlő a fürtben fut, és magánkulcsot tartalmaz. A “kubeseal” parancssori felület titkosítja a Kubernetes titkos jegyzéket a fürt nyilvános kulcsával, és létrehoz egy “SealedSecret” CRD-t. Ez a titkosított jegyzék biztonságosan leköthető a Git számára – csak a fürt privát kulcsa tudja visszafejteni, és csak az adott fürtben lehet visszafejteni (alapértelmezés szerint a titkosított szöveg névtér + névhez van kötve).

# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
  --from-literal=password=s3cr3t \
  --dry-run=client -o yaml | \
  kubeseal --format=yaml > db-creds-sealed.yaml

# This file is safe to commit
git add db-creds-sealed.yaml

Amikor alkalmazza a “SealedSecret”-et a fürtre, a vezérlő visszafejti azt, és létrehozza a megfelelő “Secret” objektumot.

Mire jó a Sealed Secrets: GitOps munkafolyamatok. Ha Argo CD-t vagy Fluxot használ, és minden fürt erőforrást (beleértve a titkokat is) deklaratívan a Gitben szeretné tárolni, a Sealed Secrets tökéletesen illeszkedik ehhez a modellhez. A fürtön belüli vezérlőn kívül nulla külső függőséget igényel.

Amit nem csinál: Rotáció, dinamikus hitelesítési adatok vagy a szokásos Kubernetes-eseményeken túlmutató naplózás. A Sealed Secrets egy Git-tároló megoldás, nem pedig egy teljes titokkezelési platform. Ha a jelszava megváltozik, akkor újra titkosítja, és újra véglegesíti.

A privát kulcs biztonsági mentése kritikus fontosságú. Ha elveszíti a vezérlő privát kulcsát, elveszíti a lezárt titkok visszafejtésének lehetőségét. Készítsen biztonsági másolatot a “sealed-secrets-key” titkáról egy külön, biztonságos helyre.

Árak: Teljesen ingyenes és nyílt forráskódú (Apache 2.0).

4. AWS Secrets Manager a Kubernetes segítségével

Ha a munkaterhelések elsősorban EKS-en futnak (vagy erősen kapcsolódnak az AWS-szolgáltatásokhoz), akkor az AWS Secrets Manager a [Secrets Store CSI Driver-rel] (https://secrets-store-csi-driver.sigs.k8s.io/) párosítva, vagy egy külső Secrets.io/. Titkokat őriz az AWS felügyelt, titkosított, naplózott tárolójában, és szükség esetén bemásolja őket a Kubernetesbe.

A Secrets Store CSI-illesztőprogram (SSCSID) a CNCF által fenntartott megközelítés: a titkok közvetlenül a pod-okba vannak csatolva fájlként egy CSI-köteten keresztül, és soha nem íródnak az etcd-be Kubernetes Secret objektumként. Ez a legmagasabb szintű biztonságú elérési út – a titkok léteznek a pod memóriában, de nem a Kubernetes Secret áruházban.

volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: aws-secrets

Az AWS Secrets Manager natív képességei közé tartozik a támogatott szolgáltatások automatikus rotációja (RDS, Redshift, DocumentDB és Lambda-n keresztül az egyéni rotációhoz), több fiókra kiterjedő hozzáférés és mély CloudTrail integráció a megfelelőségi ellenőrzési nyomvonalak érdekében.

Költségmegfontolás: Az AWS Secrets Manager havi és API-hívásonkénti díjat számít fel. A sok apró titkot tartalmazó nagy flották esetében a költségek összeadódnak. Tekintse meg felhőköltség-optimalizálási útmutatónkat a titkos vonatkozású AWS-költések kezelésével kapcsolatos stratégiákért.

A legjobb: EKS-natív csapatok, akik már befektettek az AWS-ökoszisztémába, akik szoros IAM-integrációt és natív RDS-hitelesítőadat-rotációt szeretnének.

5. Doppler – Fejlesztői első SaaS-titkok platform

A Doppler a SaaS-first megközelítést alkalmazza, amely a fejlesztői tapasztalatot helyezi előtérbe a működési összetettséggel szemben. A titkokat a Doppler felhasználói felületén (vagy CLI/API-n keresztül) határozhatja meg, környezet szerint rendezheti őket (fejlesztő, staging, termelés), és a Doppler Kubernetes operátor automatikusan szinkronizálja őket a Kubernetes Secretsbe.

Az operátor lekérdezi a Doppler-t a módosításokról, és frissíti a megfelelő Kubernetes Secretet, és opcionálisan kiváltja a pod újraindítását, ha a titkok megváltoznak. A beállítás egyetlen Helm chart telepítésből áll:

helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator

Ahol a Doppler ragyog: Helyi fejlesztés és CI/CD integráció a Kubernetes mellett. A Doppler CLI teljes mértékben lecseréli a környezeti fájlokat (“doppler futtatása – az Ön parancsa”), és ugyanazokat a titkokat adja a helyi, CI és éles környezetekben. A CI/CD pipelines esetében a Doppler natív integrációi a GitHub Actions-szel, a CircleCI-vel és másokkal szükségtelenné teszik a titkok átmásolását a folyamat környezeti változóiba.

Amit a Doppler nem fed le: Dinamikus adatbázis hitelesítő adatok. A Doppler egy statikus titoktár verzióelőzményekkel és auditnaplózással – ez nem egy titkos generációs motor, mint a Vault.

Árak: A Doppler ingyenes szintet kínál kis csapatok számára. A fizetős csomagok egyszeri bejelentkezést, hozzáférési kérelmeket és megfelelőségi funkciókat adnak hozzá. Ellenőrizze a [Doppler árképzési oldalát] (https://www.doppler.com/pricing) az aktuális szintekért (az árváltozások; ellenőrizze a költségvetés elkészítése előtt).

6. Infisical – nyílt forráskódú trezor alternatíva

Az Infisical a legerősebb nyílt forráskódú kihívója a Vault/Doppler duopóliumnak. Webes felhasználói felületet, CLI-t, SDK-kat és Kubernetes-operátort biztosít – telepíthető önállóan vagy felhőszolgáltatásként.

Az Infisical hozzáadott dinamikus titkok támogatása 2024-ben, a Vault adatbázis-titkok motorjához hasonlóan az adatbázis hitelesítő adatok generálását célozva. Az Infisical Kubernetes operátor szinkronizálja az InfisicalSecret CRD-ket a natív Kubernetes Secrets-szel, konfigurálható frissítési időközökkel.

Azon csapatok számára, amelyek SaaS-szintű felhasználói élményt (webes irányítópult, hozzáférési kérelmek munkafolyamatai, auditnaplók) szeretnének, de a megfelelőségi követelmények miatt nem tudnak külső SaaS-t használni, az Infisical self-hosted meggyőző. Lényegesen könnyebben kezelhető, mint a Vault, és fejlesztőbarátabb beépítési tapasztalattal rendelkezik.

Árak: A nyílt forráskódú mag ingyenes. A felhőalapú verzió ingyenes szinttel és fizetős csomagokkal rendelkezik a fejlett funkciókhoz. Saját üzemeltetésű vállalati licenc áll rendelkezésre a fokozott megfelelést igénylő környezetekhez.

📚 A Kubernetes biztonsági architektúrájába való mélyebb merüléshez: A Kubernetes Security and Observability az Amazonon egyetlen összefüggő keretben fedi le a titkokat, az RBAC-t, a hálózati szabályzatot és a futásidejű biztonságot.

Végrehajtási tippek

Kezdje a nyugalmi titkosítással. Mielőtt további eszközöket adna hozzá, engedélyezze a Kubernetes etcd titkosítást nyugalmi állapotban. A felügyelt fürtök esetében ez gyakran egyetlen jelölőnégyzet. Az önállóan kezelt fürtök esetében kövesse a [hivatalos útmutatót] (https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Ez azonnal növeli az alapszintű biztonsági testtartást.

A legkevesebb jogosultsággal rendelkező RBAC elfogadása a titkok számára. Vizsgálja meg, hogy mely szolgáltatásfiókok rendelkeznek “get”, “list” vagy “watch” jogosultsággal a titkos objektumokhoz. Az alapértelmezett szolgáltatásfiókok sok Helm-diagramon túl vannak biztosítva. Húzza meg az RBAC-t, mielőtt külső tárolóba helyezné.

** Korán tervezze meg titkos elnevezési konvencióit.** A titkok gyorsan szaporodnak. A következetes hierarchia ({env}/{service}/{credential-type}) drámaian egyszerűbbé teszi az automatizálást, az RBAC-házirendeket és a rotációs munkafolyamatokat minden eszközben.

Ne hagyja ki a titkos forgástesztet. Bármelyik eszközt is választja, futtasson le egy forgásfúrót, mielőtt szüksége lenne rá. Győződjön meg arról, hogy az alkalmazás leállás nélkül veszi fel az új hitelesítő adatokat. A Vault vagy ESO dinamikus titkai ezt jelentősen megkönnyítik, mint a kézzel frissített statikus titkok.

A titkos terjeszkedés figyelése. A platform növekedésével a titkok gyűlnek. Integrálja a titokkezelési jelentéseket a platform tervezési irányítópultjaiba. Tekintse meg a [Kubernetes megfigyelőeszközök útmutatóját] (/posts/best-kubernetes-monitoring-tools-2026/) a megfigyelési eszközökért, amelyek nyomon követhetik a titkos hozzáférési mintákat.

Melyik csapat melyik eszköze?

Kis csapat, felhőnatív (AWS/GCP/Azure): Kezdje azzal, hogy az External Secrets Operator csatlakozik a felhőszolgáltató natív titkos tárolójához. Minimális üzemeltetési költség, szilárd audit integráció, ingyenes.

GitOps-első csapat (Argo CD / Flux): Lezárt titkok a GitOps-ban tárolt konfigurációhoz, ESO-val kombinálva olyan érzékeny futásidejű hitelesítési adatokért, amelyeknek még titkosítva sem kellene lenniük a Gitben.

Vállalkozás megfelelőségi követelményekkel (SOC 2, PCI, HIPAA): HashiCorp Vault – vagy saját üzemeltetésű Raft-fürt vagy HCP Vault felügyelt. Az ellenőrzési naplót, a dinamikus hitelesítő adatokat és a részletes házirend-motort nehéz máshol reprodukálni.

Fejlesztői élményre összpontosító, vegyes környezet (K8s + helyi + CI/CD): Doppler az egyesített DX-hez a különböző környezetekben, vagy Infisical saját üzemeltetésű, ha az adatok tartózkodási helye számít.

Nagy platformcsoport, amely több fürtös környezeteket kezel: External Secrets Operator, mint a K8s-oldali absztrakciós réteg, amelyet a Vault vagy egy felhőalapú áruház támogat. 2026-ban jól bevált minta, hogy az igazság forrását egyetlen üzletben központosítjuk, miközben az ESO-t univerzális adapterként használjuk a klaszterek között.

Kapcsolódó: Az AI kódoló eszközök által a Kubernetes-jegyzékekben és a CI/CD-folyamatokban bevezetett biztonsági kockázatokról tekintse meg a [vibe kódolás biztonsági kockázatai 2026-ban] című útmutatónkat (/posts/vibe-coding-security-risks-2026/).

GYIK

A Kubernetes Secrets alapértelmezés szerint titkosítva van?

Nem. A Kubernetes Secrets alapértelmezés szerint base64-kódolású – kódolás, nem titkosítás. Az adatokat titkosítás nélkül tárolja az etcd, kivéve, ha kifejezetten engedélyezi a titkosítást nyugalmi állapotban. Mindig ellenőrizze a fürt konfigurációját, és fontolja meg a külső titokkezelési eszközöket az éles munkaterhelésekhez.

Mi a különbség a lezárt titkok és a külső titkok kezelője között?

A Sealed Secrets titkosítja a titkos jegyzékeket a biztonságos Git tárolás érdekében – ez egy GitOps megoldás. Az External Secrets Operator lekéri az élő titkokat külső tárolókból (Vault, AWS Secrets Manager stb.), és natív Kubernetes titkokat hoz létre belőlük. Különböző problémákat oldanak meg, és gyakran együtt használják őket.

Mik azok a dinamikus titkok, és miért fontosak?

A dinamikus titkok kérésre generált hitelesítő adatok, automatikus lejárattal – nem pedig korlátlan ideig tárolt statikus jelszavak. A HashiCorp Vault a dinamikus titkok elsődleges forrása a Kubernetes számára. Ha egy dinamikus hitelesítési adat sérül, az a saját ütemezése szerint jár le. Ez drámaian korlátozza a behatolási sugár sugarát a hosszú életű statikus titkokhoz képest.

Dopplert vagy HashiCorp Vault-ot használjam a Kuberneteshez?

A Doppler nyer a fejlesztői tapasztalat és a gyors elfogadás révén. A Vault nyer a vállalati megfelelőség terén – dinamikus hitelesítő adatok, részletes auditnaplók és részletes házirend. Kis és közepes méretű csapatok számára gyakran a Doppler a gyorsabb út. SOC 2, PCI DSS vagy HIPAA környezetben a Vault általában a védhetőbb választás.

Hogyan akadályozhatom meg, hogy a titkok kiszivárogjanak a konténernaplókba?

A titkokat fájlként csatolja, nem pedig környezeti változókként (a környezeti változókat a `/proc’ és a debug végpontokon keresztül lehet megjeleníteni. Használja a Secrets Store CSI Driver-t az etcd teljes megkerüléséhez. Keressen véletlen titkos véglegesítéseket a CI/CD-folyamatban olyan eszközökkel, mint a Trivy titkos szkenner – a beállítás részleteiért lásd a [sebezhetőség-ellenőrző eszközök útmutatóját] (/posts/vulnerability-scanning-tools-devops-2026/).

Mi a legjobb titokkezelő eszköz egy kis Kubernetes csapat számára?

Kezdje az External Secrets Operatorral, amelyet a felhőszolgáltató natív titkos tárolója támogat. Minimális műveleti költség, szilárd ellenőrzési naplózás, ingyenes. Adja hozzá a Doppler ingyenes rétegét, ha egységes fejlesztői/CI/gyártási titkokat szeretne.

Hogyan integrálhatom az AWS Secrets Managert a Kubernetes-szel?

Használja az External Secrets Operatort az AWS Secrets Managerre mutató ClusterSecretStore-al. Az EKS rendszeren használja az IRSA-t (IAM Roles for Service Accounts) a pod-szintű IAM-hitelesítéshez – nincs szükség statikus hitelesítő adatokra. A nem EKS-fürtökön használjon IAM-felhasználót a secretsmanager:GetSecretValue hatókörével az Ön konkrét titkos ARN-jeihez.