Beste Kubernetes Secrets Management Tools in 2026: Vault, ESO, Sealed Secrets en meer

Elk Kubernetes-cluster wordt geleverd met een ingebouwd Secret-object. Het lijkt op veiligheid. Het voelt als veiligheid. Het is geen beveiliging.

Een Kubernetes-geheim is standaard slechts een base64-gecodeerde string opgeslagen in etcd - leesbaar voor iedereen met clustertoegang en triviaal decodeerbaar met een oneliner: echo "c2VjcmV0" | basis64 -d. Tenzij u expliciet versleuteling in rust hebt ingeschakeld (en de meeste teams hebben dat niet gedaan), bevinden uw databasewachtwoorden, API-tokens en persoonlijke TLS-sleutels zich niet-versleuteld in de datastore van het controlevlak van uw cluster. Stuur een Kubernetes-manifest met daarin een ‘Geheim’ naar Git, en die referentie blijft voor altijd in de geschiedenis van je repository bestaan.

Dit is het probleem dat een nieuwe generatie tools voor geheimbeheer moet oplossen – en in 2026 is het ecosysteem aanzienlijk volwassener geworden. Deze handleiding behandelt de zes belangrijkste tools voor het beheren van geheimen in Kubernetes-omgevingen: wat ze doen, wat ze niet doen en welke past bij het volwassenheidsniveau van uw team.

Gerelateerd artikel: Als u zich zorgen maakt over geheimen die via uw CI/CD-pijplijn lekken, bekijk dan ons overzicht van de beste CI/CD-pijplijnhulpmiddelen. Voor een breder beeld van de containerbeveiliging kunt u onze gids voor tools voor het scannen van kwetsbaarheden raadplegen.

Waarom de standaardgeheimen van Kubernetes tekortschieten

Voordat u in de tools duikt, is het de moeite waard om precies te zijn over wat Kubernetes Secrets mist – omdat het begrijpen van de kloof u in staat stelt de juiste oplossing te kiezen.

Standaard geen versleuteling in rust. etcd slaat Kubernetes Secrets op als base64, niet versleuteld. Het inschakelen van Encryption at Rest is een configuratiestap op clusterniveau die beheerde Kubernetes-providers (EKS, GKE, AKE) anders aanpakken, en veel zelfbeheerde clusters slaan deze volledig over.

Geen geheime rotatie. Er is geen ingebouwd mechanisme waarmee een Kubernetes Secret weet dat de back-upreferenties zijn gewijzigd. U roteert een databasewachtwoord extern en uw pods blijven het oude gebruiken totdat u het geheim handmatig bijwerkt en de betrokken pods opnieuw opstart.

Geen auditlogboek voor geheime toegang. Standaard Kubernetes-auditregistratierecords Geheime objectwijzigingen, maar de meeste configuraties registreren geen individuele leesbewerkingen. Dit betekent dat u niet kunt antwoorden: “Welke service heeft toegang gehad tot dit token en wanneer?”

Git is vijandig van opzet. Het standaardadvies is “commiteer nooit geheimen aan Git.” Maar in een GitOps-wereld waar alles-als-code het doel is, is dat een pijnlijke uitzondering om vol te houden.

RBAC als een bot instrument. Met Kubernetes RBAC kunt u toegang verlenen of weigeren tot geheime objecten op naamruimteniveau. Het kan niet uitdrukken: “Service A kan geheim X lezen, maar niet geheim Y”, of “dit geheim vervalt binnen 24 uur.”

Geen van deze redenen zijn redenen om Kubernetes te verlaten; het zijn redenen om er speciale tools voor geheimbeheer bovenop te gebruiken.

TL;DR — Functievergelijking

⚠️ = vereist extra componenten

1. HashiCorp Vault — De gouden standaard voor bedrijfsgeheimen

HashiCorp Vault is de maatstaf waaraan elke andere tool voor geheimbeheer wordt gemeten. Het is al bijna tien jaar op de proef gesteld in bedrijfsomgevingen, en de functieset weerspiegelt die diepgang.

De kernfunctie van Vault bestaat uit dynamische geheimen: inloggegevens die op aanvraag worden gegenereerd en automatisch verlopen. In plaats van een statisch PostgreSQL-wachtwoord op te slaan, genereert Vault een uniek gebruikersnaam/wachtwoord-paar voor elke aanvragende service, geldig voor een configureerbare leaseperiode (bijvoorbeeld één uur). Wanneer de huurovereenkomst afloopt, wordt de identificatie ingetrokken. Dit elimineert hele categorieën van wildgroei aan gegevens en maakt het indammen van inbreuken aanzienlijk eenvoudiger.

