Beste Kubernetes Secrets Management Tools i 2026: Vault, ESO, Sealed Secrets og mer

Hver Kubernetes-klynge leveres med et innebygd “Secret”-objekt. Det ser ut som sikkerhet. Det føles som trygghet. Det er ikke sikkerhet.

En Kubernetes Secret er, som standard, bare en base64-kodet streng lagret i etcd — lesbar av alle med klyngetilgang og trivielt dekodbar med en one-liner: echo "c2VjcmV0" | base64 -d. Med mindre du eksplisitt har aktivert kryptering i hvile (og de fleste team har ikke), er databasepassordene, API-tokens og TLS private nøkler ukryptert i klyngens kontrollplandatalager. Utfør et Kubernetes-manifest som inneholder en Hemmelighet til Git, og den legitimasjonen lever i arkivets historie for alltid.

Dette er problemet som en ny generasjon av hemmelighetshåndteringsverktøy har dukket opp for å løse - og i 2026 har økosystemet modnet betydelig. Denne veiledningen dekker de seks viktigste verktøyene for å administrere hemmeligheter i Kubernetes-miljøer: hva de gjør, hva de ikke gjør, og hvilket som passer teamets modenhetsnivå.

Relatert lesning: Hvis du er bekymret for hemmeligheter som lekker gjennom CI/CD-rørledningen din, kan du se oppsummeringen av beste CI/CD-rørledningsverktøy. For det bredere beholdersikkerhetsbildet, sjekk ut vår veiledning for sårbarhetsskanningsverktøy.

Hvorfor Kubernetes standardhemmeligheter kommer til kort

Før du dykker ned i verktøy, er det verdt å være presis om hva Kubernetes Secrets mangler – fordi å forstå gapet er det som lar deg velge den riktige løsningen.

Ingen kryptering i hvile som standard. etcd lagrer Kubernetes Secrets som base64, ikke kryptert. Aktivering av Encryption at Rest er et konfigurasjonstrinn på klyngenivå som administrerte Kubernetes-leverandører (EKS, GKE, AKE) håndterer annerledes, og mange selvadministrerte klynger hopper over det helt.

Ingen hemmelig rotasjon. Det er ingen innebygd mekanisme for en Kubernetes Secret for å vite at dens støtteinformasjon har endret seg. Du roterer et databasepassord eksternt, og podene dine fortsetter å bruke det gamle til du manuelt oppdaterer hemmeligheten og starter de berørte podene på nytt.

Ingen revisjonslogg for hemmelig tilgang. Standard Kubernetes-revisjonsloggingsposter Hemmelige objektmodifikasjoner, men de fleste konfigurasjoner logger ikke individuelle lesninger – noe som betyr at du ikke kan svare “hvilken tjeneste fikk tilgang til dette tokenet og når?”

Git-fiendtlig av design. Standardrådet er “aldri forplikte hemmeligheter til Git.” Men i en GitOps-verden der alt-som-kode er målet, er det et smertefullt unntak å opprettholde.

RBAC som et sløvt instrument. Kubernetes RBAC lar deg gi eller nekte tilgang til hemmelige objekter på navneområdenivå. Den kan ikke uttrykke “Tjeneste A kan lese hemmelig X, men ikke hemmelig Y”, eller “denne hemmeligheten utløper om 24 timer.”

Ingen av disse er grunner til å forlate Kubernetes - de er grunner til å bruke dedikerte hemmelighetsadministrasjonsverktøy på toppen av det.

TL;DR — Funksjonssammenligning

⚠️ = krever ekstra komponenter

1. HashiCorp Vault — Gullstandarden for bedriftshemmeligheter

HashiCorp Vault er målestokken som alle andre hemmelighetsadministrasjonsverktøy blir målt mot. Den har blitt kamptestet i bedriftsmiljøer i nesten et tiår, og funksjonssettet gjenspeiler denne dybden.

Vaults kjernefunksjon er dynamiske hemmeligheter — legitimasjon som genereres på forespørsel og utløper automatisk. I stedet for å lagre et statisk PostgreSQL-passord, genererer Vault et unikt brukernavn/passord-par for hver forespørrende tjeneste, gyldig for en konfigurerbar leieperiode (f.eks. en time). Når leieavtalen utløper, trekkes legitimasjonen tilbake. Dette eliminerer hele klasser av legitimasjonsspredning og gjør brudd inneslutning dramatisk enklere.

