Free Press

Målet med det här dokumentet är att rekommendera HashiCorp Vault-implementeringspraxis. Denna referensarkitektur förmedlar en allmän arkitektur som bör anpassas för att tillgodose de specifika behoven i varje implementering.

Följande ämnen behandlas i den här guiden:

• Designsammanfattning
  • Nätverksanslutning
  • Felttolerans
• Rekommenderad arkitektur
  • Enstaka region (Enterprise)
  • Mångfaldstolerans
  • Flera regioner. (företag)
• Arkitektur för bästa fall
  • Distribution av Vault i en tillgänglighetszon (alla)
  • Distribution av Vault i två tillgänglighetszoner (OSS)
  • Distribution av Vault i två tillgänglighetszoner (OSS)
  • Distribution av Vault i en tillgänglighetszon (alla)
  • Distribution av Vault i två tillgänglighetszoner (OSS) två tillgänglighetszoner (Enterprise)
  • Distribution av Vault i tre tillgänglighetszoner (OSS)
• Vault Replication (Enterprise Only)
• Distribution Systemkrav
  • Hårdvara Överväganden
• Lastbalansering
• Att ytterligare referenser

”Ordlista

”Vault Cluster

Ett Vault-kluster är en uppsättning Vault-processer som tillsammans kör en Vault-tjänst.Dessa Vault-processer kan köras på fysiska eller virtuella servrar eller i behållare.

”Consul storage backend cluster

HashiCorp rekommenderar och stöder att Consul används som storage backend förVault. Ett Consul-kluster är en uppsättning Consul-serverprocesser som tillsammans kör enConsul-tjänst. Dessa Consul-processer kan köras på fysiska eller virtuella servrar eller i behållare.

”Tillgänglighetszon

En enskild feldomän på platsnivå som är värd för en del av eller hela ettVault-kluster. Latensen mellan tillgänglighetszoner bör vara < 8 ms för tur och retur. Ett enskilt Vault-kluster kan vara spritt över flera tillgänglighetszoner.

Exempel på en tillgänglighetszon i detta sammanhang är:

• En isolerad datacenter
• En isolerad bur i ett datacenter om den är isolerad från andra burar på alla andra sätt (ström, nätverk etc.)
• En tillgänglighetszon i AWS, Azure eller GCP

”Region

En geografiskt separat samling av en eller flera tillgänglighetszoner. En region är värd för ett eller flera Vault-kluster. Det finns inget definierat krav på maximal latenstid mellan regioner i Vault-arkitekturen. Ett enda Vault-kluster skulle inte spridas över flera regioner.

”Designsammanfattning

Denna design är den rekommenderade arkitekturen för produktionsmiljöer, eftersom den ger flexibilitet och motståndskraft.

Det är en viktig arkitekturrekommendation att Consul-servrarna är åtskilda från Vault-servrarna och att Consul-klustret endast används som lagringsbackend för Vault och inte för annan Consul-fokuserad funktionalitet (t.ex. tjänstesegmentering och tjänsteupptäckt) som kan medföra oförutsägbar resursanvändning. Genom att skilja Vault och Consul åt kan de båda ha ett system som kan dimensioneras på lämpligt sätt när det gäller CPU, minne och diskar. Consul är ett minnesintensivt program och det är därför fördelaktigt att separera det till sina egna resurser för att förhindra att resurserna blir omtvistade eller svälter. Det är också fördelaktigt att dedikera ett Consul-kluster som en backend för Vault-lagring eftersom detta gör det möjligt att uppgradera Consul-klustret endast när det behövs för att förbättra funktionaliteten hos backend för Vault-lagring, vilket troligen kommer att ske mycket mer sällan än i ett Consul-kluster som också används för tjänsteupptäckt och tjänstesegmentering.

Konnektiviteten mellan Vault och Consul-backend går över HTTP och bör säkras med TLS samt en Consul-token för att ge kryptering av all trafik. Se VaultDeployment Guide för mer information. Eftersom Consul-klustret för Vault-lagring kan användas utöver och separat från ettConsul-kluster för tjänsteupptäckt rekommenderas att Consul-processen för lagring körs på portar som inte är standardportar så att den inte kommer i konflikt med andraConsul-funktioner. Detta uppnås genom att ställa in Consul-lagringsklustret så att det körs på portar 7xxx och använda detta som lagringsport i Vault-konfigurationen. Det rekommenderas också att Consul körs med TLS.