Voor Kubernetes zijn de Vault Agent Injector of Vault Secrets Operator de integratiepaden. De injector werkt als een muterende webhook die automatisch een Vault-agent in uw pods plaatst, die zich bij Vault authenticeert met behulp van het Kubernetes-serviceaccount van de pod en geheimen naar een gedeeld geheugenvolume schrijft. De Vault Secrets Operator (VSO), de nieuwere aanpak, synchroniseert Vault-geheimen met native Kubernetes Secret-objecten - vertrouwder voor operators, ten koste van geheimen die kort bestaan ​​in etcd.

De geheime motoren van Vault bestrijken een indrukwekkend bereik:

• Databasereferenties (PostgreSQL, MySQL, MongoDB en meer)
• AWS, GCP, dynamische Azure-referenties
• PKI- en TLS-certificaat genereren
• Ondertekening van SSH-certificaten
• Kubernetes-serviceaccounttokens

Wat Vault goed doet: Dynamische inloggegevens, nauwkeurig toegangsbeleid, een uitgebreid auditlogboek en een volwassen plug-in-ecosysteem. Als u geheimbeheer op compliance-niveau nodig heeft met een volledig spoor van wie-wat-wanneer heeft geopend, is Vault vaak de enige redelijke optie.

Waar u op moet letten: Vault is operationeel complex. Het uitvoeren ervan in de modus met hoge beschikbaarheid vereist zorgvuldige aandacht voor opslagbackends (Raft is nu de aanbevolen keuze), ontgrendelingsprocedures en upgradepaden. De leercurve is reëel. Budget voor platformengineeringtijd.

Prijzen: De open-sourceversie is gratis en dekt de meeste behoeften. HashiCorp Cloud Platform (HCP) Vault is het beheerde aanbod met prijzen gebaseerd op clusteruren en geheime bewerkingen. De BSL-licentiewijziging uit 2023 leidde tot de OpenTofu-fork voor Terraform, maar het fork-equivalent van Vault (OpenBao) is nog steeds in ontwikkeling.

📚 Aanbevolen leesmateriaal: Hacking Kubernetes door Andrew Martin en Michael Hausenblas — uitstekende dekking van Kubernetes-aanvalsoppervlakken, inclusief geheime exfiltratiescenario’s.

2. External Secrets Operator (ESO) — De K8s-native integratielaag

External Secrets Operator neemt een fundamenteel ander architectonisch standpunt in: in plaats van zelf een geheimenopslag te zijn, is het een brug tussen Kubernetes en welke externe opslag dan ook die u al heeft. ESO synchroniseert geheimen van AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler en een groeiende lijst van andere backends met native Kubernetes Secret-objecten.

De kernabstractie is de aangepaste bron 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 houdt deze bron in de gaten, haalt het geheim op uit AWS Secrets Manager (of waar dan ook) en creëert een standaard Kubernetes-geheim. Uw applicatie leest db-creds net als elke andere Kubernetes Secret: er zijn geen codewijzigingen vereist. Wanneer ‘refreshInterval’ aangevinkt is, haalt ESO het geheim automatisch opnieuw op en werkt het bij.

Waarom ESO in 2026 zo populair is: Het past goed bij bestaande investeringen. Uw organisatie beschikt al over AWS Secrets Manager (of Vault of GCP Secret Manager). ESO maakt deze geheimen gewoon beschikbaar in Kubernetes zonder uw applicatiecode of uw bestaande geheime rotatieworkflows te wijzigen.

ESO of Vault Secrets Operator? Als u Vault gebruikt, heeft de VSO een nauwere Vault-specifieke integratie (Vault dynamische geheimen, Vault PKI). Als u zich in de geheime winkel van een cloudprovider bevindt, is ESO de schonere keuze. Veel teams gebruiken beide: ESO voor in de cloud opgeslagen statische geheimen, VSO voor door Vault beheerde dynamische inloggegevens.

Prijzen: ESO is gratis en open source (Apache 2.0), onderhouden door een CNCF-sandboxproject met sterke steun van de gemeenschap.

3. Verzegelde geheimen — GitOps-vriendelijke gecodeerde geheimen

