HashiCorp Vault 2.2: Secrets i 14 Steg [2026]

Hårdkodade API-nycklar i kod är fortfarande en av de vanligaste orsakerna till dataintrång, och de flesta utvecklingsteam vet det utan att göra något åt det. HashiCorp Vault löser problemet genom att flytta alla lösenord, API-nycklar och certifikat till en central, krypterad tjänst som delar ut dem tillfälligt istället för permanent. Den 15 oktober 2026 släppte HashiCorp Vault 2.2.0, med stöd för postkvantcertifikat, TPM-baserad autentisering och förbättrad kryptoagilitet i Transit-motorn. Den här guiden visar hur du installerar Vault, bygger ett komplett exempelprojekt med dynamiska databas-secrets och TLS-certifikat, och undviker de fallgropar som får nya installationer att låsa sig eller läcka data.

Du kommer att gå igenom installation, initiering, policyer för minsta behörighet, AppRole-autentisering för applikationer, dynamiska PostgreSQL-credentials, ett eget PKI för interna TLS-certifikat, kryptering med Transit-motorn och en fungerande Node.js-app som hämtar hemligheter i realtid. Vi jämför också Vault mot AWS Secrets Manager och Azure Key Vault på pris, och går igenom de vanligaste produktionsfelen. Mer allmän bakgrund om molnsäkerhet och felkonfiguration hittar du på vår säkerhetssektion.

Vad är HashiCorp Vault och varför behövs det 2026?

Vault är en central hemlighetshanterare som lagrar, krypterar och delar ut känslig data: databaslösenord, API-nycklar, TLS-certifikat och krypteringsnycklar. Istället för att en applikation läser ett lösenord från en miljövariabel som ligger still i åratal, kan Vault generera ett tillfälligt lösenord som upphör att gälla efter en timme. HashiCorp beskriver mekanismen rakt av: om ett konto blir komprometterat kan bara det kontots uppgifter återkallas istället för att hela systemets lösenord måste bytas. Det är skillnaden mellan att byta ett lås och att byta alla lås i hela huset.

Konceptet kallas dynamiska secrets, och det är kärnan i varför Vault vuxit till en standardkomponent i molnarkitekturer. Lucy Davinhart, talare från Sky Betting & Gaming, förklarade principen under en HashiCorp-presentation: “Unlike static key-value secrets, dynamic secrets do not necessarily exist until you request them. They can be time-limited, and you can revoke them early through Vault if you no longer require them”. Ett AWS-exempel hon gav: Vault loggar in i AWS med sina egna uppgifter, skapar en tillfällig IAM-användare, och skickar tillbaka nycklarna till din app tillsammans med en lease, en tidsgräns. Så fort leasen löper ut tar Vault bort IAM-användaren och nycklarna slutar fungera, helt automatiskt.

Senaste versionen, Vault 2.2.0, byggde vidare på detta med stöd för ML-DSA-certifikat i PKI-motorn, den postkvantsäkra signaturalgoritm som X.509-certifikat nu kan utfärdas med. Transit-motorn fick kryptoagilitet i Enterprise-versionen, vilket betyder att du kan byta krypteringsalgoritm för en nyckel utan att behöva ändra konfigurationen i alla anslutna system. Det är relevant för team som redan planerar sin övergång till postkvantkryptografi, ett ämne som blir allt mer akut i takt med att NIST:s rekommendationer sprider sig till europeiska myndigheter.

Det som gör Vault annorlunda jämfört med att bara kryptera en konfigurationsfil är att varje hemlighet blir en levande resurs med en ägare, en livslängd och en logg. En utvecklare som kopierar ett lösenord från Slack till en lokal .env-fil lämnar ett spår som ingen ser. En utvecklare som hämtar samma lösenord från Vault lämnar en rad i granskningsloggen med tidsstämpel, identitet och sökväg. Den skillnaden är ofta det som avgör om en säkerhetsutredning tar en timme eller en vecka efter ett intrång.

Vaults secrets-motorer: en snabb översikt

Innan du börjar bygga är det värt att förstå att Vault inte är en enda funktion utan en samling av fristående motorer som alla monteras på egna sökvägar. Du väljer själv vilka du aktiverar, och du kan köra flera samtidigt för olika delar av samma applikation. Det gör Vault mer av en plattform än ett enskilt verktyg, vilket också är orsaken till att en komplett genomgång tar fler steg än en enklare integration mot en enda molntjänst. Tabellen nedan sammanfattar de motorer vi använder i den här guiden och vad varje en är till för.

