Free Press

Målet med dette dokument er at anbefale HashiCorp Vault implementeringspraksis. Denne referencearkitektur formidler en generel arkitektur, som bør tilpasses for at imødekomme de specifikke behov i hver enkelt implementering.

De følgende emner behandles i denne vejledning:

• Designresumé
  • Netværksforbindelser
  • Fejletolerance
• Anbefalet arkitektur
  • Deployering i en enkelt region (virksomhed)
  • Multipel region Deployment (Enterprise)
• Best Case Architecture
  • Deployering af Vault i én tilgængelighedszone (alle)
  • Deployering af Vault i to tilgængelighedszoner (OSS)
  • Deployering af Vault i to tilgængelighedszoner (OSS)
  • Deployering af Vault i to tilgængelighedszoner (Enterprise)
  • Distribution af Vault i tre tilgængelighedszoner (OSS)
• Vault-replikering (kun Enterprise)
• Distributionssystemkrav
  • Hardware Overvejelser
• Lastbalancering
• Supplerende referencer

“Ordliste

“Vault-klynge

En Vault-klynge er et sæt Vault-processer, der sammen kører en Vault-tjeneste.Disse Vault-processer kan køre på fysiske eller virtuelle servere eller i containere.

“Consul storage backend cluster

HashiCorp anbefaler og understøtter, at Consul anvendes som storage backend forVault. En Consul-klynge er et sæt af Consul-serverprocesser, der sammen kører enConsul-tjeneste. Disse Consul-processer kan køre på fysiske eller virtuelle servere eller i containere.

“Availability Zone

Et enkelt fejldomæne på et stedniveau, der er vært for en del af eller hele enVault-klynge. Latency mellem tilgængelighedszoner bør være < 8 ms for rundt tur. En enkelt Vault-klynge kan være spredt over flere tilgængelighedszoner.

Eksempler på en tilgængelighedszone i denne sammenhæng er:

• Et isoleret datacenter
• Et isoleret bur i et datacenter, hvis det er isoleret fra andre bure på alle andre måder (strøm, netværk osv.)
• En tilgængelighedszone i AWS, Azure eller GCP

“Region

En geografisk adskilt samling af en eller flere tilgængelighedszoner. En region vil være vært for en eller flere Vault-klynger. Der er ikke noget defineret maksimalt krav til latenstid mellem regioner i Vault-arkitekturen. En enkelt Vault-klynge vil ikke blive spredt ud over flere regioner.

“Designresumé

Dette design er den anbefalede arkitektur til produktionsmiljøer, da det giver fleksibilitet og modstandsdygtighed.

Det er en vigtig arkitekturanbefaling, at Consul-serverne er adskilt fra Vault-serverne, og at Consul-klyngen kun bruges som lagerbackend for Vault og ikke til anden Consul-fokuseret funktionalitet (f.eks. servicesegmentering og service discovery), som kan medføre uforudsigelig ressourceudnyttelse. Ved at adskille Vault og Consul kan hvert system have en passende størrelse med hensyn til CPU, hukommelse og diskplads. Consul er et hukommelsesintensivt program, og det er derfor en fordel at adskille det til sine egne ressourcer for at undgå ressourcekonkurrence eller sult. Det er også en fordel at dedikere en Consul-klynge som en Vault-lagringsbackend, da dette giver mulighed for kun at opgradere Consul-klyngen efter behov for at forbedre Vault-lagringsbackend-funktionaliteten, hvilket sandsynligvis vil være meget sjældnere end en Consul-klynge, der også anvendes til service discovery og service segmentering.

Vault til Consul-backend-forbindelse foregår over HTTP og bør sikres med TLS samt en Consul-token for at sikre kryptering af al trafik. Se VaultDeployment Guide for yderligere oplysninger. Da Consul-klyngen til Vault-lagring kan bruges som supplement til og adskilt fra en Consul-klynge til tjenesteopdagelse, anbefales det, at Consul-processen til lagring køres på andre porte end standardportene, så den ikke kommer i konflikt med andre Consul-funktioner. Dette opnås ved at indstille Consul-lagringsklyngen til at køre på 7xxxporte og bruge dette som lagringsport i Vault-konfigurationen. Det anbefales også, at Consul køres med TLS.

“Detaljer om netværksforbindelser

Den følgende tabel beskriver kravene til netværkstrafik for Vault-klyngenoder.

