Bästa Kubernetes Secrets Management Tools 2026: Vault, ESO, Sealed Secrets och mer

Varje Kubernetes-kluster levereras med ett inbyggt “Secret”-objekt. Det ser ut som säkerhet. Det känns som en trygghet. Det är inte säkerhet.

En Kubernetes Secret är som standard bara en base64-kodad sträng lagrad i etcd — läsbar av alla med klusteråtkomst och trivialt avkodningsbar med en one-liner: echo "c2VjcmV0" | base64 -d. Såvida du inte uttryckligen har aktiverat kryptering i vila (och de flesta team har inte), finns dina databaslösenord, API-tokens och privata TLS-nycklar okrypterade i ditt klusters kontrollplansdatalager. Begå ett Kubernetes-manifest som innehåller en “Hemlighet” för Git, och den referensen lever för alltid i ditt förvars historia.

Detta är problemet som en ny generation av hemlighetshanteringsverktyg har dykt upp för att lösa – och 2026 har ekosystemet mognat avsevärt. Den här guiden täcker de sex viktigaste verktygen för att hantera hemligheter i Kubernetes-miljöer: vad de gör, vad de inte gör och vilket som passar ditt teams mognadsnivå.

Relaterad läsning: Om du är orolig över hemligheter som läcker genom din CI/CD-pipeline, se vår sammanfattning av bästa CI/CD-pipeline-verktyg. För den bredare containersäkerhetsbilden, kolla in vår guide för vulnerability scanning tools.

Varför Kubernetes Default Secrets faller kort

Innan du dyker in i verktyg är det värt att vara exakt om vad Kubernetes Secrets saknar – för att förstå klyftan är det som låter dig välja rätt lösning.

Ingen kryptering i vila som standard. etcd lagrar Kubernetes Secrets som base64, inte krypterad. Att aktivera Encryption at Rest är ett konfigurationssteg på klusternivå som hanterade Kubernetes-leverantörer (EKS, GKE, AKE) hanterar annorlunda, och många självhanterade kluster hoppar över det helt.

Ingen hemlig rotation. Det finns ingen inbyggd mekanism för en Kubernetes Secret att veta att dess stöduppgifter har ändrats. Du roterar ett databaslösenord externt, och dina pods fortsätter att använda det gamla tills du manuellt uppdaterar hemligheten och startar om de berörda podarna.

Ingen granskningslogg för hemlig åtkomst. Standard Kubernetes granskningsloggningsposter Hemliga objektändringar, men de flesta konfigurationer loggar inte individuella läsningar – vilket innebär att du inte kan svara “vilken tjänst fick åtkomst till denna token och när?”

Git-fientlig av design. Standardrådet är “begå aldrig hemligheter till Git.” Men i en GitOps-värld där allt-som-kod är målet, är det ett smärtsamt undantag att underhålla.

RBAC som ett trubbigt instrument. Kubernetes RBAC låter dig bevilja eller neka åtkomst till hemliga objekt på namnområdesnivå. Det kan inte uttrycka “Tjänst A kan läsa hemlighet X men inte hemlig Y”, eller “denna hemlighet går ut om 24 timmar.”

Inget av dessa är skäl att överge Kubernetes – de är skäl att använda dedikerade hemlighetshanteringsverktyg utöver det.

TL;DR — Funktionsjämförelse

⚠️ = kräver ytterligare komponenter

1. HashiCorp Vault — Guldstandarden för företagshemligheter

HashiCorp Vault är riktmärket mot vilket alla andra hemlighetshanteringsverktyg mäts. Det har stridstestats i företagsmiljöer i nästan ett decennium, och dess funktionsuppsättning återspeglar det djupet.

Vaults kärnfunktion är dynamiska hemligheter — autentiseringsuppgifter som genereras på begäran och förfaller automatiskt. Istället för att lagra ett statiskt PostgreSQL-lösenord, genererar Vault ett unikt användarnamn/lösenordspar för varje begärd tjänst, giltigt under en konfigurerbar hyresperiod (t.ex. en timme). När hyresavtalet löper ut återkallas legitimationen. Detta eliminerar hela klasser av meritförteckning och gör intrångsinneslutning dramatiskt enklare.