Secrets-motor	Vad den gör	Används i
KV v2	Lagrar statiska nyckel-värde-par med versionshistorik	Steg 4-5
AppRole (auth)	Låter applikationer autentisera sig utan lösenord	Steg 6-7
Database	Genererar tillfälliga databaskonton på begäran	Steg 8
PKI	Utfärdar interna TLS-certifikat med kort livslängd	Steg 9
Transit	Krypterar och dekrypterar data utan att lagra den	Steg 10
Kubernetes (auth)	Låter poddar autentisera sig med sina service account-tokens	Steg 11

Utöver dessa finns motorer för SSH-nycklar, AWS-, Azure- och GCP-credentials, samt Transform-motorn för tokenisering av känsliga fält som personnummer eller kortnummer. De täcks inte i denna guide, men principen är densamma för alla: Vault genererar, levererar och tar bort åtkomst, istället för att en människa gör det manuellt.

Förutsättningar: verktyg och versioner du behöver

Innan du börjar, se till att du har följande installerat. Guiden är testad mot Vault Community Edition 2.2.0, men stegen fungerar även på 2.1.x med mindre justeringar i PKI-delen.

HashiCorp Vault 2.2.0 (Community Edition, gratis och självhostad)
Docker 27 eller senare, för att köra PostgreSQL och Vault i containrar
Node.js 22 LTS för exempelapplikationen
curl och jq för att testa Vaults HTTP-API
Ett Kubernetes-kluster (valfritt, för Steg 11), till exempel minikube eller en hanterad tjänst
Grundläggande kunskap om terminalkommandon och miljövariabler

Du behöver inget betalkonto. Allt i den här guiden körs på Vault Community Edition, som är gratis och självhostad. HCP Vault Dedicated, HashiCorps hanterade tjänst, kostar från cirka 450 dollar per månad för utvecklingsnivån och cirka 1 152 dollar per månad för Essentials-nivån, men det behövs inte för att följa guiden.

Steg 1-3: Installera, initiera och lås upp Vault

Första steget är att få en Vault-server igång. För utveckling kan du köra servern i utvecklingsläge, men i den här guiden sätter vi upp en riktig server med fillagring så att du förstår hela livscykeln, inklusive upplåsning, som du kommer behöva i produktion.

# Ladda ner och installera Vault 2.2.0 (Linux, amd64)
curl -O https://releases.hashicorp.com/vault/2.2.0/vault_2.2.0_linux_amd64.zip
unzip vault_2.2.0_linux_amd64.zip
sudo mv vault /usr/local/bin/
vault version
# Output: Vault v2.2.0

Skapa en konfigurationsfil som pekar ut lagring och nätverk, sedan starta servern som en vanlig process.

mkdir -p /opt/vault/data
cat > /opt/vault/config.hcl << 'EOF'
storage "file" {
  path = "/opt/vault/data"
}
listener "tcp" {
  address     = "127.0.0.1:8200"
  tls_disable = "true"
}
disable_mlock = true
api_addr = "http://127.0.0.1:8200"
EOF
vault server -config=/opt/vault/config.hcl &

Observera disable_mlock = true. Vault 2.2.0 tog bort cap_ipc_lock från sina containeravbildningar, vilket bryter installationer som förlitade sig på mlock utan att swap var avstängt på värden. Om du kör Vault i en container behöver du antingen stänga av swap helt eller sätta den här flaggan, annars kraschar servern vid start.

Lägg också märke till att vi satte tls_disable = "true" i konfigurationen. Det är okej för lokal utveckling på din egen maskin, men i produktion ska all trafik till Vaults API gå över TLS, annars skickas unseal-nycklar, tokens och hemligheter i klartext över nätverket. Byt till en tls_cert_file och tls_key_file så snart du flyttar bortom den lokala testmiljön, gärna med certifikat utfärdade av samma PKI-motor du bygger i Steg 9.

Öppna en ny terminal, peka klienten mot servern, och initiera valvet. Initiering genererar krypteringsnycklarna som används för att låsa upp Vault varje gång den startar om.

export VAULT_ADDR='http://127.0.0.1:8200'
vault operator init -key-shares=5 -key-threshold=3

# Output (spara dessa säkert, de visas bara en gång):
# Unseal Key 1: 7xK3m9...
# Unseal Key 2: 2pL8qR...
# Unseal Key 3: 9dF4tN...
# Unseal Key 4: 1zX6vB...
# Unseal Key 5: 5hJ2wM...
# Initial Root Token: hvs.AbCdEfGhIjKlMnOpQrSt

vault operator unseal   # Kör tre gånger med tre olika nycklar
vault login hvs.AbCdEfGhIjKlMnOpQrSt