“Alternative netværkskonfigurationer

Vault kan konfigureres på flere forskellige måder til kommunikation mellemVault- og Consul-klyngerne:

• Anvendelse af værts-IP-adresser eller værtsnavne, der kan opløses via standard-namesubsystem
• Anvendelse af load balancer-IP-adresser eller værtsnavne, der kan opløses via standard-namesubsystem
• Anvendelse af den tilsluttede Consul-klynge DNS som service discovery til at opløse Vaultendpoints
• Ved anvendelse af en separat Consul service discovery-klynge DNS som service discovery til at opløse Vault-endpoints

Alle disse muligheder uddybes yderligere i Vault Deployment Guide.

“Fejltolerance

Vault er designet til at håndtere forskellige fejlscenarier, der har forskellige sandsynligheder. Når du implementerer en Vault-klynge, skal den fejltolerance, som du har brug for, overvejes og designes til. I OSS Vault er det anbefalede antal instanser 3 i en klynge, da flere instanser ville have begrænset værdi. I Vault Enterprise er det anbefalede antal også 3 i en klynge, men der kan bruges flere, hvis de er performancestandbys til at hjælpe med skrivebeskyttet arbejdsbyrde. Consul-klyngen er fra en til syv instanser.Dette bør være et ulige antal for at give mulighed for, at ledelsesvalg altid kan løses. Det anbefales, at Consul-klyngen er mindst fem instanser, som kun er dedikeret til at udføre backend-lagringsfunktioner for Vault-klyngen.

“Node

Vault- og Consul-klyngesoftwaren giver mulighed for et fejldomæne på nodniveau ved at have replikering inden for klyngen. I en enkelt HA Vault-klynge deler alleknuder den samme underliggende storage backend og dermed data. Vault klarer dette ved at en af Vault-serverne opnår en lås i datalageret for at blive den aktive Vault-node, og denne har skriveadgang. Hvis lederen på et eller andet tidspunkt går tabt, vil en anden Vault-node uden problemer overtage dens plads som leder. For at opnå n-2 redundans (hvor tabet af 2 objekter inden for fejlområdet kan tolereres) vil en ideel størrelse for en Vault-klynge være 3.Consul opnår replikering og lederskab ved hjælp af konsensus- og gossip-protokollerne. I disse protokoller vælges en leder ved konsensus, og der skal derfor altid være et aquorum af aktive servere. For at opnå n-2 redundans er den ideelle størrelse på en Consul-klynge 5. Se ConsulInternals for flere detaljer.

“Availability Zone

Typisk fordeling i et cloud-miljø er at sprede Consul/Vault-noderne i separate Availability Zones (AZ’er) inden for et netværk med høj båndbredde og lav latency, f.eks. en AWS-region, men dette er muligvis ikke muligt i en datacenterinstallation, hvor der kun er én DC inden for det krævede latency-niveau.

Det er vigtigt at forstå en ændring i krav eller bedste praksis, der er opstået som følge af udviklingen i retning af større udnyttelse af stærkt distribuerede systemer som Consul. Når man driver miljøer, der består af distribuerede systemer, er der behov for et skift i redundanskoefficienten for de underliggende komponenter. Consul er afhængig af konsensusforhandlinger til at organisere og kopiere information, og derfor skal miljøet give tre unikke resiliente veje for at give en meningsfuld pålidelighed. Et konsensussystem kræver i bund og grund, at et simpelt flertal af knuder til enhver tid er til rådighed. I eksemplet med 3 knuder skal der være 2 knuder til rådighed. Hvis disse 3 knuder er placeret i to fejldomæner, er der 50 % chance for, at tab af et enkelt fejldomæne vil resultere i en fuldstændig afbrydelse.

“Region

For at beskytte mod en fejl på regionsniveau samt give yderligere geografiske skaleringsmuligheder tilbyder Vault Enterprise:

• Disaster Recovery Replication
• Performance Replication

Se de anbefalede mønstre om Vault Replication for at få en fuldstændig beskrivelse af disse muligheder.

