Bedste Kubernetes Secrets Management Tools i 2026: Vault, ESO, Sealed Secrets & More

Hver Kubernetes-klynge leveres med et indbygget “Hemmeligt”-objekt. Det ligner sikkerhed. Det føles som tryghed. Det er ikke sikkerhed.

En Kubernetes Secret er som standard kun en base64-kodet streng gemt i etcd — læsbar af alle med klyngeadgang og trivielt afkodelig med en one-liner: echo "c2VjcmV0" | base64 -d. Medmindre du udtrykkeligt har aktiveret kryptering i hvile (og de fleste hold har ikke), sidder dine databaseadgangskoder, API-tokens og TLS private nøgler ukrypteret i din klynges kontrolplans datalager. Indgiv et Kubernetes-manifest, der indeholder en ‘Hemmelighed’ til Git, og den legitimation lever for evigt i dit depots historie.

Dette er problemet, som en ny generation af hemmelighedshåndteringsværktøjer er dukket op for at løse - og i 2026 er økosystemet modnet betydeligt. Denne guide dækker de seks vigtigste værktøjer til at administrere hemmeligheder i Kubernetes-miljøer: hvad de gør, hvad de ikke gør, og hvilket der passer til dit teams modenhedsniveau.

Relateret læsning: Hvis du er bekymret for hemmeligheder, der lækker gennem din CI/CD-pipeline, kan du se vores opsummering af bedste CI/CD-pipeline-værktøjer. For det bredere containersikkerhedsbillede, tjek vores vejledning til sårbarhedsscanningsværktøjer.

Hvorfor Kubernetes standardhemmeligheder kommer til kort

Før du dykker ned i værktøjer, er det værd at være præcis om, hvad Kubernetes Secrets mangler - fordi forståelsen af ​​hullet er det, der lader dig vælge den rigtige løsning.

Ingen kryptering i hvile som standard. etcd gemmer Kubernetes Secrets som base64, ikke krypteret. Aktivering af Encryption at Rest er et konfigurationstrin på klyngeniveau, som administrerede Kubernetes-udbydere (EKS, GKE, AKE) håndterer anderledes, og mange selvadministrerede klynger springer det helt over.

Ingen hemmelig rotation. Der er ingen indbygget mekanisme for en Kubernetes Secret at vide, at dens opbakningsoplysninger er ændret. Du roterer en databaseadgangskode eksternt, og dine pods bliver ved med at bruge den gamle, indtil du manuelt opdaterer hemmeligheden og genstarter de berørte pods.

Ingen revisionslog for hemmelig adgang. Standard Kubernetes revisionslogføringsposter Hemmelige objektændringer, men de fleste konfigurationer logger ikke individuelle læsninger - hvilket betyder, at du ikke kan svare “hvilken tjeneste fik adgang til dette token og hvornår?”

Git-fjendtlig af design. Standardrådet er “forpligt aldrig hemmeligheder til Git.” Men i en GitOps-verden, hvor alt-som-kode er målet, er det en smertefuld undtagelse at opretholde.

RBAC som et stumpt instrument. Kubernetes RBAC giver dig mulighed for at give eller nægte adgang til hemmelige objekter på navnerumsniveau. Det kan ikke udtrykke “Service A kan læse hemmeligt X, men ikke hemmeligt Y”, eller “denne hemmelighed udløber om 24 timer.”

Ingen af ​​disse er grunde til at opgive Kubernetes - de er grunde til at bruge dedikerede hemmelighedsstyringsværktøjer oven i det.

TL;DR — Funktionssammenligning

⚠️ = kræver yderligere komponenter

1. HashiCorp Vault — Guldstandarden for virksomhedshemmeligheder

HashiCorp Vault er det benchmark, som hvert andet hemmelighedsstyringsværktøj bliver målt mod. Den er blevet kamptestet i virksomhedsmiljøer i næsten et årti, og dens funktionssæt afspejler denne dybde.

Vaults kerneegenskab er dynamiske hemmeligheder — legitimationsoplysninger, der genereres on-demand og udløber automatisk. I stedet for at gemme en statisk PostgreSQL-adgangskode, genererer Vault et unikt brugernavn/adgangskodepar for hver anmodende tjeneste, gyldigt i en konfigurerbar lejeperiode (f.eks. en time). Når lejekontrakten udløber, tilbagekaldes legitimationen. Dette eliminerer hele klasser af credential sprawl og gør indeslutning af brud dramatisk lettere.