Vi valde fem nyckeldelar med en tröskel på tre (Shamir-delning), vilket betyder att tre av fem personer måste samla sina nycklar för att låsa upp Vault. I ett team bör de fem delarna gå till fem olika personer, aldrig till en delad fil i en chattkanal. Root-token ska bara användas för initial konfiguration och sedan återkallas, vilket vi gör i Steg 6.

Om du stänger av Vault-processen och startar den igen kommer den att vara förseglad (sealed) på nytt, och du måste upprepa vault operator unseal tre gånger innan servern svarar på förfrågningar. Det är avsiktligt. Krypteringsnyckeln som används för att läsa data från disken finns bara i minnet medan Vault är upplåst, och den försvinner helt vid omstart. I produktion löser de flesta team detta med auto-unseal mot ett moln-KMS istället för att en människa ska mata in nycklar manuellt varje gång en nod startar om, något vi återkommer till under avancerade tips.

Steg 4-5: Aktivera KV-motorn och skriv din första hemlighet

Vault organiserar data i secrets-motorer som monteras på sökvägar. Key/Value-motorn version 2 (KV v2) är den enklaste: den lagrar godtyckliga nyckel-värde-par och sparar versionshistorik, så du kan rulla tillbaka till en tidigare hemlighet om den av misstag skrivs över.

vault secrets enable -path=app-secrets kv-v2

vault kv put app-secrets/database \
  username="app_user" \
  password="S3kr3tLosenord!"

# Output:
# == Secret Path: app-secrets/data/database ==
# Key          Value
# ---          -----
# created_time 2026-10-17T09:14:22Z
# version      1

vault kv get app-secrets/database

Det här är en statisk hemlighet, lösenordet ändras inte förrän någon skriver det igen. Det är bättre än att lägga lösenordet i en konfigurationsfil, men fortfarande inte lika säkert som dynamiska secrets, som vi bygger i Steg 8. Testa att skriva över värdet och kör sedan vault kv get -version=1 app-secrets/database för att se att den gamla versionen fortfarande finns kvar.

Lägg märke till att sökvägen för själva datan blev app-secrets/data/database, med ett extra data-segment, trots att du skrev till app-secrets/database. Det är en vanlig källa till förvirring för nya Vault-användare, eftersom KV v2 lägger till det segmentet automatiskt för att skilja dataläsningar från metadata om versionerna. Om du ska läsa hemligheten direkt via HTTP-API:et, inte via CLI-kommandot, måste du komma ihåg att själv lägga till /data/ i anropet.

Versionshistoriken i KV v2 går att konfigurera i detalj. Du kan sätta max_versions för att begränsa hur många gamla versioner som sparas, och delete-version-after för att automatiskt kassera versioner efter en viss tid, praktiskt om en känslig hemlighet av misstag skrivits in och du vill att den gamla versionen försvinner permanent efter en kort karantänperiod snarare än att ligga kvar återställningsbar för evigt. En borttagen version kan återställas med vault kv undelete om den bara mjuk-raderats, men en fullständigt förstörd version (vault kv destroy) går inte att få tillbaka.

Steg 6-7: Policyer för minsta behörighet och AppRole-autentisering

Root-token ger full åtkomst till allt i Vault, vilket är exakt vad du inte vill att en applikation ska ha. Policyer begränsar vad en given identitet får göra, och AppRole är den vanligaste metoden för att låta maskiner (inte människor) autentisera sig mot Vault utan lösenord.

cat > app-policy.hcl << 'EOF'
path "app-secrets/data/database" {
  capabilities = ["read"]
}
path "database/creds/app-role" {
  capabilities = ["read"]
}
EOF
vault policy write app-policy app-policy.hcl

vault auth enable approle
vault write auth/approle/role/web-app \
  token_policies="app-policy" \
  token_ttl=1h \
  token_max_ttl=4h

vault read auth/approle/role/web-app/role-id
vault write -f auth/approle/role/web-app/secret-id

Role-ID är som ett användarnamn och kan ligga i din app-konfiguration. Secret-ID är hemligheten och ska distribueras separat, till exempel via en CI/CD-pipeline med eget skydd. Applikationen byter de två mot en kort-levad token:

vault write auth/approle/login \
  role_id="" \
  secret_id=""
# Output ger en client_token med policyn "app-policy" och TTL 1h

Nu kan du återkalla root-token helt: vault token revoke -self. Framöver loggar du in med en admin-policy som själv är begränsad, aldrig med root-token i en produktionsmiljö. Det här mönstret, att skilja identitet från behörighet och sätta kort livslängd på båda, är samma princip som ligger bakom säker API-autentisering med JWT mot BOLA-attacker.