På grund af de begrænsninger, der er anført ovenfor, er den anbefalede arkitektur medVault og Consul Enterprise fordelt på tre tilgængelighedszoner inden for en klynge og for klynger, der skal replikeres på tværs af regioner ved hjælp af DR- ogPerformance-replikation. Der findes også flere “Best Case”-arkitekturerløsninger for en og to tilgængelighedszoner og også for Consul OSS. Disse er ikke den anbefalede arkitektur, men er de bedste løsninger, hvis din implementering er begrænset af Consul-versionen eller antallet af tilgængelighedszoner.

“Anbefalet arkitektur

Den nedenstående arkitektur er den anbefalede bedste tilgang til implementering af Vault og bør være målarkitekturen for enhver installation. Den er opdelt i to dele:

• Vault cluster – Dette er den anbefalede arkitektur for en vault cluster som en enkelt enhed, men bør også bruge replikering som i det andet diagram
• Vault replikering – Dette er den anbefalede arkitektur for flere vault clusters for at give mulighed for regional, ydeevne og disaster recovery.

“Single Region Deployment (Enterprise)

I dette scenarie er Vault-noderne og den tilhørende Consul-klynge hostet mellem tre tilgængelighedszoner. Denne løsning har en n-2 på nodeliveau for Vault og en n-3 på nodeliveau for Consul. På AvailabilityZone-niveau er Vault på n-2 og Consul på n-1. Dette adskiller sig fra OSS-designet ved, at Consul-klyngen har seks knuder, hvoraf tre af dem er ikke-stemmende medlemmer. Consul-klyngen er opbygget ved hjælp af RedundancyZones, så hvis en node svigter, vil et ikke-stemmende medlem blive forfremmet af Autopilot til at blive fuldt medlem og dermed opretholde quorum.

“Multiple Region Deployment (Enterprise)

“Reference Diagram Resilience against Region Failure

I dette scenario replikeres klyngerne for at beskytte mod en fuld regionssvigt. Der er tre Performance Replica Vault-klynger (klynger A, B, C) med hver sin egen DR-klynge (klynger D, E, F) i en anden region. Hver klynge har sin tilknyttede Consul-klynge til storage backend.

Denne arkitektur giver mulighed for n-2 på regionsniveau, forudsat at alle hemmeligheder og hemmelige motorer er replikeret på tværs af alle klynger. Hvis den fulde Region1 svigter, vil det kræve, at DR-klyngen F skal forfremmes. Når dette er sket, vil Vaultsolutionen være fuldt funktionsdygtig med et vist tab af redundans, indtil Region1 er blevet genoprettet. Applikationer ville ikke skulle autentificere sig igen, da DR-klyngen for hver fejlslagen klynge ville indeholde alle leases og tokens.

“Referencediagram Resiliens mod klyngesvigt

Denne løsning har fuld resiliens på klyngeniveau, men beskytter ikke mod regionssvigt, da DR-klyngerne for performance-replikkerne er i samme region. Der er visse brugssituationer, hvor dette er den foretrukne metode, når data ikke kan replikeres til andre regioner på grund af styringsrestriktioner såsom GDPR. Nogle infrastrukturrammer har muligvis heller ikke mulighed for at dirigere applikationstrafikken til forskellige regioner.

“Best Case Architecture

I nogle implementeringer kan der være uoverstigelige begrænsninger, der betyder, at den anbefalede arkitektur ikke er mulig. Dette kan skyldes manglende zoner, der ikke er tilgængelige, eller fordi der anvendes Vault OSS. I disse tilfælde beskriver nedenstående arkitekturer de bedste muligheder, der er til rådighed.

Bemærk, at i disse følgende arkitekturer kan Consul-lederen være en af de fem Consul-servernoder, og den aktive Vault-node kan være en af de tre Vault-noder

“Deployment of Vault in one Availability Zone (all)

I dette scenarie er alle Vault-noder og den tilhørende Consul-klynge hostet i én Availability Zone. Denne løsning har et enkelt fejlpunkt på tilgængelighedszoneniveau, men et n-2 på knudeniveau for både Consul ogVault. Dette er ikke den arkitektur, som Hashicorp anbefaler til produktionssystemer, da der ikke er nogen redundans på tilgængelighedszoneniveau. Der er heller ikke nogen DR-mulighed, så der bør som minimum være en DR-replikat i en anden region.

“Deployment of Vault in two Availability Zones (OSS)