For Kubernetes er Vault Agent Injector eller Vault Secrets Operator integrationsstierne. Injektoren kører som en muterende webhook, der automatisk sidevogner en Vault-agent ind i dine pods, som autentificerer til Vault ved hjælp af podens Kubernetes-tjenestekonto og skriver hemmeligheder til en delt volumen i hukommelsen. Vault Secrets Operator (VSO), den nyere tilgang, synkroniserer Vault-hemmeligheder til native Kubernetes Secret-objekter - mere velkendte for operatører på bekostning af hemmeligheder, der kortvarigt eksisterer i etcd.

Vaults hemmelige motorer dækker et imponerende udvalg:

• Databaselegitimationsoplysninger (PostgreSQL, MySQL, MongoDB og mere)
• Dynamiske legitimationsoplysninger for AWS, GCP, Azure
• Generering af PKI og TLS certifikater
• SSH certifikat signering
• Kubernetes tjenestekontotokens

Hvad Vault gør godt: Dynamiske legitimationsoplysninger, finmaskede adgangspolitikker, en omfattende revisionslog og et modent plugin-økosystem. Hvis du har brug for hemmelig styring i overholdelsesgrad med fuld oversigt over, hvem der har adgang til hvad-hvornår, er Vault ofte den eneste rimelige mulighed.

Hvad skal du være opmærksom på: Vault har operationel kompleksitet. At køre det i høj tilgængelighedstilstand kræver omhyggelig opmærksomhed på storage-backends (Raft er nu det anbefalede valg), procedurer for ophævelse af forsegling og opgraderingsstier. Indlæringskurven er reel. Budget for platform engineering tid.

Priser: Open source-versionen er gratis og dækker de fleste behov. HashiCorp Cloud Platform (HCP) Vault er det administrerede tilbud med priser baseret på klyngetimer og hemmelige operationer. BSL-licensændringen fra 2023 førte til OpenTofu-gaffelen til Terraform, men Vaults gaffelækvivalent (OpenBao) er stadig ved at modnes.

📚 Anbefalet læsning: Hacking Kubernetes af Andrew Martin og Michael Hausenblas — fremragende dækning af Kubernetes angrebsflader inklusive hemmelige eksfiltrationsscenarier.

2. External Secrets Operator (ESO) — The K8s-Native Integration Layer

External Secrets Operator har en fundamentalt anderledes arkitektonisk holdning: I stedet for at være en hemmelighedsbutik i sig selv, er det en bro mellem Kubernetes og den eksterne butik, du allerede har. ESO synkroniserer hemmeligheder fra AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler og en voksende liste af andre backends til native Kubernetes Secret-objekter.

Kerneabstraktionen er den tilpassede ressource “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 holder øje med denne ressource, henter hemmeligheden fra AWS Secrets Manager (eller hvor som helst), og opretter en standard Kubernetes Secret. Din applikation læser ‘db-creds’ ligesom enhver anden Kubernetes Secret - ingen kodeændringer påkrævet. Når ‘refreshInterval’ tikker, genhenter og opdaterer ESO automatisk hemmeligheden.

Hvorfor er ESO så populær i 2026: Det spiller godt sammen med eksisterende investeringer. Din organisation har allerede AWS Secrets Manager (eller Vault, eller GCP Secret Manager) – ESO gør bare disse hemmeligheder forbrugbare i Kubernetes uden at ændre din applikationskode eller dine eksisterende hemmelige rotationsarbejdsgange.

ESO eller Vault Secrets Operator? Hvis du kører Vault, har VSO en strammere Vault-specifik integration (Vault dynamic secrets, Vault PKI). Hvis du er på en cloududbyders oprindelige hemmelige butik, er ESO det renere valg. Mange hold kører begge dele - ESO for sky-lagrede statiske hemmeligheder, VSO for Vault-administrerede dynamiske legitimationsoplysninger.

Priser: ESO er gratis og open source (Apache 2.0), vedligeholdt af et CNCF-sandkasseprojekt med stærk opbakning fra fællesskabet.

3. Forseglede hemmeligheder — GitOps-venlige krypterede hemmeligheder