Ett vanligt upplägg i större team är att ha en separat AppRole per miljö, en för staging och en för produktion, snarare än en delad roll med en villkorad policy. Det gör det enklare att återkalla åtkomst för en hel miljö utan att påverka de andra, och det gör loggarna lättare att läsa när en incident ska utredas. Secret-ID bör dessutom ha en egen TTL separat från token-TTL, så att en stulen secret-ID inte går att använda för evigt även om ingen loggar in med den direkt.

Steg 8: Dynamiska databas-secrets med PostgreSQL

Det här är där Vault visar sin verkliga styrka. Istället för att en applikation läser ett statiskt databaslösenord, ber den Vault om ett helt nytt databaskonto varje gång den startar. Starta en PostgreSQL-container att testa mot.

docker run -d --name pg-test -e POSTGRES_PASSWORD=admin123 -p 5432:5432 postgres:17

vault secrets enable database

vault write database/config/app-db \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@127.0.0.1:5432/postgres?sslmode=disable" \
  allowed_roles="app-role" \
  username="postgres" \
  password="admin123"

vault write database/roles/app-role \
  db_name=app-db \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

vault read database/creds/app-role
# Output:
# lease_id       database/creds/app-role/a1b2c3d4...
# lease_duration 1h
# username       v-token-app-role-XyZ123
# password       A1b-generated-random-string

Vault skapade precis en helt ny PostgreSQL-roll med ett slumpat lösenord, giltig en timme. HashiCorps egen dokumentation sammanfattar varför det spelar roll: "By making the credentials short-lived, you reduce the chance that they might be compromised" (HashiCorp Developer, 2026). Efter en timme tar Vault bort rollen automatiskt. Om en angripare stjäl loggfilerna med lösenordet i, spelar det ingen roll, kontot finns inte längre.

Samma mönster går att återanvända för de flesta databaser Vault stöder, bland annat MySQL, MongoDB, MSSQL och Elasticsearch, bara pluginnamnet och connection_url ändras. Om din applikation redan har en connection pool som förväntar sig ett lösenord som lever hela applikationens livstid behöver du lägga till en liten omstart av poolen när leasen förnyas eller löper ut, annars försöker appen fortsätta använda ett konto som Vault redan tagit bort. Det är den vanligaste integrationsbuggen team stöter på första gången de inför dynamiska databas-secrets.

Steg 9: PKI-motorn, utfärda interna TLS-certifikat

PKI-motorn gör Vault till din egen interna certifikatutfärdare. Det är användbart för intern mTLS mellan mikrotjänster, där du inte vill köpa publika certifikat för tjänster som aldrig syns utanför ditt nätverk.

vault secrets enable pki
vault secrets tune -max-lease-ttl=87600h pki

vault write -field=certificate pki/root/generate/internal \
  common_name="internal.example.se" \
  ttl=87600h > ca_cert.crt

vault write pki/roles/web-server \
  allowed_domains="example.se" \
  allow_subdomains=true \
  max_ttl="720h"

vault write pki/issue/web-server common_name="api.internal.example.se"
# Output ger certificate, issuing_ca, private_key och serial_number

Vault 2.2.0 lade till stöd för ML-DSA-certifikat i PKI-motorn, vilket betyder att du redan nu kan testa postkvantsignerade certifikat parallellt med dina vanliga RSA- eller ECDSA-certifikat. Den tidigare versionen, 2.1.0, lade till stöd för PKCS#12 och JKS-paket, praktiskt om dina tjänster körs i Java-miljöer som väntar sig keystore-filer snarare än råa PEM-filer. Samma princip om kort livslängd på certifikat ligger bakom vår guide om mTLS med Nginx, där klientcertifikat roteras regelbundet istället för att gälla i flera år.

Sätt alltid max_ttl på rollen betydligt kortare än rot-CA:ns egen livstid, annars kan ett utfärdat certifikat råka gälla längre än det borde om någon glömmer uppdatera rollen efter en förändring. En vanlig uppsättning i produktion är en rot-CA med lång livstid som bara används offline eller sällan, och en mellanliggande CA (intermediate) som faktiskt signerar de dagliga certifikaten. Vault stöder det mönstret direkt genom att låta dig generera en mellanliggande CSR och sedan signera den med rot-CA:n, istället för att en enda nyckel bär hela ansvaret.

Steg 10: Transit-motorn, kryptera data utan att lagra den

Transit-motorn krypterar och dekrypterar data åt din applikation utan att Vault själv lagrar den krypterade datan. Det kallas "encryption as a service" och är användbart när du vill kryptera fält i en databas utan att hantera nycklar själv.

vault secrets enable transit
vault write -f transit/keys/app-data-key

echo -n "känslig kunddata" | base64 | \
  vault write transit/encrypt/app-data-key plaintext=-

# Output:
# ciphertext vault:v1:8SDd3WHDOjf7mq69CyC...