I dette scenario er Vault-noderne og den tilhørende Consul-klynge hostet mellem to tilgængelighedszoner. Denne løsning har en n-2 på nodniveau for Vault og Consul og n-1 for Vault på tilgængelighedszoneniveau, men tilføjelsen af en tilgængelighedszone øger ikke tilgængeligheden af Consul-klyngen væsentligt. Dette skyldes, at Raft-protokollen kræver et aquorum på (n/2)+1, og hvis Zone B skulle fejle i ovenstående diagram, ville klumpen ikke være beslutningsdygtig, og den ville derfor også fejle. Dette er ikke den arkitektur, som Hashicor anbefaler til produktionssystemer, da der kun er delvis redundans på tilgængelighedszoneniveau, og en fejl i en tilgængelighedszone kan ikke nødvendigvis resultere i et nedbrud.

“Deployment of Vault in two Availability Zones (Enterprise)

På grund af behovet for at opretholde quorum i Consul-klyngen er det ikke ideelt kun at have 2tilgængelighedszoner. Der er ingen måde at sprede en Consul-klynge over to AZ’er på med nogen garanti for ekstra modstandsdygtighed. Den bedste løsning i Vault Enterprise er at behandle de to AZ’er som regioner og have separate Vaultclusters i hver af dem.

Den sekundære Vault-klynge kan enten være en performance replika eller en DR replika, som hver har sine egne fordele:

• PR sekundær: Hvis Vault-adressen administreres af Consul eller af en load balancer, vil en fejl i en af klyngerne resultere i, at trafikken dirigeres til den anden klynge uden afbrydelse, forudsat at der er logik i din applikation eller i Vault-agenten til at administrere genanmodning af tokens, som ikke replikeres mellem klyngerne.
• DR sekundær: I dette tilfælde vil en fejl i den primære klynge resultere i et behov for operatørintervention for at fremme DR til den primære, men da alle leaser og tokens replikeres, vil der ikke være behov for yderligere logik i programmet til at håndtere dette.

“Udrulning af Vault i tre tilgængelighedszoner (OSS)

I dette scenarie er knuderne i Vault og den tilhørende Consul-klynge hostet mellem tre tilgængelighedszoner. Denne løsning har et n-2 på nodniveau for Vault og Consul og n-2 for Vault på tilgængelighedszoneniveau.Dette har også et n-1 på tilgængelighedszoneniveau for Consul og betragtes som sådan som den mest modstandsdygtige af alle arkitekturer for en enkelt Vault-klynge med en Consul-lagringsbackend for OSS-produktet.

“Vault Replication (Enterprise Only)

I disse arkitekturer er Vault-klyngen illustreret som en enkelt enhed og vil være en af de enkelte klynger, der er beskrevet ovenfor, baseret på antallet af tilgængelighedszoner. Flere Vault-klynger, der fungerer som en enkelt Vaults-løsning og replikerer mellem dem, er kun tilgængelige i Enterprise Vault. OSSVault kan opsættes i flere klynger, men de vil hver især være individuelle Vault-løsninger og vil ikke understøtte replikation mellem klynger.

Dokumentationen om Vault indeholder mere detaljerede oplysninger om replikationsmulighederne i VaultEnterprise.

“Performance Replication

Vault performance replication giver mulighed for styring af hemmeligheder på tværs af mange steder.Statiske hemmeligheder, godkendelsesmetoder og godkendelsespolitikker replikeres for at være aktive og tilgængelige på flere steder, men det gælder ikke for leasestokens og dynamiske hemmeligheder.

“Disaster Recovery Replication

Vault disaster recovery replication sikrer, at en standby Vault-kluster er keptsynkroniseret med en aktiv Vault-kluster. Denne replikeringstilstand omfatter data som f.eks. flygtige autentificeringstokens, tidsbaserede tokenoplysninger samt tokenbrugsdata. Dette giver mulighed for et aggressivt recovery point-mål i miljøer, hvor det er af største betydning at forhindre tab af flygtige driftsdata. I enhver virksomhedsløsning anses disaster recovery-replikker for at være afgørende.

“Korruption eller sabotage Disaster Recovery

Et andet almindeligt scenarie, der skal beskyttes mod, og som er mere udbredt i cloud-miljøer, der giver et meget højt niveau af iboende modstandsdygtighed, kan være forsætlig eller utilsigtet korruption af data og konfiguration og/eller tab af kontrol over en cloud-konto. Vaults DR-replikering er designet til at replikere levende data, hvilket ville sprede forsætlig eller utilsigtet korruption eller sletning af data. For at beskytte dig mod disse muligheder bør du tage backup af Vaults storage backend.Dette understøttes af ConsulSnapshot-funktionen, som kan automatiseres til regelmæssige arkiveringsbackups. Et koldt sted eller en ny infrastrukturkan genhyses fra et Consul-snapshot.