Sealed Secrets af Bitnami løser et specifikt problem: hvordan gemmer du Kubernetes Secret-manifester i Git uden at gemme den faktiske klartekst? Svaret er asymmetrisk kryptering.

Sealed Secrets-controlleren kører i din klynge og har en privat nøgle. kubeseal CLI krypterer et Kubernetes Secret-manifest med klyngens offentlige nøgle, hvilket producerer en SealedSecret CRD. Dette krypterede manifest kan dekrypteres til Git sikkert — kun klyngens private nøgle kan dekryptere det, og det kan kun dekrypteres i den specifikke klynge (som standard er chifferteksten bundet til navneområde + navn).

# 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

Når du anvender SealedSecret til klyngen, dekrypterer controlleren den og opretter det tilsvarende Secret-objekt.

What Sealed Secrets gør godt: GitOps-arbejdsgange. Hvis du bruger Argo CD eller Flux og vil have alle klyngressourcer (inklusive hemmeligheder) deklarativt gemt i Git, passer Sealed Secrets perfekt til denne model. Det kræver nul eksterne afhængigheder ud over in-cluster controlleren.

Hvad det ikke gør: Rotation, dynamiske legitimationsoplysninger eller revisionslogning ud over standard Kubernetes-begivenheder. Sealed Secrets er en Git-storage-løsning, ikke en komplet hemmelighedsadministrationsplatform. Hvis din adgangskode ændres, krypterer du igen og forpligter dig igen.

Sikkerhedskopiering af privat nøgle er afgørende. Hvis du mister controllerens private nøgle, mister du muligheden for at dekryptere dine forseglede hemmeligheder. Sikkerhedskopier hemmeligheden “sealed-secrets-key” på et separat, sikkert sted.

Pris: Fuldt gratis og open source (Apache 2.0).

4. AWS Secrets Manager med Kubernetes

Hvis dine arbejdsbelastninger primært kører på EKS (eller forbinder kraftigt til AWS-tjenester), er AWS Secrets Manager parret med Secrets Store CSI-driveren eller en ekstern hemmelighedsoperatør. Du holder hemmeligheder i AWS’s administrerede, krypterede, revisionsloggede butik og trækker dem ind i Kubernetes, når det er nødvendigt.

Secrets Store CSI Driver (SSCSID) er den CNCF-vedligeholdte tilgang: hemmeligheder monteres direkte i pods som filer via en CSI-diskenhed, aldrig skrevet til etcd som Kubernetes Secret-objekter. Dette er den højeste sikkerhedssti - hemmeligheder findes i pod-hukommelsen, men ikke i Kubernetes Secret-butikken.

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

AWS Secrets Managers indbyggede muligheder inkluderer automatisk rotation for understøttede tjenester (RDS, Redshift, DocumentDB og via Lambda til brugerdefineret rotation), adgang på tværs af konti og dyb CloudTrail-integration til overholdelsesrevisionsspor.

Omkostningsovervejelse: AWS Secrets Manager opkræver pr. hemmelighed pr. måned og pr. API-kald. For store flåder med mange små hemmeligheder kan omkostningerne stige. Se vores cloud cost optimization guide for strategier til styring af hemmelige-relaterede AWS-udgifter.

Bedst til: EKS-native teams, der allerede har investeret i AWS-økosystemet, og som ønsker stram IAM-integration og native RDS-legitimationsrotation.

5. Doppler — Developer-First SaaS Secrets Platform

Doppler har en SaaS-first-tilgang, der prioriterer udvikleroplevelse frem for operationel kompleksitet. Du definerer hemmeligheder i Dopplers brugergrænseflade (eller via CLI/API), organiserer dem efter miljø (dev, iscenesættelse, produktion), og Doppler Kubernetes-operatøren synkroniserer dem automatisk til Kubernetes Secrets.

Operatøren undersøger Doppler for ændringer og opdaterer den tilsvarende Kubernetes Secret, og udløser eventuelt pod-genstart, når hemmeligheder ændres. Setup er en enkelt Helm chart installation:

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

Hvor Doppler skinner: Lokal udvikling og CI/CD-integration sammen med Kubernetes. Doppler CLI erstatter miljøfiler fuldstændigt (“doppler run – your-command”), hvilket giver de samme hemmeligheder på tværs af lokale, CI og produktionsmiljøer. For CI/CD-pipelines, eliminerer Dopplers native integrationer med GitHub Actions, CircleCI og andre behovet for at kopiere hemmeligheder ind i pipeline-miljøvariabler.