Sealed Secrets van Bitnami lost een specifiek probleem op: hoe bewaar je Kubernetes Secret-manifesten in Git zonder de daadwerkelijke leesbare tekst op te slaan? Het antwoord is asymmetrische encryptie.

De Sealed Secrets-controller draait in uw cluster en bevat een privésleutel. De kubeseal CLI codeert een Kubernetes Secret-manifest met de openbare sleutel van het cluster, waardoor een SealedSecret CRD wordt geproduceerd. Dit versleutelde manifest kan veilig naar Git worden gecommit - alleen de privésleutel van het cluster kan het ontsleutelen, en het kan alleen in dat specifieke cluster worden ontsleuteld (standaard is de cijfertekst gebonden aan naamruimte + naam).

# 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

Wanneer u SealedSecret op het cluster toepast, decodeert de controller het en maakt het overeenkomstige Secret-object aan.

Wat Sealed Secrets goed doet: GitOps-workflows. Als je Argo CD of Flux gebruikt en elke clusterbron (inclusief geheimen) declaratief in Git wilt opslaan, past Sealed Secrets perfect bij dat model. Het vereist geen externe afhankelijkheden buiten de in-clustercontroller.

Wat het niet doet: Rotatie, dynamische inloggegevens of auditlogboekregistratie buiten de standaard Kubernetes-gebeurtenissen. Sealed Secrets is een Git-opslagoplossing, geen volledig platform voor geheimbeheer. Als uw wachtwoord verandert, codeert u opnieuw en legt u opnieuw een commit vast.

Een back-up van de privésleutel is van cruciaal belang. Als u de privésleutel van de controller verliest, verliest u de mogelijkheid om uw verzegelde geheimen te ontsleutelen. Maak een back-up van het ‘verzegelde-geheimen-sleutel’-geheim op een aparte, veilige locatie.

Prijzen: Volledig gratis en open source (Apache 2.0).

4. AWS Secrets Manager met Kubernetes

Als uw werklasten voornamelijk op EKS draaien (of sterk verbonden zijn met AWS-services), is AWS Secrets Manager in combinatie met de Secrets Store CSI Driver of External Secrets Operator een logische keuze. Je bewaart geheimen in de beheerde, gecodeerde, door audits geregistreerde winkel van AWS en haalt ze indien nodig naar Kubernetes.

De Secrets Store CSI Driver (SSCSID) is de door CNCF onderhouden aanpak: geheimen worden via een CSI-volume rechtstreeks in pods als bestanden gemonteerd en nooit naar etcd geschreven als Kubernetes Secret-objecten. Dit is het pad met de hoogste beveiliging: geheimen bestaan ​​in het podgeheugen, maar niet in de Kubernetes Secret Store.

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

De native mogelijkheden van AWS Secrets Manager omvatten automatische rotatie voor ondersteunde services (RDS, Redshift, DocumentDB en via Lambda voor aangepaste rotatie), toegang tot meerdere accounts en diepgaande CloudTrail-integratie voor compliance-audittrajecten.

Kostenoverweging: AWS Secrets Manager brengt kosten in rekening per geheim per maand en per API-aanroep. Voor grote wagenparken met veel kleine geheimen kunnen de kosten oplopen. Zie onze gids voor cloudkostenoptimalisatie voor strategieën voor het beheren van geheimgerelateerde AWS-uitgaven.

Best voor: EKS-native teams die al in het AWS-ecosysteem hebben geïnvesteerd en een nauwe IAM-integratie en native RDS-referentieroulatie willen.

5. Doppler: het eerste SaaS-geheimplatform voor ontwikkelaars

Doppler hanteert een SaaS-first-aanpak waarbij de ervaring van ontwikkelaars prioriteit krijgt boven operationele complexiteit. U definieert geheimen in de gebruikersinterface van Doppler (of via CLI/API), ordent ze per omgeving (ontwikkelaar, staging, productie) en de Doppler Kubernetes-operator synchroniseert ze automatisch met Kubernetes Secrets.

De operator vraagt ​​Doppler naar wijzigingen en werkt het overeenkomstige Kubernetes-geheim bij, waarbij optioneel het opnieuw opstarten van de pod wordt geactiveerd wanneer geheimen veranderen. De installatie is een installatie met één Helm-diagram:

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