“Replikationsnoter

Der er ingen fastsat grænse for antallet af klynger inden for et replikeringssæt. De største implementeringer i dag er i 30+ klynger. En Performance Replica-klynge kan have en Disaster Recovery-klynge tilknyttet og kan også replikere til flere Disaster Recovery-klynger.

Selv om en Vault-klynge kan have en replikeringsrolle (eller roller), er der ingen særlige overvejelser, der kræves med hensyn til infrastruktur, og klynger kan overtage (eller blive forfremmet eller degraderet) til en anden rolle. Særlige omstændigheder i forbindelse med monteringsfiltre og brug af hardware-sikkerhedsmodul (HSM) kan begrænse overflytning af roller, men disse er baseret på specifikke organisationskonfigurationer.

“Overvejelser i forbindelse med HSM-integration

Anvendelse af replikering med Vault-klynger, der er integreret med hardware-sikkerhedsmodul (HSM) eller automatiske cloud-enheder til automatiserede oplukningsoperationer, har nogle detaljer, der skal forstås i planlægningsfasen.

• Hvis en primær performanceklynge bruger en HSM, skal alle andre klynger i det replikeringssæt også bruge en HSM.
• Hvis en primær performanceklynge IKKE bruger en HSM (bruger Shamir secretsharing-metoden), kan klyngerne inden for det replikeringssæt være blandet, således at nogle kan bruge en HSM, andre kan bruge Shamir.

Denne opførsel er designet. En nedstrøms Shamir-klynge udgør en potentiel angrebsvektor i replikationsgruppen, da en tærskel af nøgleindehavere kan genskabe hovednøglen og dermed omgå den opstrøms HSM-nøglebeskyttelse.

“Deployment System Requirements

Den følgende tabel indeholder retningslinjer for serverdimensionering. Særligt bemærkelsesværdigt erden stærke anbefaling om at undgå CPU’er uden fast ydeevne, eller BurstableCPU i AWS-termer, såsom T-series-instanser.

“Sizing for Vault Servers

“Sizing for Consul Servers

“Hardwareovervejelser

Den lille størrelseskategori vil være passende for de fleste indledende produktionsimplementeringer eller for udviklings-/testmiljøer.

Den store størrelse er for produktionsmiljøer, hvor der er en konstant høj arbejdsbyrde. Det kan være et stort antal transaktioner, et stort antal hemmeligheder eller en kombination af de to.

Generelt vil behandlingskravene være afhængige af arbejdsbyrden for kryptering og arbejdsbyrden for meddelelser (operationer pr. sekund og typer af operationer). Hukommelsesbehovet vil afhænge af den samlede størrelse af de hemmeligheder/nøgler, der er lagret i hukommelsen, og bør dimensioneres i overensstemmelse med disse data (ligesom harddisklageret bør dimensioneres). Vault selv har minimale krav til lagring, men det underliggende storage backend bør have et harddisksubsystem med relativt høj ydeevne.Hvis der genereres/roteres mange hemmeligheder hyppigt, skal disse oplysninger flushes til disken ofte, og det kan påvirke ydeevnen, hvis der anvendes langsommere harddiske.

Consul-serverens funktion i denne implementering er at fungere som storage backend for Vault. Det betyder, at alt indhold, der lagres med henblik på persistens i Vault, krypteres af Vault og skrives til storage backend’en i hvile. Disse data skrives til key-value store-afsnittet i Consuls servicekatalog, som skal gemmes i sin helhed i hukommelsen på hver Consul-server. Det betyder, at hukommelsen kan være en begrænsning i forbindelse med skalering, efterhånden som flere klienter autentificerer sig til Vault, flere hemmeligheder lagres vedvarende i Vault, og flere midlertidige hemmeligheder lejes fra Vault. Dette har også den virkning, at der kræves vertikal skalering af Consul-serverens hukommelse, hvis der er behov for yderligere plads, da hele servicekataloget gemmes i hukommelsen på hver Consul-server.