”Detaljer om nätverksanslutning

Nedan följer en tabell med krav på nätverkstrafik för Vault-klusternoder.

.

”Alternativa nätverkskonfigurationer

Vault kan konfigureras på flera olika sätt för kommunikation mellanVault- och Consul-klustren:

• Användning av värd-IP-adresser eller värdnamn som kan lösas upp via standard namedsubsystem
• Användning av lastbalanserings-IP-adresser eller värdnamn som kan lösas upp via standard namedsubsystem
• Användning av det anslutna Consul-klustret. DNS som service discovery för att lösa Vaultendpoints
• Användning av ett separat Consul service discovery-kluster DNS som service discovery för att lösa Vaultendpoints

Alla dessa alternativ beskrivs närmare i Vault Deployment Guide.

”Feltolerans

Vault är utformad för att hantera olika felscenarier som har olika sannolikheter. När du installerar ett Vault-kluster bör du ta hänsyn till den feltolerans som du behöver och konstruera för den. I OSS Vault är det rekommenderade antalet instanser 3 i ett kluster eftersom fler instanser skulle ha ett begränsat värde. I Vault Enterprise är det rekommenderade antalet också 3 i ett kluster, men fler kan användas om de är prestandastandbys för att hjälpa till med skrivskyddad arbetsbelastning. Consul-klustret har mellan en och sju instanser.Detta bör vara ett udda antal för att ledningsval alltid skall kunna lösas. Det rekommenderas att Consul-klustret är minst fem instanser som är dedikerade till att utföra backend-lagringsfunktioner endast för Vault-klustret.

”Node

Mjukvaran för Vault- och Consul-klustret möjliggör en feldomän på nodnivå genom att ha replikering inom klustret. I ett enda HA Vault-kluster delar alla noder samma underliggande lagringsbackend och därmed data. Vault löser detta genom att en av Vault-servrarna erhåller en låsning i datalagret för att bli den aktiva Vault-noden som har skrivåtkomst. Om ledaren någon gång går förlorad kommer en annan Vault-nod sömlöst att ta dess plats som ledare. För att uppnå n-2 redundans (där förlusten av två objekt inom felområdet kan tolereras) är den ideala storleken på ett Vault-kluster 3.Consul åstadkommer replikering och ledarskap med hjälp av sina konsensus- och gossip-protokoll. I dessa protokoll väljs en ledare genom konsensus och därför måste det alltid finnas ett aquorum av aktiva servrar. För att uppnå n-2 redundans är den ideala storleken på ett Consul-kluster 5. Se ConsulInternals för mer information.

”Availability Zone

Typisk fördelning i en molnmiljö är att sprida Consul/Vault-noderna till separata Availability Zones (AZ) inom ett nätverk med hög bandbredd och låg latenstid, t.ex. en AWS-region, men detta är kanske inte möjligt i en installation i ett datacenter där det bara finns en DC inom den latensnivå som krävs.

Det är viktigt att förstå en förändring i krav eller bästa praxis som har uppstått som ett resultat av att man går mot ett större utnyttjande av starkt distribuerade system som Consul. När man driver miljöer som består av distribuerade system krävs en förändring i redundanskoefficienten för underliggande komponenter. Consul bygger på konsensusförhandlingar för att organisera och kopiera information, och därför måste miljön tillhandahålla tre unika motståndskraftiga vägar för att ge meningsfull tillförlitlighet. Ett konsensussystem kräver i huvudsak att en enkel majoritet av noderna alltid är tillgängliga. I exemplet med tre noder måste två vara tillgängliga. Om dessa tre noder är placerade i två felområden finns det en 50-procentig chans att en förlust av ett enda felområde skulle resultera i ett fullständigt avbrott.

”Region

För att skydda sig mot ett fel på regionnivå, samt ge ytterligare geografiska skalningsmöjligheter, erbjuder Vault Enterprise:

• Disaster Recovery Replication
• Performance Replication

Se Recommended Patterns on Vault Replication för en fullständig beskrivning av dessa alternativ.