Waar Doppler uitblinkt: Lokale ontwikkeling en CI/CD-integratie naast Kubernetes. De Doppler CLI vervangt omgevingsbestanden volledig (doppler run -- your-command), waardoor dezelfde geheimen worden gegeven in lokale, CI- en productieomgevingen. Voor CI/CD pipelines elimineren de native integraties van Doppler met GitHub Actions, CircleCI en anderen de noodzaak om geheimen naar pipeline-omgevingsvariabelen te kopiëren.

Wat Doppler niet dekt: Dynamische databasereferenties. Doppler is een statische geheimenopslag met versiegeschiedenis en auditregistratie. Het is geen engine voor het genereren van geheimen zoals Vault.

Prijzen: Doppler biedt een gratis niveau voor kleine teams. Betaalde abonnementen voegen SSO, toegangsverzoeken en compliance-functies toe. Kijk op de Prijspagina van Doppler voor de huidige niveaus (prijswijzigingen; verifieer vóór budgettering).

6. Infisical - Open-source kluisalternatief

Infisical is de sterkste open-source uitdager van het Vault/Doppler-duopolie. Het biedt een web-UI, CLI, SDK’s en een Kubernetes-operator, die door uzelf kan worden gehost of als cloudservice kan worden gebruikt.

Infisical heeft in 2024 ondersteuning voor dynamische geheimen toegevoegd, gericht op het genereren van databasegegevens, vergelijkbaar met de databasegeheimenengine van Vault. De Infisical Kubernetes-operator synchroniseert InfisicalSecret CRD’s met native Kubernetes Secrets, met configureerbare vernieuwingsintervallen.

Voor teams die UX op SaaS-niveau willen (webdashboard, workflows voor toegangsaanvragen, auditlogboeken) maar geen externe SaaS kunnen gebruiken vanwege compliance-eisen, is Infisical zelf-hosted aantrekkelijk. Het is aanzienlijk eenvoudiger te gebruiken dan Vault en heeft een ontwikkelaarsvriendelijkere onboarding-ervaring.

Prijzen: Open-source kern is gratis. De in de cloud gehoste versie heeft een gratis laag en betaalde abonnementen voor geavanceerde functies. Er is een zelf-gehoste ondernemingslicentie beschikbaar voor omgevingen met veel compliance.

📚 Voor een diepere duik in de Kubernetes-beveiligingsarchitectuur: Kubernetes Security and Observability op Amazon behandelt geheimen, RBAC, netwerkbeleid en runtime-beveiliging in één samenhangend raamwerk.

Implementatietips

Begin met versleuteling in rust. Voordat u extra tools toevoegt, schakelt u Kubernetes etcd-versleuteling in rust in. Voor beheerde clusters is dit vaak één selectievakje. Voor zelfbeheerde clusters volgt u de officiële handleiding. Dit verhoogt onmiddellijk uw basisveiligheidshouding.

Gebruik RBAC met de minste rechten voor geheimen. Controleer welke serviceaccounts de machtigingen ‘get’, ’list’ of ‘watch’ hebben voor geheime objecten. Standaardserviceaccounts in veel Helm-grafieken zijn overbezet. Draai de RBAC vast voordat u deze naar een externe opslagplaats draait.

Plan uw geheime naamgevingsconventies vroeg. Geheimen verspreiden zich snel. Een consistente hiërarchie ({env}/{service}/{credential-type}) maakt automatisering, RBAC-beleid en rotatieworkflows dramatisch eenvoudiger voor alle tools.

Sla de geheime rotatietests niet over. Welke tool u ook kiest, voer een rotatieoefening uit voordat u deze nodig heeft. Controleer of uw toepassing zonder downtime nieuwe referenties ophaalt. Dynamische geheimen met Vault of ESO maken dit aanzienlijk eenvoudiger dan handmatig bijgewerkte statische geheimen.

Controleer op geheime wildgroei. Naarmate uw platform groeit, stapelen geheimen zich op. Integreer rapportage over geheimenbeheer in uw platformengineeringdashboards. Zie onze Kubernetes monitoring tools guide voor observatietools die geheime toegangspatronen kunnen volgen.

Welke tool voor welk team?

Klein team, cloud-native (AWS/GCP/Azure): Begin met External Secrets Operator die verbinding maakt met de eigen geheime opslag van uw cloudprovider. Minimale operationele overhead, solide auditintegratie, gratis.

GitOps-first team (Argo CD / Flux): Verzegelde geheimen voor in GitOps opgeslagen configuratie, gecombineerd met ESO voor gevoelige runtime-referenties die niet in Git zouden moeten staan, zelfs niet gecodeerd.