Dertil kommer, at netværksgennemstrømning er en fælles overvejelse for Vault- og Consul-servere. Da begge systemer er HTTPS API-drevne, bruger alle indgående anmodninger, kommunikation mellem Vault og Consul, underliggende sladderkommunikation mellem Consul-klyngemedlemmer, kommunikation med eksterne systemer (pr. auth- eller secretengine-konfiguration og nogle konfigurationer af auditlogning) og svar netværksbåndbredde.

På grund af overvejelser om netværksydelse i Consul-klyngedrift bør replikering af Vault-datasæt på tværs af netværksgrænser opnås gennem Performance- eller DR-replikering i stedet for at sprede Consul-klyngen på tværs af netværk og fysiske grænser. Hvis en enkelt Consul-klynge spredes på tværs af netværkssegmenter, der ligger langt fra hinanden eller er interregionale, kan dette forårsage synkroniseringsproblemer i klyngen eller yderligere dataoverførselsgebyrer hos nogle cloud-udbydere.

“Andre overvejelser

Vault Production Hardening Recommendationsgiver vejledning om bedste praksis for en produktionshærdet implementering afVault.

“Belastningsbalancering

“Belastningsbalancering ved hjælp af Consul-grænseflade

Consul kan levere belastningsbalanceringsfunktioner gennem serviceopdagelse, men det kræver, at alle Vault-klienter er Consul-kender. Det betyder, at en klient enten kan bruge Consul DNS eller API-grænseflader til at finde den aktive Vault-knude. En klient kan få adgang til Vault via en URL som følgende:http://active.vault.service.consul:8200

Dette er afhængig af operativsystemets DNS-opløsningssystem, og anmodningen kan videresendes til Consul for at få svar på den faktiske IP-adresse. Operationen kan være fuldstændig gennemsigtig for ældre applikationer og vil fungere som en typisk DNS-opløsningsoperation. Se Consul DNSforwarding for yderligere oplysninger

“Load Balancing Using External Load Balancer

External load balancers understøttes som et indgangspunkt til en Vault-klynge. Den eksterne load balancer skal spørge til thesys/health-slutpunktet for at registrere den aktive knude og videresende trafikken i overensstemmelse hermed. Belastningsbalanceren skal være konfigureret til at sende en HTTP-forespørgsel for følgende URL til hver knude i klyngen til: http://<Vault Node URL>:8200/v1/sys/health

Den aktive Vault-node vil svare med et 200-svar, mens standby-noderne vil returnere et 4xx-svar.

Det følgende er en prøvekonfigurationsblok fra HAProxy til illustration:

listen vault bind 0.0.0.0:80 balance roundrobin option httpchk GET /v1/sys/health server vault1 192.168.33.10:8200 check server vault2 192.168.33.11:8200 check server vault3 192.168.33.12:8200 check

Bemærk, at ovenstående blok kan genereres af Consul (med consul-template)når der anvendes en software-load balancer. Dette kan være tilfældet, når loadbalanceren er software som Nginx, HAProxy eller Apache.

Eksempel på Consul-skabelon for ovenstående HAProxy-blok:

listen vault bind 0.0.0.0:8200 balance roundrobin option httpchk GET /v1/sys/health{{range service "vault"}} server {{.Node}} {{.Address}}:{{.Port}} check{{end}}

“Håndtering af klient-IP-adresse

Der er to understøttede metoder til håndtering af klient-IP-adressering bag en proxy eller load balancer; X-Forwarded-ForHeadersog PROXYv1.Begge kræver en pålidelig load balancer og en IP-adresse, der skal være opført som tilladteadresser for at overholde bedste sikkerhedspraksis.

“Yderligere referencer

• Dokumentationen om Vaults arkitektur forklarer hver enkelt Vault-komponent
• For at integrere Vault med eksisterende LDAP-server henvises til dokumentationen om LDAP Auth-metoden
• Referer til vejledningen AppRole PullAuthentication for programmatisk at generere et token til en maskine eller app
• Consul er en integreret del af driften af en modstandsdygtig Vault-klynge, uanset lokation. Se online Consuld-dokumentationen for at lære mere.

“Næste trin

• Læs Production Hardening for at lære bestpractices for en produktionshærdningsimplementering af Vault.
• Læs Deployment Guide for at lære de trin, der kræves for at installere og konfigurere en enkelt HashiCorp Vault-klynge.