vault write transit/decrypt/app-data-key \
  ciphertext="vault:v1:8SDd3WHDOjf7mq69CyC..."

Prefixet vault:v1: visar vilken nyckelversion som användes. Det betyder att du kan rotera nyckeln med vault write -f transit/keys/app-data-key/rotate utan att gammal krypterad data blir oläsbar, Vault vet fortfarande hur man dekrypterar data krypterad med v1 även efter att v2 blivit standard. I Enterprise-versionen av Vault 2.2.0 går det nu även att byta kryptografisk algoritm för en nyckel utan att röra konfigurationen i de system som konsumerar den, vad HashiCorp kallar kryptoagilitet.

Transit-motorn är särskilt användbar när flera olika applikationer behöver kryptera samma typ av data, till exempel personnummer i tre olika mikrotjänster. Istället för att varje tjänst hanterar sin egen nyckel, sin egen rotation och sitt eget skydd mot nyckelläckage, pratar alla tre med samma Transit-motor och delar aldrig på den faktiska krypteringsnyckeln. Om du behöver söka eller jämföra krypterad data utan att dekryptera den finns även en convergent encryption-läge, där samma klartext alltid ger samma chiffertext, praktiskt för indexering men med en viss avvikelse från perfekt sekretess som är värt att känna till innan du slår på det.

Steg 11: Vault i Kubernetes med Agent Injector

Om dina applikationer körs i Kubernetes behöver de inte anropa Vaults API direkt. Vault Agent Injector lägger automatiskt till en sidecar-container i varje pod som begär det, och den containern hämtar hemligheter och skriver dem till en delad volym som din app läser som vanliga filer.

helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault --set "injector.enabled=true"

# I din deployment.yaml, lägg till annoteringar:
annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "web-app"
  vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/app-role"

Vault 2.2.0 lade till stöd för att autentisera noder via TPM-förankrad identitet i Enterprise-versionen, så Linux-arbetslaster kan bevisa sin identitet med hårdvara snarare än med förinstallerade bootstrap-uppgifter som någon ändå måste distribuera säkert i förväg. För team utan Enterprise-licens fungerar Kubernetes-autentiseringsmetoden precis lika bra: Vault litar på Kubernetes-klustrets egna service account-tokens istället för AppRole.

En detalj som ofta missas: sidecar-containern som injiceras av Agent Injector hämtar hemligheten en gång vid podstart och förnyar den sedan i bakgrunden enligt sin egen TTL, helt oberoende av din applikationscontainer. Om din app bara läser filen vid uppstart och aldrig tittar på den igen, kommer den att fortsätta köra med en hemlighet som i praktiken redan hunnit roteras av Vault i bakgrunden. För databas-credentials med kort TTL bör applikationen därför antingen läsa filen på nytt vid varje anslutning, eller lyssna på filsystemändringar och återansluta när innehållet byts ut.

Steg 12: Bygg det kompletta exempelprojektet

Nu sätter vi ihop allt till en liten Node.js-tjänst som loggar in med AppRole, hämtar ett databaslösenord dynamiskt, och förnyar sin egen token innan den löper ut. Skapa en mapp med följande filer.

// package.json
{
  "name": "vault-demo-app",
  "version": "1.0.0",
  "type": "module",
  "dependencies": { "node-vault": "^0.10.2" }
}

// index.js
import vaultClient from "node-vault";

const vault = vaultClient({
  apiVersion: "v1",
  endpoint: process.env.VAULT_ADDR || "http://127.0.0.1:8200",
});

async function main() {
  const login = await vault.approleLogin({
    role_id: process.env.VAULT_ROLE_ID,
    secret_id: process.env.VAULT_SECRET_ID,
  });
  vault.token = login.auth.client_token;

  const dbCreds = await vault.read("database/creds/app-role");
  console.log("Nytt DB-konto:", dbCreds.data.username);
  console.log("Lease löper ut om:", dbCreds.lease_duration, "sekunder");

  setInterval(async () => {
    await vault.tokenRenewSelf();
    console.log("Token förnyad", new Date().toISOString());
  }, 30 * 60 * 1000);
}

main().catch(console.error);

npm install
export VAULT_ADDR="http://127.0.0.1:8200"
export VAULT_ROLE_ID=""
export VAULT_SECRET_ID=""
node index.js

# Output:
# Nytt DB-konto: v-token-app-role-A9f2Kl
# Lease löper ut om: 3600 sekunder
# Token förnyad 2026-10-17T10:45:03.120Z