Onderneming met nalevingsvereisten (SOC 2, PCI, HIPAA): HashiCorp Vault – zelfgehoste Raft-cluster of beheerd door HCP Vault. Het auditlogboek, de dynamische inloggegevens en de verfijnde beleidsengine zijn moeilijk elders te repliceren.

Op ontwikkelaarservaring gerichte, gemengde omgeving (K8s + lokaal + CI/CD): Doppler voor de uniforme DX in alle omgevingen, of Infisical zelf-gehost als datalocatie belangrijk is.

Groot platformteam dat omgevingen met meerdere clusters beheert: External Secrets Operator als de abstractielaag aan de K8s-zijde, ondersteund door Vault of een cloud-native store. Het centraliseren van de bron van de waarheid in één winkel en het gebruik van ESO als universele adapter tussen clusters is een beproefd patroon in 2026.

Gerelateerd: Voor de beveiligingsrisico’s die door AI-coderingstools in uw Kubernetes-manifesten en CI/CD-pijplijnen worden geïntroduceerd, raadpleegt u onze handleiding over vibe coding security risico’s in 2026.

Veelgestelde vragen

Worden Kubernetes Secrets standaard gecodeerd?

Nee. Kubernetes Secrets zijn standaard base64-gecodeerd: codering, geen codering. De gegevens worden zonder codering opgeslagen in etcd, tenzij u Encryption at Rest expliciet inschakelt. Controleer altijd uw clusterconfiguratie en overweeg externe hulpprogramma’s voor geheimbeheer voor productieworkloads.

Wat is het verschil tussen Sealed Secrets en External Secrets Operator?

Sealed Secrets codeert geheime manifesten voor veilige Git-opslag: het is een GitOps-oplossing. External Secrets Operator haalt live geheimen op uit externe winkels (Vault, AWS Secrets Manager, enz.) en creëert er native Kubernetes Secrets van. Ze lossen verschillende problemen op en worden vaak samen gebruikt.

Wat zijn dynamische geheimen en waarom zijn ze belangrijk?

Dynamische geheimen zijn inloggegevens die op aanvraag worden gegenereerd en automatisch verlopen, in plaats van statische wachtwoorden die voor onbepaalde tijd worden opgeslagen. HashiCorp Vault is de belangrijkste bron van dynamische geheimen voor Kubernetes. Als een dynamische referentie in gevaar komt, verloopt deze volgens zijn eigen schema. Dit beperkt de straal van de explosie dramatisch in vergelijking met langlevende statische geheimen.

Moet ik Doppler of HashiCorp Vault gebruiken voor Kubernetes?

Doppler wint op het gebied van ontwikkelaarservaring en snelle acceptatie. Vault wint op het gebied van compliance op ondernemingsniveau: dynamische inloggegevens, gedetailleerde auditlogboeken en verfijnd beleid. Voor kleine tot middelgrote teams is Doppler vaak de snelste weg. Voor SOC 2-, PCI DSS- of HIPAA-omgevingen is Vault doorgaans de beter verdedigbare keuze.

Hoe voorkom ik dat geheimen in containerlogboeken lekken?

Mount geheimen als bestanden in plaats van omgevingsvariabelen (omgevingsvariabelen kunnen zichtbaar worden gemaakt via /proc en debug-eindpunten). Gebruik het Secrets Store CSI-stuurprogramma om etcd volledig te omzeilen. Scan op onbedoelde geheime commits in uw CI/CD-pijplijn met tools zoals de geheime scanner van Trivy. Zie onze handleiding voor het scannen van kwetsbaarheden voor installatiedetails.

Wat is de beste tool voor geheimbeheer voor een klein Kubernetes-team?

Begin met External Secrets Operator, ondersteund door de eigen geheime opslag van uw cloudprovider. Minimale operationele overhead, solide auditregistratie, gratis. Voeg de gratis laag van Doppler toe als u ook een uniforme ervaring met dev/CI/productiegeheimen wilt.

Hoe integreer ik AWS Secrets Manager met Kubernetes?

Gebruik de External Secrets Operator met een ClusterSecretStore die naar AWS Secrets Manager wijst. Gebruik op EKS IRSA (IAM Roles for Service Accounts) voor IAM-authenticatie op podniveau: er zijn geen statische referenties nodig. Gebruik op niet-EKS-clusters een IAM-gebruiker met secretsmanager:GetSecretValue gericht op uw specifieke geheime ARN’s.