För Kubernetes är Vault Agent Injector eller Vault Secrets Operator integrationsvägarna. Injektorn körs som en muterande webhook som automatiskt sidovagnar en Vault-agent till dina poddar, som autentiserar till Vault med hjälp av poddens Kubernetes-tjänstkonto och skriver hemligheter till en delad volym i minnet. Vault Secrets Operator (VSO), det nyare tillvägagångssättet, synkroniserar Vault-hemligheter till inhemska Kubernetes Secret-objekt – mer bekanta för operatörer, till priset av hemligheter som kortvarigt finns i etcd.

Vaults hemliga motorer täcker ett imponerande utbud:

• Databasuppgifter (PostgreSQL, MySQL, MongoDB och mer)
• Dynamiska autentiseringsuppgifter för AWS, GCP, Azure
• Generering av PKI- och TLS-certifikat
• Signering av SSH-certifikat
• Kubernetes tjänstkontotokens

Vad Vault gör bra: Dynamiska autentiseringsuppgifter, finkorniga åtkomstpolicyer, en omfattande granskningslogg och ett moget plugin-ekosystem. Om du behöver hemlig hantering av efterlevnadsgrad med fullständig information om vem som har tillgång till vad-när, är Vault ofta det enda rimliga alternativet.

Vad du bör vara uppmärksam på: Vault har operativ komplexitet. Att köra det i högtillgänglighetsläge kräver noggrann uppmärksamhet på lagringsbackends (Raft är nu det rekommenderade valet), procedurer för att ta bort försegling och uppgraderingsvägar. Inlärningskurvan är verklig. Budget för plattformskonstruktionstid.

Priser: Den öppna källkodsversionen är gratis och täcker de flesta behov. HashiCorp Cloud Platform (HCP) Vault är det hanterade erbjudandet med prissättning baserad på klustertimmar och hemliga operationer. BSL-licensändringen från 2023 ledde till OpenTofu-gaffeln för Terraform, men Vaults gaffelmotsvarighet (OpenBao) håller fortfarande på att mogna.

📚 Rekommenderad läsning: Hacking Kubernetes av Andrew Martin och Michael Hausenblas — utmärkt täckning av Kubernetes attackytor inklusive hemliga exfiltrationsscenarier.

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

External Secrets Operator intar en fundamentalt annorlunda arkitektonisk hållning: snarare än att vara en hemlighetsbutik själv, är det en bro mellan Kubernetes och vilken extern butik du redan har. ESO synkroniserar hemligheter från AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler och en växande lista med andra backends till inbyggda Kubernetes Secret-objekt.

Kärnabstraktionen är den anpassade resursen “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 tittar på den här resursen, hämtar hemligheten från AWS Secrets Manager (eller var som helst), och skapar en standard Kubernetes Secret. Din applikation läser “db-creds” precis som alla andra Kubernetes Secret - inga kodändringar krävs. När “refreshInterval” tickar, hämtar och uppdaterar ESO hemligheten automatiskt.

Varför ESO är så populärt 2026: Det passar bra med befintliga investeringar. Din organisation har redan AWS Secrets Manager (eller Vault eller GCP Secret Manager) – ESO gör bara dessa hemligheter förbrukningsbara i Kubernetes utan att ändra din programkod eller dina befintliga hemliga rotationsarbetsflöden.

ESO eller Vault Secrets Operator? Om du kör Vault har VSO:n stramare Vault-specifik integration (Vault dynamic secrets, Vault PKI). Om du är på en molnleverantörs hemliga butik är ESO det renare valet. Många team kör båda – ESO för molnlagrade statiska hemligheter, VSO för Vault-hanterade dynamiska referenser.

Priser: ESO är gratis och öppen källkod (Apache 2.0), upprätthålls av ett CNCF-sandlådeprojekt med stark community-stöd.

3. Förseglade hemligheter — GitOps-vänliga krypterade hemligheter