På grund av de begränsningar som anges ovan är den rekommenderade arkitekturen medVault och Consul Enterprise distribuerade över tre tillgänglighetszoner inom ett kluster och för kluster som replikeras över regioner med hjälp av DR- och prestandareplikering. Det finns också flera ”Best Case”-arkitekturer med lösningar för en och två tillgänglighetszoner och även för Consul OSS. Dessa är inte den rekommenderade arkitekturen, men är de bästa lösningarna om din installation begränsas av Consul-versionen eller antalet tillgänglighetszoner.

”Rekommenderad arkitektur

Arkitekturen nedan är det rekommenderade bästa tillvägagångssättet för Vault-installation och bör vara målarkitekturen för alla installationer. Den är uppdelad i två delar:

• Vaultkluster – Detta är den rekommenderade arkitekturen för ett vaultkluster som en enskild enhet, men bör också använda replikering enligt det andra diagrammet
• Vaultreplikering – Detta är den rekommenderade arkitekturen för flera vaultkluster för att möjliggöra regional, prestandaförmåga och katastrofåterställning.

”Single Region Deployment (Enterprise)

I det här scenariot är Vault-noderna och dess associerade Consul-kluster placerade mellan tre tillgänglighetszoner. Den här lösningen har en n-2 på nodnivå för Vault och en n-3 på nodnivå för Consul. På AvailabilityZone-nivå ligger Vault på n-2 och Consul på n-1. Detta skiljer sig från OSS-konceptet genom att Consul-klustret har sex noder med tre av dem som icke röstande medlemmar. Consul-klustret är uppbyggt med hjälp av RedundancyZones så att om någon nod skulle gå sönder skulle en icke-röstande medlem befordras av Autopilot för att bli fullvärdig medlem och på så sätt bibehålla beslutförhet.

”Multiple Region Deployment (Enterprise)

”Referensdiagram Resilience against Region Failure

I det här scenariot replikeras klustren för att skydda sig mot ett fullständigt regionshaveri. Det finns tre kluster för Performance Replica Vault (kluster A, B, C), vart och ett med ett eget DR-kluster (kluster D, E, F) i en annan region. Varje kluster har sitt tillhörande Consul-kluster för lagringsbackend.

Denna arkitektur möjliggör n-2 på regionnivå förutsatt att alla hemligheter och hemlighetsmotorer replikeras över alla kluster. Om hela Region1 misslyckas måste DR-klustret F befordras. När detta har gjorts skulle Vaultsolution vara fullt fungerande med viss förlust av redundans tills Region1 har återställts. Programmen skulle inte behöva autentisera sig på nytt eftersom DR-klustret för varje misslyckat kluster skulle innehålla alla leasingavtal och tokens.

”Referensdiagram Motståndskraft mot klusterfel

Denna lösning har full motståndskraft på klusternivå, men skyddar inte mot regionfel eftersom DR-klustren för prestandareplikerna finns i samma region. Det finns vissa användningsfall där detta är den föredragna metoden när data inte kan replikeras till andra regioner på grund av styrningsrestriktioner som GDPR. Vissa infrastrukturramar har inte heller möjlighet att dirigera applikationstrafik till olika regioner.

”Best Case Architecture

I vissa installationer kan det finnas oöverstigliga begränsningar som innebär att den rekommenderade arkitekturen inte är möjlig. Detta kan bero på brist på tillgängliga zoner eller på att man använder Vault OSS. I dessa fall beskriver arkitekturerna nedan de bästa möjliga alternativen.

Notera att i följande arkitekturer kan Consul-ledaren vara vilken som helst av de fem Consul-servernoderna och den aktiva Vault-noden kan vara vilken som helst av de tre Vault-noderna

”Deployment of Vault in one Availability Zone (all)

I det här scenariot finns alla Vault-noder och dess tillhörande Consul-kluster i en tillgänglighetszon. Den här lösningen har en enda felpunkt på tillgänglighetszonsnivå, men en n-2 på nodnivå för både Consul ochVault. Detta är inte den arkitektur som Hashicorp rekommenderar för produktionssystem eftersom det inte finns någon redundans på tillgänglighetszonsnivå. Det finns inte heller någon DR-funktion och därför bör det åtminstone finnas en DR-replika i en annan region.