Hvad Doppler ikke dækker: Dynamiske databaselegitimationsoplysninger. Doppler er en statisk hemmelighedsbutik med versionshistorik og revisionslogning - det er ikke en hemmelig generationsmotor som Vault.

Priser: Doppler tilbyder et gratis niveau for små teams. Betalte planer tilføjer SSO, adgangsanmodninger og overholdelsesfunktioner. Tjek Dopplers prisside for aktuelle niveauer (prisændringer; bekræft før budgettering).

6. Infisical — Open-Source Vault Alternativ

Infisical er den stærkeste open source-udfordrer til Vault/Doppler-duopolet. Det giver en web-brugergrænseflade, CLI, SDK’er og en Kubernetes-operatør - kan implementeres selv-hostet eller forbrugt som en cloud-tjeneste.

Infisical tilføjede dynamiske hemmeligheder understøtter i 2024, rettet mod generering af databaselegitimationsoplysninger svarende til Vaults databasehemmelighedsmotor. Infisical Kubernetes-operatøren synkroniserer ‘InfisicalSecret’-CRD’er til native Kubernetes Secrets med konfigurerbare opdateringsintervaller.

For teams, der ønsker UX på SaaS-niveau (web-dashboard, arbejdsgange for adgangsanmodninger, revisionslogfiler), men som ikke kan bruge ekstern SaaS på grund af overholdelseskrav, er Infisical self-hosted overbevisende. Det er betydeligt nemmere at betjene end Vault og har en mere udviklervenlig onboarding-oplevelse.

Pris: Open source-kerne er gratis. Den cloud-hostede version har et gratis niveau og betalte planer for avancerede funktioner. Selv-hostet virksomhedslicens er tilgængelig for compliance-tunge miljøer.

📚 For et dybere dyk ned i Kubernetes sikkerhedsarkitektur: Kubernetes Security and Observability på Amazon dækker hemmeligheder, RBAC, netværkspolitik og runtime-sikkerhed i én sammenhængende ramme.

Implementeringstip

Start med kryptering i hvile. Inden du tilføjer yderligere værktøj, skal du aktivere Kubernetes etcd-kryptering i hvile. For administrerede klynger er dette ofte et enkelt afkrydsningsfelt. For selvadministrerede klynger skal du følge den officielle vejledning. Dette hæver straks din grundlæggende sikkerhedsstilling.

Adopter mindst privilegerede RBAC for hemmeligheder. Kontroller, hvilke tjenestekonti der har tilladelser “get”, “liste” eller “se” på hemmelige objekter. Standardservicekonti i mange Helm-diagrammer er overprovisioneret. Spænd RBAC før rotation til et eksternt lager.

Planlæg dine hemmelige navnekonventioner tidligt. Hemmeligheder spreder sig hurtigt. Et konsekvent hierarki ({env}/{service}/{credential-type}) gør automatisering, RBAC-politikker og rotationsarbejdsgange dramatisk enklere på tværs af alle værktøjer.

Spring ikke over hemmelige rotationstests. Uanset hvilket værktøj du vælger, så kør et rotationsbor, før du skal bruge det. Bekræft, at din applikation henter nye legitimationsoplysninger uden nedetid. Dynamiske hemmeligheder med Vault eller ESO gør dette væsentligt nemmere end manuelt opdaterede statiske hemmeligheder.

Overvåg for hemmelig spredning. Efterhånden som din platform vokser, ophobes hemmeligheder. Integrer hemmelighedsstyringsrapportering i dine platformstekniske dashboards. Se vores Kubernetes-vejledning til overvågningsværktøjer for observationsværktøjer, der kan spore hemmelige adgangsmønstre.

Hvilket værktøj til hvilket hold?

Lille team, cloud-native (AWS/GCP/Azure): Start med External Secrets Operator, der opretter forbindelse til din cloud-udbyders oprindelige hemmelige butik. Minimal operationel overhead, solid revisionsintegration, gratis.

GitOps-first team (Argo CD / Flux): Forseglede hemmeligheder til GitOps-lagret konfiguration, kombineret med ESO for følsomme runtime-legitimationsoplysninger, der ikke engang burde være krypteret i Git.