Appen innehåller inget lösenord i källkoden, ingen .env-fil med riktiga uppgifter, och inget som behöver roteras manuellt. Byt ut database/creds/app-role mot transit/encrypt/app-data-key eller pki/issue/web-server för att återanvända samma mönster för kryptering eller certifikat.

Steg 13-14: Snapshot, återställning och granskningslogg

Ett vanligt misstag är att aldrig testa sin backup förrän servern redan kraschat. Vault 2.2.0 gjorde det möjligt att återställa enskilda KV v2-secrets direkt från ett klustersnapshot, istället för att behöva återställa hela klustret för att rädda en enda hemlighet.

# Ta en snapshot (kräver Integrated Storage, inte fillagring)
vault operator raft snapshot save backup-2026-10-17.snap

# Aktivera granskningslogg innan något annat
vault audit enable file file_path=/var/log/vault/audit.log

tail -f /var/log/vault/audit.log | jq .

Granskningsloggen (audit log) ska aktiveras samma dag du sätter upp Vault, inte efter en incident. Varje läsning, skrivning och inloggning hamnar i loggen med tidsstämpel och identitet, vilket är exakt det spår en säkerhetsutredning behöver för att se vem som läste vad och när. Samma logik om spårbarhet gäller för leveranskedjan i sin helhet, se vår guide om SBOM och leveranskedjesäkerhet.

Vanliga fallgropar att undvika

De flesta Vault-incidenter kommer inte från en bugg i Vault självt utan från hur det konfigureras och drivs av teamet runt det. Nedan är de misstag som dyker upp oftast när nya installationer går från proof-of-concept till produktion, baserat på de typer av fel som täcks i HashiCorps egen dokumentation och i releaseanteckningarna för 2.1 och 2.2.

Att lagra unseal-nycklar på samma server som Vault. Om disken kraschar eller stjäls förloras både valvet och nycklarna till det samtidigt. Sprid nycklarna på minst tre separata platser.
Att aldrig återkalla root-token efter konfigurationen. En kvarglömd root-token är en permanent bakdörr. Återkalla den direkt efter att admin-policyer är på plats.
Att sätta för lång TTL på dynamiska secrets "för säkerhets skull". En lease på 24 timmar ger en angripare ett helt dygns fönster om token läcker. Börja med en timme och höj bara om du har en konkret anledning.
Att glömma stänga av swap när mlock inaktiveras i containrar. Vault 2.2.0:s nya containeravbildningar saknar cap_ipc_lock, och utan avstängd swap kan krypteringsnycklar i minnet skrivas till disk okrypterat.
Att använda samma AppRole för flera orelaterade applikationer. Om en app komprometteras får angriparen åtkomst till allt den delade rollen tillåter, inte bara den sårbara appens egna hemligheter.
Att hoppa över granskningsloggen i utvecklingsmiljö och glömma aktivera den i produktion. Många team testar i dev-läge utan audit log och tar sedan med sig samma vana till produktion.
Att inte planera för vad som händer om Vault självt blir otillgängligt. Om varje applikation kräver ett levande anrop till Vault för att starta, och Vault är nere, går hela flottan av tjänster inte att starta om. Cacha korta TTL:er lokalt eller sätt upp Vaults inbyggda högtillgänglighetsläge med flera noder innan det blir en enda felkälla för hela infrastrukturen.

Felsökning: vanliga fel och lösningar

När något går fel i Vault är felmeddelandet oftast exakt och användbart, till skillnad från många andra infrastrukturverktyg. Problemet är att meddelandena förutsätter att du redan vet var i stacken felet uppstod: klienten, nätverket, policyn eller själva secrets-motorn. Tabellen nedan samlar de fel vi stötte på eller som är vanligast rapporterade under installation, autentisering och drift, tillsammans med den mest sannolika orsaken och en konkret åtgärd.

Felmeddelande eller symptom	Trolig orsak	Lösning
Vault is sealed	Servern startade om och behöver låsas upp igen	Kör `vault operator unseal` tre gånger med giltiga nyckeldelar
permission denied	Policyn saknar rättigheter för sökvägen	Kontrollera `vault policy read <namn>` och lägg till rätt `path`-block
connection refused på port 8200	Vault-processen kraschade vid start	Kontrollera loggen, oftast en felaktig `storage`-sökväg eller saknad `disable_mlock`
lease not found vid tokenRenewSelf	Token har redan löpt ut (max_ttl nådd)	Logga in igen via AppRole istället för att förnya en död token
x509: certificate signed by unknown authority	Klienten litar inte på Vaults interna rot-CA	Importera `ca_cert.crt` i klientens trust store
database/config skriver men creds/app-role ger fel	`allowed_roles` matchar inte rollnamnet exakt	Jämför stavning mellan `database/config` och `database/roles`
too many unseal key shares provided	Fler nycklar angavs än tröskeln kräver	Ange exakt det antal som `key-threshold` anger, inte fler
Vault Agent Injector lägger inte till sidecar	Namespace saknar rätt label eller annotering felstavad	Verifiera `vault.hashicorp.com/agent-inject: "true"` exakt enligt dokumentationen