”Deployment of Vault in two Availability Zones (OSS)

I det här scenariot är Vault-noderna och det tillhörande Consul-klustret placerade i två tillgänglighetszoner. Den här lösningen har n-2 på nodnivå för Vault och Consul och n-1 för Vault på tillgänglighetszonsnivå, men tillägget av en tillgänglighetszon ökar inte tillgängligheten för Consul-klustret nämnvärt. Detta beror på att Raft-protokollet kräver ett aquorum på (n/2)+1, och om zon B skulle misslyckas i diagrammet ovan skulle klustret inte vara fulltaligt och därmed också misslyckas. Detta är inte den arkitektur som Hashicor rekommenderar för produktionssystem eftersom det endast finns en partiell redundans på tillgänglighetszonsnivå och ett fel i en tillgänglighetszon kanske inte resulterar i ett avbrott.

”Deployment of Vault in two Availability Zones (Enterprise)

På grund av behovet av att upprätthålla quorum i Consul-klustret är det inte idealiskt att endast ha 2 tillgänglighetszoner. Det finns inget sätt att sprida ett Consul-kluster över två zoner med någon garanti för ökad motståndskraft. Den bästa lösningen iVault Enterprise är att behandla de två AZ:erna som regioner och ha separata Vaultkluster i varje.

Det sekundära Vault-klustret kan antingen vara en prestandareplika eller en DR-replika, som båda har sina egna fördelar:

• PR secondary: Om Vault-adressen hanteras av Consul eller av en lastbalansering kommer ett fel på något av klustren att resultera i att trafiken dirigeras till det andra klustret utan att det blir något avbrott, under förutsättning att det finns en logik i programmet eller i Vault-agenten som hanterar återbegärande av token som inte replikeras mellan klustren.
• DR sekundär: I detta fall kommer felet på det primära klustret att leda till att operatören måste ingripa för att befordra DR till det primära klustret, men eftersom alla leaser och tokens replikeras finns det inget behov av någon ytterligare logik i programmet för att hantera detta.

”Utplacering av Vault i tre tillgänglighetszoner (OSS)

I det här scenariot finns noderna i Vault och det tillhörande Consul-klustret i tre tillgänglighetszoner. Denna lösning har n-2 på nodnivå för Vault och Consul och n-2 för Vault på tillgänglighetszonsnivå.Den har också n-1 på tillgänglighetszonsnivå för Consul och anses därför vara den mest motståndskraftiga av alla arkitekturer för ett enskilt Vault-kluster med en Consul-lagringsbackend för OSS-produkten.

”Vault Replication (Enterprise Only)

I dessa arkitekturer illustreras Vault-klustret som en enda enhet och skulle vara ett av de enskilda kluster som beskrivs ovan baserat på antalet tillgänglighetszoner. Flera Vault-kluster som fungerar som en enda Vault-lösning och replikering mellan dem är endast tillgängliga i Enterprise Vault. OSSVault kan konfigureras i flera kluster, men de skulle var och en vara individuella Vault-lösningar och skulle inte stödja replikering mellan kluster.

Dokumentationen om Vault ger mer detaljerad information om replikeringsmöjligheterna i VaultEnterprise.

”Replikering av prestanda

Replikering av prestanda i Vault gör det möjligt att hantera hemligheter över många platser.Statiska hemligheter, autentiseringsmetoder och auktoriseringsprinciper replikeras för att vara aktiva och tillgängliga på flera platser, men leasestokens och dynamiska hemligheter replikeras inte.

”Replikering för katastrofåterställning

Replikering för katastrofåterställning av Vault säkerställer att ett Vault-kluster i reserv är keptsynkroniserat med ett aktivt Vault-kluster. Detta repliklingsläge omfattar data som t.ex. kortvariga autentiserings-tokens, tidsbaserad tokeninformation samt data om tokenanvändning. Detta ger ett aggressivt mål för återställningspunkten i miljöer där det är viktigast att förhindra förlust av flyktiga driftsdata. I alla företagslösningar anses repliker för katastrofåterställning vara nödvändiga.

”Korruption eller sabotage Disaster Recovery

