Nejlepší nástroje pro správu Kubernetes Secrets v roce 2026: Vault, ESO, Sealed Secrets a další

Každý cluster Kubernetes se dodává s vestavěným objektem Secret. Vypadá to na bezpečnost. Připadá mi to jako bezpečí. To není bezpečnost.

Tajemství Kubernetes je ve výchozím nastavení pouze řetězec zakódovaný v base64 uložený v etcd – čitelný pro kohokoli s přístupem ke clusteru a triviálně dekódovatelný pomocí jednoho řádku: `echo “c2VjcmV0” | základ 64 -d’. Pokud jste explicitně nepovolili šifrování v klidu (a většina týmů to neudělala), vaše databázová hesla, tokeny API a soukromé klíče TLS jsou nezašifrované v datovém úložišti řídicí roviny vašeho clusteru. Odešlete manifest Kubernetes obsahující „tajemství“ Gitu a toto pověření zůstane navždy v historii vašeho úložiště.

Toto je problém, který se objevila nová generace nástrojů pro správu tajemství – a v roce 2026 ekosystém výrazně dozrál. Tato příručka pokrývá šest nejdůležitějších nástrojů pro správu tajemství v prostředích Kubernetes: co dělají, co nedělají a který z nich odpovídá úrovni vyspělosti vašeho týmu.

Související čtení: Pokud máte obavy z úniku tajemství prostřednictvím vašeho kanálu CI/CD, podívejte se na náš souhrn nejlepších nástrojů pro potrubí CI/CD. Chcete-li získat širší obrázek o zabezpečení kontejneru, podívejte se na našeho průvodce nástroji pro skenování zranitelnosti.

Proč chybí výchozí tajemství Kubernetes

Než se ponoříte do nástrojů, stojí za to upřesnit, co Kubernetes Secrets postrádá – protože pochopení mezery vám umožní vybrat správné řešení.

Ve výchozím nastavení žádné šifrování v klidu. etcd ukládá Kubernetes Secrets jako base64, nešifrované. Povolení Encryption at Rest je krok konfigurace na úrovni clusteru, který spravovaní poskytovatelé Kubernetes (EKS, GKE, AKE) zpracovávají odlišně a mnoho samospravovaných clusterů jej zcela vynechává.

Žádné tajné střídání. Neexistuje žádný vestavěný mechanismus, pomocí kterého by tajný klíč Kubernetes věděl, že se jeho přihlašovací údaje změnily. Externě otočíte heslo databáze a vaše moduly budou nadále používat to staré, dokud ručně neaktualizujete tajemství a nerestartujete dotčené moduly.

Žádný protokol auditu pro tajný přístup. Standardní záznamy protokolování auditu Kubernetes Úpravy tajných objektů, ale většina konfigurací nezaznamenává jednotlivá čtení – což znamená, že nemůžete odpovědět, „která služba přistupovala k tomuto tokenu a kdy?“

Git-nepřátelský design. Standardní rada je “nikdy nesvěřujte tajemství Gitu.” Ale ve světě GitOps, kde je cílem vše jako kód, je to bolestná výjimka, kterou je třeba udržovat.

RBAC jako neomalený nástroj. Kubernetes RBAC vám umožňuje udělit nebo zakázat přístup k tajným objektům na úrovni jmenného prostoru. Nemůže vyjádřit „Služba A může číst tajné X, ale ne tajné Y“ nebo „tento tajný klíč vyprší za 24 hodin“.

Žádný z těchto důvodů není důvodem k opuštění Kubernetes – jsou to důvody, proč k tomu použít vyhrazené nástroje pro správu tajemství.

TL;DR — Porovnání funkcí

⚠️ = vyžaduje další komponenty

1. HashiCorp Vault — Zlatý standard pro podniková tajemství

HashiCorp Vault je měřítkem, se kterým se poměřují všechny ostatní nástroje pro správu tajemství. Téměř deset let byl testován v podnikových prostředích a jeho sada funkcí tuto hloubku odráží.

Základní schopností Vaultu jsou dynamická tajemství – přihlašovací údaje, které se generují na vyžádání a automaticky vyprší. Namísto ukládání statického hesla PostgreSQL generuje Vault jedinečný pár uživatelské jméno/heslo pro každou službu, která požaduje, platný po dobu konfigurovatelného zapůjčení (např. jednu hodinu). Když nájem vyprší, pověření je zrušeno. To eliminuje celé třídy rozšiřování pověření a výrazně usnadňuje zadržování porušení.

Pro Kubernetes jsou integračními cestami Vault Agent Injector nebo Vault Secrets Operator. Injektor běží jako mutující webhook, který automaticky připojí agenta Vaultu do vašich modulů, který se ověřuje k Vaultu pomocí účtu služby Kubernetes modulu a zapisuje tajné informace do sdíleného svazku v paměti. Novější přístup Operátor Vault Secrets Operator (VSO) synchronizuje tajné klíče Vault do nativních objektů Kubernetes Secret – operátorům známější, za cenu tajných klíčů, které krátce existují v etcd.

Tajné motory Vault pokrývají působivý rozsah:

• Databázové přihlašovací údaje (PostgreSQL, MySQL, MongoDB a další)
• AWS, GCP, dynamické přihlašovací údaje Azure
• Generování certifikátů PKI a TLS
• Podepisování certifikátů SSH
• Tokeny servisního účtu Kubernetes

Co Vault dělá dobře: Dynamické přihlašovací údaje, jemné zásady přístupu, komplexní protokol auditu a vyspělý ekosystém pluginů. Pokud potřebujete správu tajemství na úrovni shody s úplnými informacemi o tom, kdo-co-kdy přistupoval, Vault je často jedinou rozumnou možností.

Na co si dát pozor: Vault má provozní složitost. Spuštění v režimu vysoké dostupnosti vyžaduje pečlivou pozornost backendům úložiště (doporučenou volbou je nyní Raft), procedurám odpečetění a cestám upgradu. Křivka učení je skutečná. Rozpočet na dobu vývoje platformy.

Cena: Verze s otevřeným zdrojovým kódem je zdarma a pokrývá většinu potřeb. HashiCorp Cloud Platform (HCP) Vault je spravovaná nabídka s cenou založenou na hodinách clusteru a tajných operacích. Změna licence BSL z roku 2023 vedla k vidlici OpenTofu pro Terraform, ale ekvivalent vidlice Vaultu (OpenBao) stále dozrává.

📚 Doporučená literatura: Hacking Kubernetes od Andrewa Martina a Michaela Hausenblase – vynikající pokrytí povrchů útoků Kubernetes včetně scénářů tajné exfiltrace.

2. External Secrets Operator (ESO) – nativní integrační vrstva K8s

External Secrets Operator zaujímá zásadně odlišný architektonický postoj: spíše než samotný tajný obchod, je to most mezi Kubernetes a jakýmkoli externím obchodem, který již máte. ESO synchronizuje tajné klíče z AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler a rostoucího seznamu dalších backendů do nativních objektů Kubernetes Secret.

Jádrem abstrakce je vlastní zdroj „ExternalSecret“:

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

ESO sleduje tento zdroj, načte tajemství z AWS Secrets Manager (nebo kdekoli) a vytvoří standardní Kubernetes Secret. Vaše aplikace čte db-creds stejně jako jakýkoli jiný Kubernetes Secret – není třeba měnit kód. Když zaškrtne refreshInterval, ESO automaticky znovu načte a aktualizuje tajemství.

Proč je ESO v roce 2026 tak populární: Hraje dobře se stávajícími investicemi. Vaše organizace již má správce AWS Secrets Manager (nebo Vault, nebo GCP Secret Manager) – ESO pouze umožňuje použití těchto tajemství v Kubernetes bez změny kódu vaší aplikace nebo vašich stávajících pracovních postupů rotace tajných informací.

Operátor ESO nebo Vault Secrets? Pokud používáte Vault, VSO má těsnější integraci specifickou pro Vault (dynamická tajemství Vaultu, Vault PKI). Pokud používáte nativní tajný obchod poskytovatele cloudu, ESO je čistší volbou. Mnoho týmů provozuje obojí – ESO pro statická tajemství uložená v cloudu, VSO pro dynamické přihlašovací údaje spravované službou Vault.

Cena: ESO je bezplatný a otevřený zdroj (Apache 2.0), spravovaný sandboxovým projektem CNCF se silnou komunitou.

3. Zapečetěná tajemství — GitOps-Friendly Encrypted Secrets

Sealed Secrets od Bitnami řeší konkrétní problém: jak ukládáte manifesty Kubernetes Secret v Gitu, aniž byste ukládali skutečný prostý text? Odpovědí je asymetrické šifrování.

Ovladač Sealed Secrets běží ve vašem clusteru a má soukromý klíč. CLI kubeseal zašifruje manifest Kubernetes Secret veřejným klíčem clusteru a vytvoří CRD SealedSecret. Tento zašifrovaný manifest lze bezpečně odevzdat Gitu – dešifrovat jej může pouze soukromý klíč clusteru a lze jej dešifrovat pouze v tomto konkrétním clusteru (ve výchozím nastavení je šifrovaný text vázán na jmenný prostor + jméno).

# 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

Když použijete SealedSecret na cluster, řadič jej dešifruje a vytvoří odpovídající objekt Secret.

Co dělá Sealed Secrets dobře: Pracovní postupy GitOps. Pokud používáte Argo CD nebo Flux a chcete, aby každý prostředek clusteru (včetně tajemství) byl deklarativně uložen v Gitu, Sealed Secrets tomuto modelu dokonale vyhovuje. Vyžaduje nulové externí závislosti mimo řadič v clusteru.

Co nedělá: Rotace, dynamické přihlašovací údaje nebo protokolování auditu nad rámec standardních událostí Kubernetes. Sealed Secrets je řešení úložiště Git, nikoli platforma pro správu úplných tajemství. Pokud se vaše heslo změní, znovu zašifrujete a znovu potvrdíte.

Záloha soukromého klíče je kritická. Pokud ztratíte soukromý klíč ovladače, ztratíte možnost dešifrovat svá zapečetěná tajemství. Zálohujte tajný klíč sealed-secrets-key na samostatné, zabezpečené místo.

Cena: Plně zdarma a open source (Apache 2.0).

4. Správce tajemství AWS s Kubernetes

Pokud vaše úlohy běží primárně na EKS (nebo se intenzivně připojují ke službám AWS), AWS Secrets Manager spárovaný s Secrets Store CSI Driver nebo External Secrets Operator je přirozeně vhodný. Uchováváte tajemství ve spravovaném, šifrovaném a auditovaném úložišti AWS a v případě potřeby je stahujete do Kubernetes.

Ovladač Secret Store CSI Driver (SSCSID) je přístup udržovaný CNCF: tajné informace se připojují přímo do podů jako soubory prostřednictvím svazku CSI, nikdy se nezapisují do etcd jako objekty Kubernetes Secret. Toto je cesta s nejvyšším zabezpečením – tajemství existují v paměti modulu, ale ne v úložišti Kubernetes Secret.

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

Mezi nativní funkce AWS Secrets Manager patří automatická rotace pro podporované služby (RDS, Redshift, DocumentDB a via Lambda pro vlastní rotaci), přístup mezi účty a hluboká integrace CloudTrail pro kontrolní záznamy shody.

Úvaha o nákladech: Poplatky AWS Secrets Manager za tajný klíč za měsíc a za volání API. U velkých flotil s mnoha malými tajemstvími se náklady mohou sčítat. Nahlédněte do našeho průvodce optimalizací nákladů na cloud, kde najdete strategie pro správu výdajů AWS souvisejících s tajnými službami.

Nejlepší pro: Nativní týmy EKS již investovaly do ekosystému AWS a chtějí těsnou integraci IAM a nativní rotaci pověření RDS.

5. Doppler — První vývojář SaaS Secrets Platform

Doppler využívá SaaS-first přístup, který upřednostňuje vývojářské zkušenosti před provozní složitostí. Tajné klíče definujete v uživatelském rozhraní Dopplera (nebo prostřednictvím rozhraní CLI/API), uspořádáte je podle prostředí (vývoj, příprava, produkce) a operátor Doppler Kubernetes je automaticky synchronizuje do tajných klíčů Kubernetes.

Operátor požádá Dopplera o změny a aktualizuje odpovídající tajný klíč Kubernetes, volitelně spouští restartování modulu, když se tajné klíče změní. Nastavení je jediná instalace grafu Helm:

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

Tam, kde Doppler září: Lokální vývoj a integrace CI/CD spolu s Kubernetes. Doppler CLI zcela nahrazuje soubory prostředí (doppler run -- your-command), čímž poskytuje stejná tajemství v lokálních, CI a produkčních prostředích. Pro CI/CD kanály nativní integrace Dopplera s GitHub Actions, CircleCI a dalšími eliminují potřebu kopírovat tajné klíče do proměnných prostředí kanálu.

Co Doppler nepokrývá: Pověření k dynamické databázi. Doppler je statický tajný obchod s historií verzí a protokolováním auditu – není to engine generující tajemství jako Vault.

Cena: Doppler nabízí bezplatnou úroveň pro malé týmy. Placené plány přidávají funkce jednotného přihlášení, požadavky na přístup a dodržování předpisů. Aktuální úrovně (změny cen, ověřte před sestavováním rozpočtu) naleznete na stránce cen Dopplera.

6. Infisical — Alternativa úložiště s otevřeným zdrojem

Infisical je nejsilnější open-source vyzyvatel duopolu Vault/Doppler. Poskytuje webové uživatelské rozhraní, rozhraní příkazového řádku, sady SDK a operátora Kubernetes – nasaditelný samostatně hostovaný nebo spotřebovaný jako cloudová služba.

Společnost Infisical přidala v roce 2024 podporu dynamických tajných klíčů se zaměřením na generování přihlašovacích údajů k databázi, která je podobná modulu tajných informací databáze Vault. Operátor Infisical Kubernetes synchronizuje InfisicalSecret CRD s nativními Kubernetes Secrets s konfigurovatelnými intervaly obnovování.

Pro týmy, které chtějí UX na úrovni SaaS (webový panel, pracovní postupy žádostí o přístup, protokoly auditu), ale nemohou používat externí SaaS kvůli požadavkům na dodržování předpisů, je samohostování Infisical přesvědčivé. Je výrazně jednodušší na ovládání než ve Vaultu a má pro vývojáře přívětivější integraci.

Cena: Open source jádro je zdarma. Verze hostovaná v cloudu má bezplatnou úroveň a placené plány pro pokročilé funkce. Samoobslužná podniková licence je k dispozici pro prostředí vyžadující dodržování předpisů.

📚 Pro hlubší ponor do architektury zabezpečení Kubernetes: Zabezpečení a pozorování Kubernetes na Amazonu pokrývá tajemství, RBAC, síťové zásady a zabezpečení za běhu v jednom soudržném rámci.

Tipy pro implementaci

Začněte s šifrováním v klidu. Před přidáním dalších nástrojů povolte šifrování Kubernetes etcd v klidu. U spravovaných clusterů se často jedná o jediné zaškrtávací políčko. V případě clusterů s vlastní správou postupujte podle oficiálního průvodce. To okamžitě zvýší vaši základní bezpečnostní pozici.

Přijměte RBAC s nejméně privilegiem pro Secrets. Auditujte, které servisní účty mají oprávnění get, list nebo watch u tajných objektů. Výchozí servisní účty v mnoha grafech Helm jsou nadměrně zajištěny. Před otočením do externího úložiště utáhněte RBAC.

Naplánujte si své tajné konvence pojmenování včas. Tajemství se rychle množí. Konzistentní hierarchie ({env}/{service}/{credential-type}) výrazně zjednodušuje automatizaci, zásady RBAC a rotaci ve všech nástrojích.

Nepřeskakujte tajné testování rotace. Ať už zvolíte kterýkoli nástroj, spusťte rotační vrták, než jej budete potřebovat. Ověřte, že vaše aplikace získává nová pověření bez prostojů. Dynamické tajné klíče s Vault nebo ESO to výrazně usnadňují než ručně aktualizované statické tajné klíče.

Sledování tajného rozrůstání. Jak se vaše platforma rozrůstá, hromadí se tajemství. Integrujte hlášení správy tajemství do svých řídicích panelů platformy. V našem průvodci nástroji pro monitorování Kubernetes najdete nástroje pro sledování, které mohou sledovat vzory tajného přístupu.

Jaký nástroj pro který tým?

Malý tým, cloud-native (AWS/GCP/Azure): Začněte s externím tajným operátorem, který se připojí k nativnímu tajnému úložišti vašeho cloudového poskytovatele. Minimální provozní režie, solidní integrace auditu, zdarma.

První tým GitOps (Argo CD / Flux): Zapečetěná tajemství pro konfiguraci uloženou v GitOps v kombinaci s ESO pro citlivé runtime přihlašovací údaje, které by v Gitu neměly být ani šifrované.

Podnik s požadavky na shodu (SOC 2, PCI, HIPAA): HashiCorp Vault – buď samostatně hostovaný cluster Raft, nebo spravovaný HCP Vault. Protokol auditu, dynamická pověření a jemnozrnný modul zásad je těžké jinde replikovat.

Smíšené prostředí zaměřené na vývojářské zkušenosti (K8s + místní + CI/CD): Doppler pro sjednocené DX napříč prostředími, nebo Infisical self-hosted, pokud záleží na umístění dat.

Velký tým platforem spravující prostředí s více clustery: Operátor externích tajemství jako abstrakční vrstva na straně K8, podporovaná Vaultem nebo cloudovým nativním úložištěm. Centralizace zdroje pravdy v jednom obchodě při používání ESO jako univerzálního adaptéru napříč clustery je v roce 2026 dobře osvědčený vzor.

Související: Bezpečnostní rizika zaváděná nástroji pro kódování AI do vašich manifestů Kubernetes a kanálů CI/CD najdete v našem průvodci [bezpečnostní rizika kódování vibrací v roce 2026] (/posts/vibe-coding-security-risks-2026/).

Nejčastější dotazy

Jsou tajemství Kubernetes ve výchozím nastavení šifrována?

Ne. Tajemství Kubernetes jsou ve výchozím nastavení kódována pomocí base64 – kódování, nikoli šifrování. Data jsou uložena v etcd bez šifrování, pokud výslovně nepovolíte šifrování v klidu. Vždy ověřte konfiguraci clusteru a zvažte externí nástroje pro správu tajných klíčů pro produkční úlohy.

Jaký je rozdíl mezi Sealed Secrets a External Secrets Operator?

Sealed Secrets šifruje tajné manifesty pro bezpečné úložiště Git – je to řešení GitOps. Operátor externích tajemství stahuje živá tajemství z externích úložišť (Vault, AWS Secrets Manager atd.) a vytváří z nich nativní tajemství Kubernetes. Řeší různé problémy a často se používají společně.

Co jsou dynamická tajemství a proč na nich záleží?

Dynamická tajemství jsou přihlašovací údaje generované na vyžádání s automatickým vypršením – spíše než statická hesla uložená na dobu neurčitou. HashiCorp Vault je primárním zdrojem dynamických tajemství pro Kubernetes. Pokud dojde ke kompromitaci dynamického pověření, jeho platnost vyprší podle vlastního plánu. To dramaticky omezuje poloměr výbuchu ve srovnání s dlouhotrvajícími statickými tajemstvími.

Mám používat Doppler nebo HashiCorp Vault pro Kubernetes?

Doppler vyhrává díky zkušenostem vývojářů a rychlému přijetí. Vault vítězí na dodržování podnikových předpisů – dynamické přihlašovací údaje, podrobné protokoly auditu a podrobná pravidla. Pro malé až středně velké týmy je Doppler často rychlejší cestou. Pro prostředí SOC 2, PCI DSS nebo HIPAA je Vault obvykle obhajitelnější volbou.

Jak zabráním úniku tajných informací do protokolů kontejneru?

Připojujte tajné klíče jako soubory, nikoli jako proměnné prostředí (proměnné prostředí lze zpřístupnit pomocí /proc a ladit koncové body). K úplnému vynechání etcd použijte ovladač CSI Secrets Store. Vyhledejte ve svém kanálu CI/CD náhodná tajná potvrzení pomocí nástrojů, jako je tajný skener Trivy – podrobnosti o nastavení najdete v našem průvodci nástroji pro skenování zranitelnosti.

Jaký je nejlepší nástroj pro správu tajemství pro malý tým Kubernetes?

Začněte s operátorem External Secrets Operator podporovaným nativním tajným úložištěm vašeho poskytovatele cloudu. Minimální provozní režie, solidní protokolování auditu, zdarma. Přidejte Dopplerovu bezplatnou úroveň, pokud chcete také sjednocený zážitek z dev/CI/produkčních tajemství.

Jak integruji AWS Secrets Manager s Kubernetes?

Použijte External Secrets Operator s ClusterSecretStore směřujícím na AWS Secrets Manager. Na EKS použijte IRSA (IAM Roles for Service Accounts) pro ověřování IAM na úrovni pod – nejsou potřeba žádné statické přihlašovací údaje. V clusterech bez EKS použijte uživatele IAM s secretsmanager:GetSecretValue v rozsahu pro vaše konkrétní tajná ARN.