Enterprise med overholdelseskrav (SOC 2, PCI, HIPAA): HashiCorp Vault — enten selv-hostet tømmerflådeklynge eller HCP Vault-administreret. Revisionsloggen, dynamiske legitimationsoplysninger og finmasket politikmotor er svære at replikere andre steder.

Udvikleroplevelsesfokuseret, blandet miljø (K8s + lokal + CI/CD): Doppler til den forenede DX på tværs af miljøer, eller Infisical-selvhostet, hvis data-residency er vigtig.

Stor platformsteam, der administrerer multi-cluster-miljøer: External Secrets Operator som abstraktionslaget på K8s-siden, understøttet af Vault eller en cloud-native butik. At centralisere kilden til sandhed i én butik, mens ESO bruges som en universel adapter på tværs af klynger, er et velafprøvet mønster i 2026.

Relateret: For sikkerhedsrisici introduceret af AI-kodningsværktøjer i dine Kubernetes-manifester og CI/CD-pipelines, se vores vejledning om vibe-kodningssikkerhedsrisici i 2026.

Ofte stillede spørgsmål

Er Kubernetes Secrets krypteret som standard?

Nej. Kubernetes Secrets er base64-kodet som standard - kodning, ikke kryptering. Dataene gemmes i etcd uden kryptering, medmindre du udtrykkeligt aktiverer Encryption at Rest. Bekræft altid din klyngekonfiguration og overvej eksternt hemmelighedsstyringsværktøj til produktionsbelastninger.

Hvad er forskellen mellem Sealed Secrets og External Secrets Operator?

Sealed Secrets krypterer hemmelige manifester til sikker Git-lagring — det er en GitOps-løsning. External Secrets Operator henter levende hemmeligheder fra eksterne butikker (Vault, AWS Secrets Manager osv.) og opretter indbyggede Kubernetes Secrets fra dem. De løser forskellige problemer og bruges ofte sammen.

Hvad er dynamiske hemmeligheder, og hvorfor betyder de noget?

Dynamiske hemmeligheder er legitimationsoplysninger, der genereres on-demand med automatisk udløb - snarere end statiske adgangskoder, der gemmes på ubestemt tid. HashiCorp Vault er den primære kilde til dynamiske hemmeligheder for Kubernetes. Hvis en dynamisk legitimationsoplysninger er kompromitteret, udløber den efter sin egen tidsplan. Dette begrænser dramatisk eksplosionsradius sammenlignet med langlivede statiske hemmeligheder.

Skal jeg bruge Doppler eller HashiCorp Vault til Kubernetes?

Doppler vinder på udvikleroplevelse og hurtig adoption. Vault vinder på virksomhedens overholdelse – dynamiske legitimationsoplysninger, granulære revisionslogfiler og finmasket politik. For små til mellemstore hold er Doppler ofte den hurtigere vej. For SOC 2-, PCI DSS- eller HIPAA-miljøer er Vault typisk det mere forsvarlige valg.

Hvordan forhindrer jeg hemmeligheder i at lække ind i containerlogfiler?

Monter hemmeligheder som filer i stedet for miljøvariabler (miljøvariabler kan afsløres gennem /proc og debug-endepunkter). Brug Secrets Store CSI-driveren til at omgå etcd helt. Scan for utilsigtede hemmelige commits i din CI/CD-pipeline med værktøjer som Trivys hemmelige scanner – se vores vejledning til sårbarhedsscanningsværktøjer for opsætningsdetaljer.

Hvad er det bedste hemmelighedsstyringsværktøj for et lille Kubernetes-team?

Start med External Secrets Operator understøttet af din cloud-udbyders oprindelige hemmelige butik. Minimal driftsoverhead, solid revisionslogning, gratis. Tilføj Dopplers gratis niveau, hvis du også ønsker en samlet dev/CI/production secrets-oplevelse.

Hvordan integrerer jeg AWS Secrets Manager med Kubernetes?

Brug External Secrets Operator med en ClusterSecretStore, der peger på AWS Secrets Manager. På EKS skal du bruge IRSA (IAM-roller for servicekonti) til IAM-godkendelse på pod-niveau - ingen statiske legitimationsoplysninger er nødvendige. På ikke-EKS-klynger skal du bruge en IAM-bruger med secretsmanager:GetSecretValue scoped til dine specifikke hemmelige ARN’er.