Ett annat vanligt scenario att skydda sig mot, som är vanligare i molnmiljöer som ger mycket höga nivåer av inneboende motståndskraft, kan vara avsiktlig eller oavsiktlig korruption av data och konfiguration och/eller förlust av kontroll över ett molnkonto. Vaults DR-replikering är utformad för att replikera levande data, vilket skulle sprida avsiktlig eller oavsiktlig datakorruption eller radering. För att skydda dig mot dessa möjligheter bör du säkerhetskopiera Vaults lagringsbackend.Detta stöds av ConsulSnapshot-funktionen, som kan automatiseras för regelbundna arkivbackuper. En kall plats eller ny infrastruktur kan återskapas från en Consul-snapshot.

”Replication Notes

Det finns ingen fastställd gräns för antalet kluster inom en replikeringsuppsättning. De största implementeringarna i dag ligger i intervallet 30+ kluster. Ett Performance Replica-kluster kan ha ett Disaster Recovery-kluster associerat med det och kan också replikera till flera Disaster Recovery-kluster.

Ett Vault-kluster kan ha en replikeringsroll (eller roller), men det krävs inga särskilda överväganden när det gäller infrastrukturen, och kluster kan överta (eller befordras eller degraderas) till en annan roll. Särskilda omständigheter i samband med monteringsfilter och användning av Hardware Security Module (HSM) kan begränsa byte av roller, men dessa är baserade på specifika organisationskonfigurationer.

”Överväganden i samband med HSM-integration

Användning av replikering med Vault-kluster som är integrerade med HSM-enheter (Hardware Security Module) eller automatiska avstängningsenheter i molnet för automatisk avstängning av förseglingar har vissa detaljer som bör förstås under planeringsfasen.

• Om ett primärt prestandakluster använder en HSM måste alla andra kluster i replikeringsuppsättningen också använda en HSM.
• Om ett primärt prestandakluster INTE använder en HSM (använder Shamir-principen för hemlighetsdelning) kan klustren inom replikeringsuppsättningen vara blandade, så att vissa kan använda en HSM och andra kan använda Shamir.

Detta beteende är designat. Ett Shamir-kluster nedströms utgör en potentiell angreppsvektor i replikeringsgruppen eftersom ett tröskelvärde för nyckelinnehavare skulle kunna skapa huvudnyckeln och därmed kringgå HSM-nyckelskyddet uppströms.

”Deployment System Requirements

I följande tabell finns riktlinjer för serverdimensionering. Särskilt viktigt är den starka rekommendationen att undvika CPU:er utan fast prestanda, eller BurstableCPU i AWS-termer, t.ex. instanser i T-serien.

”Dimensionering för Vault-servrar

”Dimensionering för Consul-servrar

”Hårdvaruöverväganden

Den lilla storlekskategorin är lämplig för de flesta första produktionsinstallationer eller för utvecklings- och testmiljöer.

Den stora storleken är avsedd för produktionsmiljöer där arbetsbelastningen är konstant hög. Det kan vara ett stort antal transaktioner, ett stort antal hemligheter eller en kombination av de två.

I allmänhet kommer bearbetningskraven att vara beroende av krypteringsarbetsbelastningen och arbetsbelastningen för meddelanden (operationer per sekund och typer av operationer). Minnesbehovet är beroende av den totala storleken på de hemligheter/nycklar som lagras i minnet och bör dimensioneras i enlighet med dessa uppgifter (liksom hårddisklagret). Vault i sig har minimala lagringsbehov, men den underliggande lagringsservicen bör ha ett hårddiskundersystem med relativt hög prestanda.Om många hemligheter genereras/roteras ofta kommer denna information att behöva spolas till disken ofta, vilket kan påverka prestandan om långsammare hårddiskar används.

Consul-serverns funktion i den här installationen är att fungera som lagringsservicen för Vault. Detta innebär att allt innehåll som lagras för persistens i Vault krypteras av Vault och skrivs till lagringsbackend i vila. Dessa data skrivs till nyckelvärdeslagret i Consuls tjänstekatalog, som måste lagras i sin helhet i minnet på varje Consul-server. Detta innebär att minnet kan vara en begränsning vid skalning när fler klienter autentiserar sig till Vault, fler hemligheter lagras permanent i Vault och fler tillfälliga hemligheter hyrs från Vault. Detta har också den effekten att det krävs vertikal skalning av Consul-serverns minne om ytterligare utrymme behövs, eftersom hela tjänstekatalogen lagras i minnet på varje Consul-server.