For Kubernetes er Vault Agent Injector eller Vault Secrets Operator integrasjonsbanene. Injektoren kjører som en muterende webhook som automatisk sidevogner en Vault-agent inn i podene dine, som autentiserer til Vault ved hjelp av podens Kubernetes-tjenestekonto og skriver hemmeligheter til et delt volum i minnet. Vault Secrets Operator (VSO), den nyere tilnærmingen, synkroniserer Vault-hemmeligheter til innfødte Kubernetes Secret-objekter – mer kjent for operatører, på bekostning av hemmeligheter som kort eksisterer i etcd.

Vaults hemmelige motorer dekker et imponerende utvalg:

• Databaselegitimasjon (PostgreSQL, MySQL, MongoDB og mer)
• AWS, GCP, Azure dynamisk legitimasjon
• Generering av PKI og TLS sertifikater
• Signering av SSH-sertifikat
• Kubernetes tjenestekonto tokens

Hva Vault gjør bra: Dynamisk legitimasjon, finmaskede tilgangspolicyer, en omfattende revisjonslogg og et modent plugin-økosystem. Hvis du trenger hemmelig administrasjon i samsvarsgrad med fullstendig oversikt over hvem som har tilgang til hva-når, er Vault ofte det eneste rimelige alternativet.

Hva du bør passe på: Vault har operasjonell kompleksitet. Å kjøre den i høytilgjengelighetsmodus krever nøye oppmerksomhet til lagringsbackends (Raft er nå det anbefalte valget), opphevingsprosedyrer og oppgraderingsbaner. Læringskurven er ekte. Budsjett for plattformutviklingstid.

Priser: Åpen kildekode-versjonen er gratis og dekker de fleste behov. HashiCorp Cloud Platform (HCP) Vault er det administrerte tilbudet med priser basert på klyngetimer og hemmelige operasjoner. BSL-lisensendringen fra 2023 førte til OpenTofu-gaffelen for Terraform, men Vaults gaffelekvivalent (OpenBao) modnes fortsatt.

📚 Anbefalt lesning: Hacking Kubernetes av Andrew Martin og Michael Hausenblas — utmerket dekning av Kubernetes angrepsflater, inkludert hemmelige eksfiltrasjonsscenarier.

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

External Secrets Operator har en fundamentalt annerledes arkitektonisk holdning: i stedet for å være en hemmelighetsbutikk i seg selv, er det en bro mellom Kubernetes og den eksterne butikken du allerede har. ESO synkroniserer hemmeligheter fra AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler og en voksende liste over andre backends til native Kubernetes Secret-objekter.

Kjerneabstraksjonen er den tilpassede ressursen “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 ser på denne ressursen, henter hemmeligheten fra AWS Secrets Manager (eller hvor som helst), og lager en standard Kubernetes Secret. Applikasjonen din leser “db-creds” akkurat som alle andre Kubernetes Secret - ingen kodeendringer kreves. Når ‘refreshInterval’ tikker, henter og oppdaterer ESO hemmeligheten automatisk.

Hvorfor ESO er så populært i 2026: Det passer godt sammen med eksisterende investeringer. Organisasjonen din har allerede AWS Secrets Manager (eller Vault, eller GCP Secret Manager) – ESO gjør disse hemmelighetene forbrukbare i Kubernetes uten å endre applikasjonskoden eller eksisterende hemmelige rotasjonsarbeidsflyter.

ESO eller Vault Secrets Operator? Hvis du kjører Vault, har VSO en tettere Vault-spesifikk integrasjon (Vault dynamic secrets, Vault PKI). Hvis du er på en skyleverandørs opprinnelige hemmelige butikk, er ESO det renere valget. Mange team kjører begge deler – ESO for skylagrede statiske hemmeligheter, VSO for Vault-administrerte dynamiske legitimasjoner.

Priser: ESO er gratis og åpen kildekode (Apache 2.0), vedlikeholdt av et CNCF-sandkasseprosjekt med sterk støtte fra samfunnet.

3. Forseglede hemmeligheter — GitOps-vennlige krypterte hemmeligheter