Avancerade tips för produktion

När grunderna sitter är nästa steg att automatisera upplåsning utan att en människa behöver mata in nycklar manuellt varje gång servern startar om. Auto-unseal med en extern nyckeltjänst (till exempel ett moln-KMS) löser det utan att kompromissa med Shamir-delningen för den initiala root-nyckeln. Ett annat tips: separera Vaults egen lagring från applikationsdata helt, kör Integrated Storage (Raft) i ett eget kluster av minst tre noder för kvorum och failover, aldrig på en enda server i produktion.

För team som redan automatiserar infrastruktur är det värt att koppla Vault till samma pipeline som hanterar Terraform-tillstånd, så att secrets aldrig checkas in i ett state-filarkiv av misstag. Den risken beskrivs närmare i vår guide om Terraform-säkerhet och IaC-skanning. Slutligen: sätt upp larm på antalet misslyckade inloggningsförsök mot Vault, inte bara på serverns drifttid. En plötslig våg av permission denied är ofta det första tecknet på att någon testar stulna AppRole-uppgifter.

Om din organisation har flera team eller flera kunder som ska dela samma Vault-kluster utan att se varandras hemligheter, finns Namespaces i Enterprise-versionen. Varje namespace fungerar som ett helt eget Vault med egna policyer, egna autentiseringsmetoder och egna secrets-motorer, men delar samma underliggande kluster och drift. Det är vanligtvis billigare och enklare att underhålla än att köra ett separat Vault-kluster per team, särskilt när antalet team växer förbi en handfull.

Slutligen: testa dina policyer innan du litar på dem. Kommandot vault policy read <namn> visar vad en policy faktiskt tillåter, men det bästa testet är att logga in som den rollen i en separat terminal och faktiskt försöka läsa och skriva till sökvägar som rollen inte borde ha åtkomst till. Om kommandot lyckas när det borde misslyckas har du hittat ett hål innan en angripare gör det.

Vault jämfört med AWS Secrets Manager och Azure Key Vault

Prismodellerna för hemlighetshantering skiljer sig markant mellan de tre stora alternativen, enligt en sammanställning av 14 verktyg för hemlighetshantering, och valet påverkar både kostnad och hur mycket du behöver konfigurera själv. AWS Secrets Manager tar betalt per lagrad hemlighet och per API-anrop, medan Azure Key Vault bara tar betalt per operation utan separat lagringskostnad. Vault Community Edition är gratis att självhosta, men du står själv för drift, patchning och tillgänglighet.

Tjänst	Prismodell	Bäst för
HashiCorp Vault Community	Gratis (självhostad, du står för drift)	Team med egen plattformskompetens och behov av dynamiska secrets
HCP Vault Dedicated	Från cirka 450 USD/mån (Development), cirka 1 152 USD/mån (Essentials)	Team som vill ha Vault utan att drifta klustret själva
AWS Secrets Manager	0,40 USD per hemlighet/månad + 0,05 USD per 10 000 API-anrop	AWS-tunga miljöer med färre men ofta lästa hemligheter
Azure Key Vault	0,03 USD per 10 000 operationer, ingen lagringsavgift	Azure-miljöer med många operationer men få lagrade secrets

Den praktiska skillnaden syns tydligast vid skala. En organisation som lagrar tusen hemligheter i AWS Secrets Manager betalar runt 400 dollar i månaden bara för lagring, innan ett enda API-anrop räknats in. Samma volym i Azure Key Vault kostar nästan ingenting i lagring men kan bli dyrare om applikationerna gör miljontals anrop per månad. Vault Community undviker båda avgifterna men flyttar kostnaden till din egen drifttid, vilket gör det mest attraktivt för team som redan kör egen Kubernetes-infrastruktur och ändå behöver personal för drift.

För svenska och nordiska organisationer med krav på datalokalisering spelar också var hemligheterna faktiskt lagras in i beslutet. AWS Secrets Manager och Azure Key Vault går att låsa till regioner inom EU, men du litar fortfarande på att amerikanska molnleverantörer hanterar den underliggande infrastrukturen. Ett självhostat Vault-kluster, kört i en svensk eller nordisk datacenterregion, ger full kontroll över var krypteringsnycklar och hemligheter fysiskt befinner sig, vilket är relevant för organisationer under NIS2 eller med strikta interna krav på datasuveränitet.

Så håller du Vault säkert uppgraderat