Sealed Secrets av Bitnami löser ett specifikt problem: hur lagrar du Kubernetes Secret-manifest i Git utan att lagra den faktiska klartexten? Svaret är asymmetrisk kryptering.

Styrenheten Sealed Secrets körs i ditt kluster och har en privat nyckel. kubeseal CLI krypterar ett Kubernetes Secret-manifest med klustrets publika nyckel, vilket producerar en SealedSecret CRD. Detta krypterade manifest kan överföras till Git på ett säkert sätt — bara klustrets privata nyckel kan dekryptera det, och det kan bara dekrypteras i det specifika klustret (som standard är chiffertexten bunden till namnutrymme + namn).

# 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 tillämpar SealedSecret på klustret, dekrypterar styrenheten det och skapar motsvarande Secret-objekt.

Vad Sealed Secrets gör bra: GitOps-arbetsflöden. Om du använder Argo CD eller Flux och vill ha alla klusterresurser (inklusive hemligheter) deklarativt lagrade i Git, passar Sealed Secrets den modellen perfekt. Det kräver noll externa beroenden utöver klusterstyrenheten.

Vad det inte gör: Rotation, dynamiska referenser eller granskningsloggning utöver vanliga Kubernetes-händelser. Sealed Secrets är en Git-lagringslösning, inte en fullständig hemlighetshanteringsplattform. Om ditt lösenord ändras, krypterar du om och förbinder dig igen.

Säkerhetskopiering av privat nyckel är avgörande. Om du tappar bort kontrollerns privata nyckel, förlorar du möjligheten att dekryptera dina förseglade hemligheter. Säkerhetskopiera hemligheten “sealed-secrets-key” på en separat, säker plats.

Priser: Helt gratis och öppen källkod (Apache 2.0).

4. AWS Secrets Manager med Kubernetes

Om dina arbetsbelastningar huvudsakligen körs på EKS (eller ansluter kraftigt till AWS-tjänster), är AWS Secrets Manager ihopkopplad med Secrets Store CSI-drivrutinen eller External Secrets Operator a natural fits Du håller hemligheter i AWS:s hanterade, krypterade, revisionsloggade butik och drar in dem i Kubernetes när det behövs.

Secrets Store CSI-drivrutinen (SSCSID) är den CNCF-underhållna metoden: hemligheter monteras direkt i pods som filer via en CSI-volym, aldrig skrivna till etcd som Kubernetes Secret-objekt. Detta är den högsta säkerhetsvägen - hemligheter finns i podminnet men inte i Kubernetes Secret-butiken.

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

AWS Secrets Managers inbyggda funktioner inkluderar automatisk rotation för tjänster som stöds (RDS, Redshift, DocumentDB och via Lambda för anpassad rotation), åtkomst över flera konton och djup CloudTrail-integration för granskningsspår för efterlevnad.

Kostnadsövervägande: AWS Secrets Manager debiterar per hemlighet per månad och per API-anrop. För stora flottor med många små hemligheter kan kostnaderna öka. Se vår guide för optimering av molnkostnad för strategier för hantering av hemlighetsrelaterade AWS-utgifter.

Bäst för: EKS-baserade team som redan har investerat i AWS-ekosystemet som vill ha tät IAM-integration och inbyggd RDS-referensrotation.

5. Doppler — Developer-First SaaS Secrets Platform

Doppler använder en SaaS-first-metod som prioriterar utvecklarupplevelse framför operativ komplexitet. Du definierar hemligheter i Dopplers användargränssnitt (eller via CLI/API), organiserar dem efter miljö (dev, staging, produktion), och Doppler Kubernetes-operatören synkroniserar dem automatiskt till Kubernetes Secrets.

Operatören söker efter ändringar i Doppler och uppdaterar motsvarande Kubernetes-hemlighet, och utlöser eventuellt omstarter av podden när hemligheterna ändras. Installationen är en enda installation av Helm Chart:

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

Där Doppler lyser: Lokal utveckling och CI/CD-integration tillsammans med Kubernetes. Doppler CLI ersätter miljöfiler helt (doppler run -- ditt-kommando), vilket ger samma hemligheter över lokala, CI och produktionsmiljöer. För CI/CD-pipelines, eliminerar Dopplers inbyggda integrationer med GitHub Actions, CircleCI och andra behovet av att kopiera hemligheter till pipelinemiljövariabler.