För övrigt är nätverksgenomströmning ett vanligt problem för Vault- och Consul-servrar. Eftersom båda systemen är HTTPS API-drivna förbrukar alla inkommande förfrågningar, kommunikation mellan Vault och Consul, underliggande skvallerkommunikation mellan Consul-klustermedlemmar, kommunikation med externa system (per auth- eller secretengine-konfiguration och vissa konfigurationer för granskningsloggning) och svar nätverksbandbredd.

På grund av överväganden om nätverksprestanda vid drift av Consul-kluster bör replikering av Vault-datamängder över nätverksgränser ske med hjälp av prestandareplikation eller DR-replikation, snarare än att sprida Consul-klustret över nätverksgränser och fysiska gränser. Om ett enskilt Consul-kluster sprids över nätverkssegment som är avlägsna eller interregionala kan detta orsaka synkroniseringsproblem inom klustret eller ytterligare dataöverföringsavgifter hos vissa molnleverantörer.

”Andra överväganden

Vault Production Hardening Recommendations ger vägledning om bästa praxis för en produktionssäkrad driftsättning avVault.

”Lastbalansering

”Lastbalansering med hjälp av Consul-gränssnittet

Consul kan tillhandahålla lastbalanseringsfunktioner genom tjänsteupptäckt, men det kräver att alla Vault-klienter är medvetna om Consul. Detta innebär att en klient antingen kan använda Consul DNS eller API-gränssnitt för att hitta den aktiva Vault-noden. En klient kan få tillgång till Vault via en URL som följande:http://active.vault.service.consul:8200

Detta är beroende av operativsystemets DNS-upplösningssystem, och begäran kan vidarebefordras till Consul för att få svar på den faktiska IP-adressen. Operationen kan vara helt genomskinlig för äldre program och skulle fungera precis som en vanlig DNS-upplösningsoperation. Se Consul DNSforwarding för mer information

”Lastbalansering med hjälp av extern lastbalansering

Externa lastbalanseringssystem stöds som en ingångspunkt till ett Vault-kluster. Den externa lastbalansenheten bör fråga efter slutpunkten för att upptäcka den aktiva noden och dirigera trafiken i enlighet med detta. Lastbalansen bör konfigureras för att göra en HTTP-förfrågan för följande URL till varje nod i klustret till: http://<Vault Node URL>:8200/v1/sys/health

Den aktiva Vault-noden kommer att svara med ett 200-svar medan standby-noderna returnerar ett 4xx-svar.

Nedan följer ett exempel på ett konfigurationsblock från HAProxy för att illustrera detta:

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

Observera att ovanstående block skulle kunna genereras av Consul (med consul-template)när en mjukvaru-lastbalanserare används. Detta kan vara fallet när lastbalansen är en programvara som Nginx, HAProxy eller Apache.

Exempel på Consul-mall för ovanstående HAProxy-block:

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}}

”Hantering av klient-IP-adresser

Det finns två metoder som stöds för att hantera klient-IP-adressering bakom en proxy eller lastbalansering; X-Forwarded-ForHeadersoch PROXYv1.Båda kräver att en betrodd lastutjämnare och en IP-adress listas som tillåtna adresser för att följa bästa säkerhetspraxis.

”Ytterligare referenser

• Dokumentationen om Vaults arkitektur förklarar varje Vault-komponent
• För att integrera Vault med en befintlig LDAP-server hänvisas till dokumentationen om Auth-metoden för LDAP
• Hänvisa till handledningen AppRole PullAuthentication för att programmeringsmässigt generera en token för en maskin eller en app
• Consul är en integrerad del av att driva ett motståndskraftigt Vault-kluster, oavsett plats. Se Consuld-dokumentationen online för att lära dig mer.

”Nästa steg

• Läs Production Hardening för att lära dig bästa praxis för en produktionshärdningsimplementering av Vault.
• Läs Deployment Guide för att lära dig de steg som krävs för att installera och konfigurera ett enda HashiCorp Vault-kluster.