Vault 2.1 patchade tidigare under 2026 sårbarheten GO-2026-6107 i beroendet go.etcd.io/etcd/client/pkg/v3 genom att uppgradera till version 3.7.1. Det är en bra påminnelse om att Vault, precis som alla andra verktyg, ärver sårbarheter från sina egna beroenden, inte bara från sin egen kod. Ha en rutin för att läsa HashiCorps egna versionsanteckningar vid varje ny release, och testa uppgraderingar i en separat miljö innan de rullas ut mot produktionsklustret. Samma princip om att aldrig lita blint på ett verktygs säkerhet gäller generellt, oavsett om det handlar om hemlighetshantering eller patchning av kända sårbarheter som beskrivs i vår guide om CISA KEV-patchhantering.

Sätt också upp ett separat testkluster där du övar på katastrofåterställning minst en gång i kvartalet. Ta en snapshot, förstör testklustret medvetet, och återställ från snapshoten. Om det första försöket misslyckas vill du upptäcka det i en övning, inte under en verklig incident klockan tre på natten.

Prenumerera på HashiCorps releaseflöde på GitHub och läs igenom varje changelog innan du uppgraderar, även mellan mindre versioner. Vault 2.1.0 innehöll förändringar i hur PostgreSQL-lagring hanteras och i containeravbildningarnas innehåll, exakt den typ av förändring som kan se harmlös ut i en changelog men som stoppar en produktionsuppgradering mitt i natten om den testas för första gången direkt i produktion. Kör alltid en uppgradering mot ett testkluster med en kopia av din konfiguration innan den rullas ut brett.

Vanliga frågor om HashiCorp Vault

Är HashiCorp Vault gratis att använda?
Vault Community Edition är gratis och öppen källkod, och den innehåller kärnfunktionerna: KV-motor, dynamiska secrets, PKI och Transit. Enterprise-funktioner som kryptoagilitet, TPM-autentisering och avancerad governance kräver en kommersiell licens eller HCP Vault Dedicated.

Vad är skillnaden mellan statiska och dynamiska secrets?
En statisk hemlighet, som ett lösenord lagrat i KV-motorn, ändras bara när någon manuellt skriver ett nytt värde. En dynamisk hemlighet genereras av Vault vid varje begäran, har en tidsgräns, och tas automatiskt bort när den löper ut.

Behöver jag Kubernetes för att använda Vault?
Nej. Vault fungerar lika bra mot virtuella maskiner, bare-metal-servrar eller enskilda utvecklarmaskiner. Kubernetes-integrationen med Agent Injector är bara ett bekvämt sätt att leverera secrets till poddar, inget krav.

Vad händer om jag tappar bort unseal-nycklarna?
Utan tillräckligt många nyckeldelar för att nå tröskeln går det inte att låsa upp Vault igen, och all data i valvet blir oåtkomlig. Det är därför nycklarna måste spridas och säkerhetskopieras separat från servern själv.

Kan Vault ersätta AWS Secrets Manager helt?
Ja, tekniskt sett, men de löser delvis olika problem. AWS Secrets Manager är enklast om du redan är helt låst till AWS och vill undvika att drifta egen infrastruktur. Vault är mer flexibelt vid multimoln eller hybridmiljöer, och dess dynamiska secrets-motorer för databaser och PKI är mer utbyggda.

Hur ofta bör jag rotera Transit-krypteringsnycklar?
Det finns ingen universell regel, men många team roterar var 90 dagar som standard och oftare för extra känslig data. Eftersom Vault behåller äldre nyckelversioner för dekryptering stör rotation inte redan krypterad data.

Är ML-DSA-certifikat i Vault 2.2.0 redo för produktion?
De är tillgängliga att testa, men de flesta klienter och bibliotek stöder ännu inte postkvantsignaturer fullt ut. Använd dem parallellt med vanliga RSA- eller ECDSA-certifikat under en övergångsperiod snarare än som enda signeringsmetod.

Varför räcker det inte att bara använda miljövariabler för hemligheter?
Miljövariabler löser inte rotation, spårbarhet eller återkallelse. De syns ofta i processlistor, i felloggar och i containerinspektioner, och de ändras bara när en människa manuellt uppdaterar dem. Vault löser alla fyra problemen samtidigt genom att göra hemligheten till en tidsbegränsad resurs istället för en permanent textsträng.

Kan flera team dela samma Vault-installation säkert?
Ja, med rätt policyer och, i Enterprise-versionen, med Namespaces som isolerar team från varandra helt. Utan Namespaces går det fortfarande att separera team med strikta path-baserade policyer, men risken för felkonfiguration ökar ju fler team som delar samma rotstruktur.