Vad Doppler inte täcker: Dynamiska databasuppgifter. Doppler är en statisk hemlighetsbutik med versionshistorik och revisionsloggning - det är inte en hemlig generationsmotor som Vault.

Priser: Doppler erbjuder en gratis nivå för små team. Betalda planer lägger till SSO, åtkomstförfrågningar och efterlevnadsfunktioner. Kontrollera Dopplers prissättningssida för aktuella nivåer (prisändringar; verifiera före budgetering).

6. Infisical — Alternativ för valv med öppen källkod

Infisical är den starkaste utmanaren med öppen källkod till Vault/Doppler-duopolet. Det tillhandahåller ett webbgränssnitt, CLI, SDK:er och en Kubernetes-operatör – distribuerbar självvärd eller konsumeras som en molntjänst.

Infisical adderade dynamiska hemligheter stöds 2024, inriktat på generering av databasuppgifter som liknar Vaults databashemlighetsmotor. Operatören Infisical Kubernetes synkroniserar “InfisicalSecret” CRD:er till inhemska Kubernetes Secrets, med konfigurerbara uppdateringsintervall.

För team som vill ha UX på SaaS-nivå (webbinstrumentpanel, arbetsflöden för åtkomstförfrågningar, revisionsloggar) men inte kan använda extern SaaS på grund av efterlevnadskrav, är Infisical self-hosted övertygande. Det är betydligt enklare att använda än Vault och har en mer utvecklarvänlig introduktionsupplevelse.

Priser: Kärna med öppen källkod är gratis. Den molnbaserade versionen har en gratis nivå och betalplaner för avancerade funktioner. En företagslicens för egen värd är tillgänglig för miljöer med höga krav.

📚 För en djupare dykning i Kubernetes säkerhetsarkitektur: Kubernetes Security and Observability på Amazon täcker hemligheter, RBAC, nätverkspolicy och runtime-säkerhet i ett sammanhållet ramverk.

Implementeringstips

Börja med kryptering i vila. Innan du lägger till ytterligare verktyg, aktivera Kubernetes etcd-kryptering i vila. För hanterade kluster är detta ofta en enda kryssruta. För självhanterade kluster, följ den officiella guiden. Detta höjer omedelbart din grundläggande säkerhetsställning.

Anta RBAC med minsta privilegium för hemligheter. Granska vilka tjänstkonton som har “get”, “list” eller “watch”-behörigheter för hemliga objekt. Standardtjänstkonton i många Helm-diagram är överprovisionerade. Dra åt RBAC innan du roterar till ett externt lager.

Planera dina hemliga namnkonventioner tidigt. Hemligheter sprider sig snabbt. En konsekvent hierarki ({env}/{service}/{credential-type}) gör automatisering, RBAC-policyer och rotationsarbetsflöden dramatiskt enklare för alla verktyg.

Hoppa inte över hemliga rotationstester. Vilket verktyg du än väljer, kör en rotationsborr innan du behöver den. Verifiera att din applikation hämtar nya referenser utan driftstopp. Dynamiska hemligheter med Vault eller ESO gör detta betydligt enklare än manuellt uppdaterade statiska hemligheter.

Övervaka för hemlig spridning. När din plattform växer, ackumuleras hemligheter. Integrera rapportering om hemlighetshantering i dina instrumentpaneler för plattformsteknik. Se vår Kubernetes-guide för övervakningsverktyg för observerbarhetsverktyg som kan spåra hemliga åtkomstmönster.

Vilket verktyg för vilket team?

Litt team, molnbaserad (AWS/GCP/Azure): Börja med External Secrets Operator som ansluter till din molnleverantörs hemliga butik. Minimala driftskostnader, solid revisionsintegration, gratis.

GitOps-first team (Argo CD / Flux): Sealed Secrets för GitOps-lagrade konfigurationer, kombinerat med ESO för känsliga runtime-referenser som inte ens borde vara krypterade i Git.