Sealed Secrets av Bitnami løser et spesifikt problem: hvordan lagrer du Kubernetes Secret-manifester i Git uten å lagre selve klarteksten? Svaret er asymmetrisk kryptering.

Sealed Secrets-kontrolleren kjører i klyngen din og har en privat nøkkel. kubeseal CLI krypterer et Kubernetes Secret-manifest med klyngens offentlige nøkkel, og produserer en SealedSecret CRD. Dette krypterte manifestet kan trygt dekrypteres til Git - bare klyngens private nøkkel kan dekryptere den, og den kan bare dekrypteres i den spesifikke klyngen (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 bruker SealedSecret på klyngen, dekrypterer kontrolleren den og oppretter det tilsvarende Secret-objektet.

Hva Sealed Secrets gjør godt: GitOps-arbeidsflyter. Hvis du bruker Argo CD eller Flux og vil ha hver klyngressurs (inkludert hemmeligheter) deklarativt lagret i Git, passer Sealed Secrets perfekt til denne modellen. Det krever null eksterne avhengigheter utover in-cluster-kontrolleren.

Hva det ikke gjør: Rotasjon, dynamisk legitimasjon eller revisjonslogging utover standard Kubernetes-hendelser. Sealed Secrets er en Git-lagringsløsning, ikke en fullstendig administrasjonsplattform for hemmeligheter. Hvis passordet ditt endres, krypterer du på nytt og forplikter deg på nytt.

Sikkerhetskopiering av privat nøkkel er kritisk. Hvis du mister kontrollerens private nøkkel, mister du muligheten til å dekryptere dine forseglede hemmeligheter. Sikkerhetskopier hemmeligheten “sealed-secrets-key” på et eget, sikkert sted.

Priser: Helt gratis og åpen kildekode (Apache 2.0).

4. AWS Secrets Manager med Kubernetes

Hvis arbeidsbelastningene dine hovedsakelig kjører på EKS (eller kobler tungt til AWS-tjenester), er AWS Secrets Manager sammenkoblet med Secrets Store CSI-driveren eller operatøren en naturlig passform Du holder hemmeligheter i AWSs administrerte, krypterte, revisjonsloggede butikk og trekker dem inn i Kubernetes når det trengs.

Secrets Store CSI-driveren (SSCSID) er den CNCF-opprettholdte tilnærmingen: hemmeligheter monteres direkte i pods som filer via et CSI-volum, aldri skrevet til etcd som Kubernetes Secret-objekter. Dette er banen med høyest sikkerhet – hemmeligheter finnes i pod-minnet, 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 opprinnelige muligheter inkluderer automatisk rotasjon for støttede tjenester (RDS, Redshift, DocumentDB og via Lambda for tilpasset rotasjon), tilgang på tvers av kontoer og dyp CloudTrail-integrasjon for revisjonsspor for samsvar.

Kostnadshensyn: AWS Secrets Manager tar betalt per hemmelighet per måned og per API-anrop. For store flåter med mange små hemmeligheter kan kostnadene øke. Se vår veiledning for skykostnadsoptimalisering for strategier for å administrere hemmelige relaterte AWS-utgifter.

Best for: EKS-innfødte team som allerede har investert i AWS-økosystemet som ønsker tett IAM-integrasjon og naturlig rotasjon av RDS-legitimasjon.

5. Doppler — utvikler-første SaaS Secrets-plattform

Doppler bruker en SaaS-first-tilnærming som prioriterer utvikleropplevelse fremfor operasjonell kompleksitet. Du definerer hemmeligheter i Dopplers brukergrensesnitt (eller via CLI/API), organiserer dem etter miljø (utvikler, iscenesettelse, produksjon), og Doppler Kubernetes-operatøren synkroniserer dem automatisk til Kubernetes Secrets.

Operatøren sjekker Doppler for endringer og oppdaterer den tilsvarende Kubernetes Secret, eventuelt utløser pod omstart når hemmeligheter endres. Oppsettet er en enkelt installasjon av Helm-diagram:

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

Hvor Doppler skinner: Lokal utvikling og CI/CD-integrasjon sammen med Kubernetes. Doppler CLI erstatter miljøfiler fullstendig (doppler run -- your-command), og gir de samme hemmelighetene på tvers av lokale, CI- og produksjonsmiljøer. For CI/CD-pipelines, eliminerer Dopplers native integrasjoner med GitHub Actions, CircleCI og andre behovet for å kopiere hemmeligheter inn i pipelinemiljøvariabler.

Hva Doppler ikke dekker: Dynamisk databaselegitimasjon. Doppler er en butikk for statiske hemmeligheter med versjonshistorikk og revisjonslogging – det er ikke en hemmelig generasjonsmotor som Vault.

Priser: Doppler tilbyr et gratis nivå for små lag. Betalte planer legger til SSO, tilgangsforespørsler og samsvarsfunksjoner. Sjekk Dopplers prisside for gjeldende nivåer (prisendringer; bekreft før budsjettering).

6. Infisical — Open-Source Vault Alternative

Infisical er den sterkeste åpen kildekode-utfordreren til Vault/Doppler-duopolet. Det gir et nettgrensesnitt, CLI, SDK-er og en Kubernetes-operatør – distribuerbar selv-vert eller konsumert som en skytjeneste.

Støtte for infisical lagt til dynamiske hemmeligheter i 2024, rettet mot generering av databaselegitimasjon som ligner på Vaults databasehemmelighetsmotor. Infisical Kubernetes-operatøren synkroniserer InfisicalSecret CRD-er med innfødte Kubernetes Secrets, med konfigurerbare oppdateringsintervaller.

For team som ønsker UX på SaaS-nivå (nettdashbord, arbeidsflyter for tilgangsforespørsel, revisjonslogger), men som ikke kan bruke ekstern SaaS på grunn av samsvarskrav, er Infisical self-hosted overbevisende. Det er betydelig enklere å betjene enn Vault og har en mer utviklervennlig onboard-opplevelse.

Priser: Kjerne med åpen kildekode er gratis. Den skybaserte versjonen har et gratis nivå og betalte planer for avanserte funksjoner. Selvvertsbasert bedriftslisens er tilgjengelig for miljøer med mye samsvar.

📚 For et dypere dykk inn i Kubernetes sikkerhetsarkitektur: Kubernetes Security and Observability på Amazon dekker hemmeligheter, RBAC, nettverkspolicy og kjøretidssikkerhet i ett sammenhengende rammeverk.

Implementeringstips

Start med kryptering i hvile. Før du legger til ytterligere verktøy, aktiver Kubernetes etcd-kryptering i hvile. For administrerte klynger er dette ofte en enkelt avmerkingsboks. For selvadministrerte klynger, følg den offisielle veiledningen. Dette øker umiddelbart din grunnleggende sikkerhetsstilling.

Ta i bruk RBAC med minste privilegier for hemmeligheter. Kontroller hvilke tjenestekontoer som har tillatelser “get”, “liste” eller “se” på hemmelige objekter. Standard tjenestekontoer i mange Helm-diagrammer er overprovisionert. Stram RBAC før du roterer til et eksternt lager.

Planlegg dine hemmelige navnekonvensjoner tidlig. Hemmeligheter sprer seg raskt. Et konsekvent hierarki ({env}/{service}/{credential-type}) gjør automatisering, RBAC-policyer og rotasjonsarbeidsflyter dramatisk enklere på tvers av alle verktøy.

Ikke hopp over hemmelig rotasjonstesting. Uansett hvilket verktøy du velger, kjør en rotasjonsbor før du trenger den. Bekreft at applikasjonen din henter ny legitimasjon uten nedetid. Dynamiske hemmeligheter med Vault eller ESO gjør dette betydelig enklere enn manuelt oppdaterte statiske hemmeligheter.

Overvåk for hemmelig spredning. Ettersom plattformen din vokser, hoper det seg opp hemmeligheter. Integrer rapportering om hemmelighetsadministrasjon i dashboardene for plattformutvikling. Se vår Kubernetes overvåkingsverktøyveiledning for observasjonsverktøy som kan spore hemmelige tilgangsmønstre.

Hvilket verktøy for hvilket lag?

Lite team, skybasert (AWS/GCP/Azure): Start med External Secrets Operator som kobler til skyleverandørens opprinnelige hemmelige butikk. Minimal driftskostnad, solid revisjonsintegrasjon, gratis.

GitOps-first team (Argo CD / Flux): Sealed Secrets for GitOps-lagret konfigurasjon, kombinert med ESO for sensitive kjøretidslegitimasjoner som ikke skal være i Git engang kryptert.

Bedrift med samsvarskrav (SOC 2, PCI, HIPAA): HashiCorp Vault – enten selvvertsbasert flåteklynge eller HCP Vault administrert. Revisjonsloggen, dynamisk legitimasjon og finmasket policymotor er vanskelig å replikere andre steder.

Utvikler-erfaring fokusert, blandet miljø (K8s + lokal + CI/CD): Doppler for enhetlig DX på tvers av miljøer, eller Infisical selv-vert hvis data-residency er viktig.

Stort plattformteam som administrerer miljøer med flere klynge: External Secrets Operator som abstraksjonslaget på K8s-siden, støttet av Vault eller en skybasert butikk. Å sentralisere kilden til sannhet i én butikk mens du bruker ESO som en universell adapter på tvers av klynger er et godt utprøvd mønster i 2026.

Relatert: For sikkerhetsrisikoene introdusert av AI-kodingsverktøy i Kubernetes-manifestene og CI/CD-pipelines, se veiledningen vår om vibe coding security risks in 2026.

Vanlige spørsmål

Er Kubernetes Secrets kryptert som standard?

Nei. Kubernetes Secrets er base64-kodet som standard – koding, ikke kryptering. Dataene lagres i etcd uten kryptering med mindre du eksplisitt aktiverer Encryption at Rest. Verifiser alltid klyngekonfigurasjonen og vurder verktøy for administrasjon av eksterne hemmeligheter for produksjonsarbeidsbelastninger.

Hva er forskjellen mellom Sealed Secrets og External Secrets Operator?

Sealed Secrets krypterer hemmelige manifester for sikker Git-lagring – det er en GitOps-løsning. External Secrets Operator henter levende hemmeligheter fra eksterne butikker (Vault, AWS Secrets Manager, etc.) og lager innfødte Kubernetes Secrets fra dem. De løser ulike problemer og brukes ofte sammen.

Hva er dynamiske hemmeligheter og hvorfor er de viktige?

Dynamiske hemmeligheter er legitimasjon generert på forespørsel med automatisk utløp – i stedet for statiske passord lagret på ubestemt tid. HashiCorp Vault er den primære kilden til dynamiske hemmeligheter for Kubernetes. Hvis en dynamisk legitimasjon er kompromittert, utløper den etter sin egen tidsplan. Dette begrenser eksplosjonsradius dramatisk sammenlignet med langvarige statiske hemmeligheter.

Bør jeg bruke Doppler eller HashiCorp Vault for Kubernetes?

Doppler vinner på utvikleropplevelse og rask adopsjon. Vault vinner på bedriftsoverholdelse – dynamisk legitimasjon, granulære revisjonslogger og finmasket policy. For små til mellomstore lag er Doppler ofte den raskere veien. For SOC 2-, PCI DSS- eller HIPAA-miljøer er Vault vanligvis det mer forsvarlige valget.

Hvordan forhindrer jeg at hemmeligheter lekker inn i beholderloggene?

Monter hemmeligheter som filer i stedet for miljøvariabler (miljøvariabler kan eksponeres gjennom /proc og feilsøkingsendepunkter). Bruk Secrets Store CSI-driveren for å omgå etcd helt. Skann etter utilsiktede hemmelige forpliktelser i CI/CD-pipelinen din med verktøy som Trivys hemmelige skanner – se vår veiledning for sårbarhetsskanning for oppsettdetaljer.

Hva er det beste verktøyet for hemmeligheter for et lite Kubernetes-team?

Start med External Secrets Operator støttet av skyleverandørens opprinnelige hemmelige butikk. Minimal driftsoverhead, solid revisjonslogging, gratis. Legg til Dopplers gratislag hvis du også vil ha en enhetlig dev/CI/production secrets-opplevelse.

Hvordan integrerer jeg AWS Secrets Manager med Kubernetes?

Bruk External Secrets Operator med en ClusterSecretStore som peker på AWS Secrets Manager. På EKS, bruk IRSA (IAM-roller for tjenestekontoer) for IAM-autentisering på pod-nivå – ingen statisk legitimasjon er nødvendig. På ikke-EKS-klynger, bruk en IAM-bruker med secretsmanager:GetSecretValue scoped til dine spesifikke hemmelige ARN-er.