Företag med efterlevnadskrav (SOC 2, PCI, HIPAA): HashiCorp Vault — antingen egenvärdigt flottkluster eller HCP Vault-hanterat. Granskningsloggen, dynamiska referenser och finkornig policymotor är svåra att replikera någon annanstans.

Utvecklar-upplevelse fokuserad, blandad miljö (K8s + lokal + CI/CD): Doppler för den förenade DX över miljöer, eller Infisical självvärd om datauppehållet är viktigt.

Stort plattformsteam som hanterar miljöer med flera kluster: External Secrets Operator som abstraktionsskiktet på K8s-sidan, med stöd av Vault eller en molnbaserad butik. Att centralisera källan till sanning i en butik samtidigt som ESO används som en universell adapter över kluster är ett väl beprövat mönster 2026.

Relaterat: För säkerhetsriskerna som introduceras av AI-kodningsverktyg i dina Kubernetes-manifester och CI/CD-pipelines, se vår guide om vibe-kodningssäkerhetsrisker 2026.

Vanliga frågor

Är Kubernetes Secrets krypterade som standard?

Nej. Kubernetes Secrets är base64-kodade som standard — kodning, inte kryptering. Data lagras i etcd utan kryptering om du inte uttryckligen aktiverar Encryption at Rest. Verifiera alltid din klusterkonfiguration och överväg verktyg för hantering av externa hemligheter för produktionsbelastningar.

Vad är skillnaden mellan Sealed Secrets och External Secrets Operator?

Sealed Secrets krypterar hemliga manifest för säker Git-lagring — det är en GitOps-lösning. External Secrets Operator hämtar levande hemligheter från externa butiker (Vault, AWS Secrets Manager, etc.) och skapar inbyggda Kubernetes Secrets från dem. De löser olika problem och används ofta tillsammans.

Vad är dynamiska hemligheter och varför spelar de roll?

Dynamiska hemligheter är autentiseringsuppgifter som genereras på begäran med automatiskt utgångsdatum - snarare än statiska lösenord som lagras på obestämd tid. HashiCorp Vault är den primära källan till dynamiska hemligheter för Kubernetes. Om en dynamisk autentiseringsinformation äventyras löper den ut enligt sitt eget schema. Detta begränsar dramatiskt sprängningsradien jämfört med långlivade statiska hemligheter.

Ska jag använda Doppler eller HashiCorp Vault för Kubernetes?

Doppler vinner på utvecklarupplevelse och snabb adoption. Arkiv vinner på företagsefterlevnad – dynamiska referenser, granulära granskningsloggar och finkornig policy. För små till medelstora lag är Doppler ofta den snabbare vägen. För SOC 2-, PCI DSS- eller HIPAA-miljöer är Vault vanligtvis det mer försvarbara valet.

Hur förhindrar jag att hemligheter läcker in i behållarloggarna?

Montera hemligheter som filer snarare än miljövariabler (miljövariabler kan exponeras genom /proc och felsökningsslutpunkter). Använd Secrets Store CSI-drivrutinen för att kringgå etcd helt. Sök efter oavsiktliga hemliga bekräftelser i din CI/CD-pipeline med verktyg som Trivys hemliga skanner — se vår guide för vulnerability scanning tools för installationsdetaljer.

Vilket är det bästa verktyget för hemlighetshantering för ett litet Kubernetes-team?

Börja med External Secrets Operator med stöd av din molnleverantörs hemliga butik. Minimal operationsoverhead, solid revisionsloggning, gratis. Lägg till Dopplers gratisnivå om du också vill ha en enhetlig dev/CI/production secrets-upplevelse.

Hur integrerar jag AWS Secrets Manager med Kubernetes?

Använd External Secrets Operator med en ClusterSecretStore som pekar på AWS Secrets Manager. På EKS, använd IRSA (IAM-roller för tjänstekonton) för IAM-autentisering på podnivå – inga statiska autentiseringsuppgifter behövs. På icke-EKS-kluster, använd en IAM-användare med secretsmanager:GetSecretValue avgränsad till dina specifika hemliga ARN.