Free Press

Het doel van dit document is het aanbevelen van HashiCorp Vault implementatiepraktijken. Deze referentiearchitectuur geeft een algemene architectuur weer die moet worden aangepast aan de specifieke behoeften van elke implementatie.

De volgende onderwerpen komen in deze gids aan de orde:

• Ontwerpsamenvatting
  • Netwerkconnectiviteit
  • Failure Tolerance
• Aanbevolen architectuur
  • Single Region Deployment (Enterprise)
  • Multiple Region Deployment (Enterprise)
• Best Case Architecture
  • Deployment van Vault in één beschikbaarheidszone (all)
  • Deployment van Vault in twee beschikbaarheidszones (OSS)
  • Deployment van Vault in twee beschikbaarheidszones (Enterprise)
  • Deployment van Vault in twee beschikbaarheidszones (Enterprise)
  • Opstelling van Vault in drie beschikbaarheidszones (OSS)
• Vault replicatie (alleen Enterprise)
• Systeemvereisten voor opstelling
  • Hardware Overwegingen
• Load Balancing
• Aanvullende referenties

“Glossary

“Vault Cluster

Een Vault cluster is een verzameling Vault processen die samen een Vault service draaien.Deze Vault-processen kunnen worden uitgevoerd op fysieke of virtuele servers, of in containers.

“Consul storage backend cluster

HashiCorp beveelt aan en ondersteunt het gebruik van Consul als het storage backend voorVault. Een Consul-cluster bestaat uit een aantal Consul-serverprocessen die samen een Consul-service draaien. Deze Consul-processen kunnen worden uitgevoerd op fysieke of virtualservers, of in containers.

“Availability Zone

Een enkelvoudig storingsdomein op locatieniveau dat een deel van, of alle van eenVault-cluster host. De latentie tussen beschikbaarheidszones zou < 8ms voor rondreis moeten zijn. Een enkel Vault-cluster kan over meerdere beschikbaarheidszones zijn gespreid.

Voorbeelden van een beschikbaarheidszone in deze context zijn:

• Een geïsoleerd datacenter
• Een geïsoleerde kooi in een datacenter als deze op alle andere manieren (stroom, netwerk, etc)
• Een beschikbaarheidszone in AWS, Azure of GCP

“Regio

Een geografisch afgescheiden verzameling van een of meer beschikbaarheidszones. Een regio kan een of meer Vault-clusters hosten. Er is geen gedefinieerde maximale latentie-eis tussen regio’s in de Vault-architectuur. Een enkel Vault-cluster wordt niet over meerdere regio’s verspreid.

“Design Summary

Dit ontwerp is de aanbevolen architectuur voor productieomgevingen, omdat het flexibiliteit en veerkracht biedt.

Het is een belangrijke aanbeveling voor de architectuur dat de Consul servers gescheiden zijn van de Vault servers en dat het Consul cluster alleen wordt gebruikt als een opslag backend voor Vault en niet voor andere Consul-gerichte functionaliteit (b.v. service-egmentatie en service discovery) die onvoorspelbaar resource-gebruik kan introduceren. Door Vault en Consul van elkaar te scheiden, kunnen beide een systeem krijgen dat de juiste grootte heeft wat betreft CPU, geheugen en schijfruimte. Consul is een geheugenintensieve toepassing en dus is het scheiden ervan naar zijn eigen bronnen voordelig om resource contention of starvation te voorkomen. Een Consul cluster aanwijzen als Vault storage backend is ook voordelig, omdat het Consul cluster dan alleen kan worden geüpgraded als dat nodig is om de Vault storage backend functionaliteit te verbeteren. Dit zal waarschijnlijk veel minder vaak nodig zijn dan een Consul cluster dat ook wordt gebruikt voor service discovery en service segmentatie.

Vault naar Consul backend connectiviteit verloopt via HTTP en dient te worden beveiligd met TLS, alsmede met een Consul token om encryptie van al het verkeer te verschaffen. Zie de Vault-deployment guide voor meer informatie. Aangezien het Consul-cluster voor Vault storage naast en los van een Consul-cluster voor service discovery kan worden gebruikt, wordt aanbevolen het storage Consul-proces op niet-standaard poorten te laten draaien, zodat het niet conflicteert met andere Consul-functionaliteit. Door het Consul storage cluster op 7xxxpoorten te laten draaien en dit als de storage poort in de Vault configuratie te gebruiken wordt dit bereikt. Het wordt ook aanbevolen om Consul met TLS uit te voeren.

“Details netwerkverbindingen

De volgende tabel geeft een overzicht van de vereisten voor netwerkverkeer voor Vault-clusternodes.

“Alternatieve netwerkconfiguraties

Vault kan op verschillende manieren worden geconfigureerd voor communicatie tussen deVault- en Consul-clusters:

• Gebruik van host IP-adressen of hostnamen die via een standaard naamsubsysteem kunnen worden opgelost
• Gebruik van load balancer IP-adressen of hostnamen die via een standaard naamsubsysteem kunnen worden opgelost
• Gebruik van het gekoppelde Consul cluster DNS als service discovery om Vault endpoints op te lossen
• Een aparte Consul service discovery cluster gebruiken DNS als service discovery om Vault endpoints op te lossen

Al deze opties worden verder uitgewerkt in de Vault Deployment Guide.

“Tolerantie bij storingen

Vault is ontworpen om met verschillende storingsscenario’s met verschillende waarschijnlijkheden om te gaan. Bij de implementatie van een Vault-cluster moet rekening worden gehouden met de vereiste storingstolerantie en moet daarvoor een ontwerp worden gemaakt. In OSS Vault is het aanbevolen aantal instanties 3 in een cluster, omdat meer instanties slechts een beperkte waarde hebben. InVault Enterprise is het aanbevolen aantal ook 3 in een cluster, maar er kunnen er meer worden gebruikt als zij prestatiestandaarden zijn om te helpen met read-only werkbelasting. Het Consul-cluster bestaat uit één tot zeven instanties. Dit moet een oneven aantal zijn, zodat leiderschapsverkiezingen altijd kunnen worden opgelost. Het wordt aanbevolen dat het Consul-cluster uit ten minste vijf instanties bestaat die alleen back-end opslagfuncties voor het Vault-cluster uitvoeren.

“Node

De Vault- en Consul-clustersoftware maakt een storingsdomein op het niveau van de knooppunten mogelijk door replicatie binnen het cluster. In een enkel HA Vault cluster delen alle knooppunten dezelfde onderliggende storage backend en dus gegevens. Vault ondervangt dit door een van de Vault servers een lock te laten verkrijgen in de dataopslag om de actieve Vault node te worden en deze heeft schrijftoegang. Als op enig moment de leider wegvalt, zal een andere Vault node naadloos zijn plaats als leider innemen. Om n-2 redundantie te bereiken (waarbij het verlies van 2 objecten binnen het failure domain getolereerd kan worden), zou een ideale grootte voor een Vault cluster 3 zijn. Consul bereikt replicatie en leiderschap door het gebruik van zijn consensus en gossip protocollen. In deze protocollen wordt een leider bij consensus gekozen en moet er dus altijd een aquorum van actieve servers zijn. Om n-2 redundantie te bereiken, is een ideale grootte van een Consul cluster 5. Zie ConsulInternals voor meer details.

“Availability Zone

Typische distributie in een cloud omgeving is om Consul/Vault nodes te verspreiden over verschillende Availability Zones (AZs) binnen een hoge bandbreedte, lage latency netwerk, zoals een AWS Region, maar dit kan niet mogelijk zijn in een datacenter installatie waar er slechts een DC is binnen het vereiste niveau van latency.

Het is belangrijk om een verandering in vereisten of best practices te begrijpen die is ontstaan als gevolg van de verschuiving naar meer gebruik van sterk gedistribueerde systemen zoals Consul. Wanneer omgevingen worden geëxploiteerd die uit gedistribueerde systemen bestaan, is een verschuiving vereist in de redundantiecoëfficiënt van onderliggende componenten. Consul vertrouwt op consensusonderhandelingen om informatie te organiseren en te repliceren en dus moet de omgeving 3 unieke veerkrachtige paden voorzien om een betekenisvolle betrouwbaarheid te bieden. In wezen vereist een consensussysteem dat een eenvoudige meerderheid van knooppunten op elk moment beschikbaar is. In het voorbeeld van 3 nodes, moeten er 2 beschikbaar zijn. Als die 3 nodes in twee faaldomeinen worden geplaatst, is er een kans van 50% dat het verlies van één faaldomein zou resulteren in een volledige uitval.

“Regio

Om bescherming te bieden tegen een storing op regioniveau, alsmede aanvullende geografische schaalmogelijkheden te bieden, biedt Vault Enterprise:

• Disaster Recovery Replication
• Performance Replication

Raadpleeg de Aanbevolen patronen voor Vault Replication voor een volledige beschrijving van deze opties.

Omwille van de hierboven vermelde beperkingen is de aanbevolen architectuur voor Vault en Consul Enterprise verdeeld over drie beschikbaarheidszones binnen een cluster en voor clusters die over regio’s worden gerepliceerd met DR- en performantiereplicatie. Er zijn ook verschillende “Best Case” architectuuroplossingen voor één en twee beschikbaarheidszones en ook voor Consul OSS. Deze zijn niet de aanbevolen architectuur, maar zijn de beste oplossingen als uw implementatie wordt beperkt door de Consul versie of het aantal beschikbaarheidszones.

“Aanbevolen Architectuur

De onderstaande architectuur is de aanbevolen beste benadering voor de implementatie van Vault en zou de doelarchitectuur voor elke installatie moeten zijn. Deze is opgesplitst in twee delen:

• Vault cluster – Dit is de aanbevolen architectuur voor een vault cluster als enkele entiteit, maar zou ook replicatie moeten gebruiken zoals volgens het tweede diagram
• Vault replicatie – Dit is de aanbevolen architectuur voor meerdere vaultclusters om regionaal, prestatie- en rampherstel mogelijk te maken.

“Single Region Deployment (Enterprise)

In dit scenario worden de Vault-nodes en het bijbehorende Consul-cluster gehost tussen drie beschikbaarheidszones. Deze oplossing heeft een n-2 op het niveau van knooppunten voor Vault en een n-3 op het niveau van knooppunten voor Consul. Op het niveau van de beschikbaarheidszone staat Vault op n-2 en Consul op n-1. Dit wijkt af van het OSS-ontwerp in die zin dat het Consul-cluster zes knooppunten heeft, waarvan er drie als niet-stemmend lid fungeren. Het Consul-cluster is opgezet met behulp van Redundantiezones, zodat als een node uitvalt, een lid zonder stemrecht door Autopilot wordt gepromoveerd tot volwaardig lid en zo het quorum wordt gehandhaafd.

“Multiple Region Deployment (Enterprise)

“Reference Diagram Resilience against Region Failure

In dit scenario worden de clusters gerepliceerd als bescherming tegen het uitvallen van een volledige regio. Er zijn drie Performance Replica Vault-clusters (clusters A, B, C), elk met een eigen DR-cluster (clusters D, E, F) in een andere regio. Elk cluster heeft zijn eigen Consul-cluster voor opslagbackend.

Deze architectuur maakt n-2 op regioniveau mogelijk, mits alle secrets en secrets engines over alle clusters worden gerepliceerd. Bij uitval van de volledige Region1 zou de DR cluster F moeten worden gepromoveerd. Zodra dit is gebeurd, zou de Vaultsolution volledig functioneel zijn met enig verlies van redundantie totdat de Region1 is hersteld. Toepassingen hoeven zich niet opnieuw te authenticeren omdat de DR-cluster voor elke gefaalde cluster alle leases en tokens bevat.

“Reference Diagram Resilience against Cluster Failure

Deze oplossing biedt volledige veerkracht op clusterniveau, maar biedt geen bescherming tegen regio-falen omdat de DR-clusters voor de prestatiereplica’s zich in dezelfde regio bevinden. Er zijn bepaalde use-cases waarin dit de voorkeursmethode is wanneer gegevens niet naar andere regio’s kunnen worden gerepliceerd als gevolg van governancebeperkingen zoals GDPR. Ook kunnen sommige infrastructuurframeworks niet de mogelijkheid hebben om applicatieverkeer naar verschillende regio’s te routeren.

“Best Case Architecture

In sommige implementaties kunnen er onoverkomelijke beperkingen zijn die betekenen dat de aanbevolen architectuur niet mogelijk is. Dit kan te wijten zijn aan een gebrek aan beschikbare zones of aan het gebruik van Vault OSS. In deze gevallen geven de onderstaande architecturen de beste beschikbare opties weer.

Merk op dat in deze volgende architecturen de Consul-leider een van de vijf Consul-servernodes kan zijn en het actieve Vault-knooppunt een van de drie Vault-nodes

“Implementatie van Vault in één beschikbaarheidszone (alle)

In dit scenario worden alle Vault-nodes en het bijbehorende Consul-cluster binnen één beschikbaarheidszone gehost. Deze oplossing heeft een single point of failure op het niveau van de beschikbaarheidszone, maar een n-2 op het niveau van de node voor zowel Consul als Vault. Dit is geen door Hashicorp aanbevolen architectuur voor productiesystemen, omdat er geen redundantie is op het niveau van de beschikbaarheidszone. Ook is er geen DR-mogelijkheid, dus zou er minimaal een DR-replica in een aparte regio moeten zijn.

“Deployment of Vault in two Availability Zones (OSS)

In dit scenario worden de Vault-nodes en het bijbehorende Consul-cluster tussen twee Availability Zones gehost. Deze oplossing heeft een n-2 op het niveau van knooppunten voor Vault en Consul en n-1 voor Vault op het niveau van beschikbaarheidszones, maar de toevoeging van een beschikbaarheidszone verhoogt de beschikbaarheid van het Consul-cluster niet significant. Dit komt doordat het Raft-protocol een quorum van (n/2)+1 vereist en als Zone B in het bovenstaande diagram zou uitvallen, zou het cluster niet quorum zijn en dus ook uitvallen. Dit is geen door Hashicorp aanbevolen architectuur voor productiesystemen, omdat er slechts gedeeltelijke redundantie is op het niveau van de beschikbaarheidszone en een storing in de beschikbaarheidszone mogelijk niet tot uitval leidt.

“Implementatie van Vault in twee beschikbaarheidszones (Enterprise)

Vanwege de noodzaak om het quorum in het Consul-cluster te handhaven, is het niet ideaal om slechts twee beschikbaarheidszones te hebben. Er is geen manier om een Consul-cluster over twee AZ’s te spreiden met enige garantie op extra veerkracht. De beste oplossing inault Enterprise is om de twee AZ’s als regio’s te behandelen en in elke regio afzonderlijke Vaultclusters te hebben.

De secundaire Vault cluster kan een Performance Replica of een DR Replica zijn, die elk hun eigen voordelen hebben:

• PR secondary: Als het Vault adres door Consul of door een load balancer wordt beheerd, dan zal een storing in een van beide clusters tot gevolg hebben dat het verkeer zonder uitval naar de andere cluster wordt geleid, mits er logica in de applicatie of de Vault agent is om het opnieuw aanvragen van tokens te beheren die niet tussen de clusters worden gerepliceerd.
• DR secondary: In dit geval zal het uitvallen van het primaire cluster tot gevolg hebben dat de operator moet ingrijpen om de DR tot het primaire cluster te promoveren, maar aangezien alle leases en tokens worden gerepliceerd, zou er geen extra logica in de applicatie nodig zijn om dit af te handelen.

“Deployment van Vault in drie beschikbaarheidszones (OSS)

In dit scenario worden de nodes in Vault en het bijbehorende Consul-cluster tussen drie beschikbaarheidszones gehost. Deze oplossing heeft een n-2 op het niveau van de nodes voor Vault en Consul en een n-2 voor Vault op het niveau van de beschikbaarheidszone. Deze oplossing heeft ook een n-1 op het niveau van de beschikbaarheidszone voor Consul en wordt als zodanig beschouwd als de meest veerkrachtige van alle architecturen voor een enkel Vault-cluster met een Consul storage backend voor het OSS-product.

“Vault Replication (Enterprise Only)

In deze architecturen wordt de Vault Cluster als een enkele entiteit geïllustreerd, en zou een van de enkele clusters zijn die hierboven zijn beschreven op basis van uw aantal beschikbaarheidszones. Meerdere Vault clusters die als een enkele Vault oplossing fungeren en onderling repliceren is alleen beschikbaar in Enterprise Vault. OSSVault kan in meerdere clusters worden opgezet, maar dit zijn dan afzonderlijke Vault-oplossingen en ondersteunen geen replicatie tussen clusters.

De Vaultdocumentatie bevat meer gedetailleerde informatie over de replicatiemogelijkheden binnen VaultEnterprise.

“Performance Replication

Vault performance replication maakt het beheer van geheimen over vele locaties mogelijk.Statische secrets, authenticatiemethoden en autorisatiebeleid worden gerepliceerd om op meerdere locaties actief en beschikbaar te zijn, maar leasestokens en dynamische secrets niet.

“Replicatie bij noodherstel

Replicatie bij noodherstel van Vault zorgt ervoor dat een stand-by Vault-cluster keptsynchroon is met een actief Vault-cluster. Deze replicatiemodus omvat gegevens zoals efemere authenticatietokens, tijdgebaseerde tokeninformatie en gegevens over tokengebruik. Dit zorgt voor een agressieve herstelpuntdoelstelling in omgevingen waar het voorkomen van verlies van efemere operationele gegevens van het grootste belang is. In elke bedrijfsoplossing worden Disaster Recovery Replicas als essentieel beschouwd.

“Rampherstel door corruptie of sabotage

Een ander veelvoorkomend scenario waartegen bescherming moet worden geboden, dat vaker voorkomt in cloudomgevingen die zeer hoge niveaus van intrinsieke veerkracht bieden, kan de opzettelijke of onopzettelijke corruptie van gegevens en configuratie zijn, en/of een verlies van controle over cloudaccounts. DR-replicatie van Vault is ontworpen om live gegevens te repliceren, waardoor opzettelijke of onopzettelijke gegevenscorruptie of -verwijdering zou worden vermeerderd. Om u tegen deze mogelijkheden te beschermen, moet u een back-up maken van de storage backend van Vault. Dit wordt ondersteund door de ConsulSnapshot-functie, die kan worden geautomatiseerd voor regelmatige archiefback-ups. Een koude site of nieuwe infrastructuur kan opnieuw worden gehydrateerd vanuit een Consul-snapshot.

“Replicatieopmerkingen

Er is geen vaste limiet voor het aantal clusters binnen een replicatieset. De grootste implementaties liggen tegenwoordig in het bereik van 30+ clusters. Een Performance Replica-cluster kan een Disaster Recovery-cluster hebben en kan ook naar meerdere Disaster Recovery-clusters repliceren.

Terwijl een Vault-cluster een replicatierol (of rollen) kan hebben, zijn er geen speciale overwegingen vereist in termen van infrastructuur, en clusters kunnen een andere rol aannemen (of worden gepromoveerd of gedegradeerd). Speciale omstandigheden met betrekking tot mount filters en Hardware Security Module (HSM) gebruik kunnen het wisselen van rollen beperken, maar die zijn gebaseerd op specifieke organisatie configuraties.

“Considerations Related to HSM Integration

Het gebruik van replicatie met Vault clusters geïntegreerd met Hardware Security Module (HSM) of cloud auto-unseal apparaten voor geautomatiseerde unseal operaties heeft een aantal details die begrepen moeten worden tijdens de planningsfase.

• Als een performance primary cluster een HSM gebruikt, moeten alle andere clusters binnen die replicatieset ook een HSM gebruiken.
• Als een prestatiegerelateerd primair cluster GEEN HSM gebruikt (het gebruikt de Shamir-methode voor het delen van geheimen), kunnen de clusters binnen die replicatieset gemengd zijn, zodat sommige een HSM gebruiken en andere een Shamir.

Dit gedrag is zo ontworpen. Een stroomafwaarts Shamir-cluster vormt een potentiële aanvalsvector in de replicatiegroep, aangezien een drempel van sleutelhouders de hoofdsleutel zou kunnen maken en zo de stroomopwaartse HSM-sleutelbescherming zou kunnen omzeilen.

“Deployment System Requirements

De volgende tabel bevat richtlijnen voor de grootte van de server. Het is met name raadzaam om CPU’s met een niet-vaste prestatie te vermijden, of BurstableCPU in AWS-termen, zoals instances uit de T-serie.

“Sizing for Vault Servers

“Sizing for Consul Servers

“Hardware Considerations

De categorie kleine afmetingen zou geschikt zijn voor de meeste initiële productie-implementaties, of voor ontwikkelings-/testomgevingen.

Het grote formaat is voor productie-omgevingen waar sprake is van een consistente hoge werklast. Dat kan een groot aantal transacties zijn, een groot aantal geheimen, of een combinatie van die twee.

In het algemeen zijn de verwerkingsvereisten afhankelijk van de encryptie- en berichtenwerkbelasting (bewerkingen per seconde, en soorten bewerkingen). De geheugenbehoefte hangt af van de totale omvang van de in het geheugen opgeslagen geheimen/sleutels en moet op die gegevens worden afgestemd (evenals de opslagruimte op de harde schijf). Vault zelf heeft minimale opslagvereisten, maar het onderliggende opslagsysteem moet een relatief goed presterend subsysteem voor harde schijven hebben. Als er veel geheimen worden gegenereerd/geroteerd, moet deze informatie vaak naar de schijf worden gespoeld, wat de prestaties kan beïnvloeden als langzamere harde schijven worden gebruikt.

De functie van de Consul servers in deze implementatie is om als opslagsysteem voor Vault te fungeren. Dit betekent dat alle inhoud die voor persistentie in Vault wordt opgeslagen, door Vault wordt versleuteld en in rust naar het opslagbackend wordt geschreven. Deze gegevens worden weggeschreven naar de key-value store sectie van Consul’s Service Catalog, die in zijn geheel in het geheugen op elke Consul server moet worden opgeslagen. Dit betekent dat geheugen een beperking kan zijn bij het schalen naarmate meer cliënten zich authenticeren bij Vault, meer geheimen persistent in Vault worden opgeslagen, en meer tijdelijke geheimen van Vault worden gehuurd. Dit heeft ook tot gevolg dat het geheugen van de Consul server verticaal moet worden opgeschaald als extra ruimte nodig is, omdat de volledige ServiceCatalog in het geheugen van elke Consul server wordt opgeslagen.

Daarnaast is netwerkdoorvoer een gemeenschappelijke overweging voor Vault en Consulservers. Aangezien beide systemen door HTTPS API worden gestuurd, verbruiken alle inkomende verzoeken, de communicatie tussen Vault en Consul, de onderliggende roddelcommunicatie tussen de Consul cluster leden, de communicatie met externe systemen (per auth of secretengine configuratie, en sommige audit logging configuraties) en de antwoorden netwerkbandbreedte.

Omwille van netwerkprestatie overwegingen bij Consul cluster operaties, moet replicatie van Vault datasets over netwerkgrenzen worden bereikt door Performance of DR Replicatie, in plaats van het verspreiden van het Consul cluster over netwerk en fysieke grenzen. Als een enkel Consul-cluster wordt verspreid over verafgelegen of interregionale netwerksegmenten, kan dit leiden tot synchronisatieproblemen binnen het cluster of extra kosten voor gegevensoverdracht bij sommige cloudproviders.

“Overige overwegingen

Vault Production Hardening Recommendationsbiedt richtlijnen voor de beste werkwijzen voor een productieversterkte implementatie vanVault.

“Load Balancing

“Load Balancing Using Consul Interface

Consul kan load balancing-mogelijkheden bieden via service discovery, maar vereist dat alle Vault-clients Consul aware zijn. Dit betekent dat een client de Consul DNS of API interfaces kan gebruiken om de actieve Vault node te vinden. Een client kan Vault benaderen via een URL als de volgende:http://active.vault.service.consul:8200

Dit is afhankelijk van het DNS-resolutiesysteem van het besturingssysteem, en het verzoek kan naar Consul worden doorgestuurd voor het daadwerkelijke IP-adresantwoord. De operatie kan volledig transparant zijn voor legacy applicaties en zou net zo werken als een atypische DNS resolutie operatie. Zie Consul DNS-forwarding voor meer informatie

“Load Balancing Using External Load Balancer

Externe load balancers worden ondersteund als ingang naar een Vault-cluster. De externe loadbalancer moet het sys/health-eindpunt pollen om het actieve knooppunt te detecteren en het verkeer dienovereenkomstig te routeren. De loadbalancer moet worden geconfigureerd om een HTTP-verzoek voor de volgende URL naar elk knooppunt in het cluster te sturen: http://<Vault Node URL>:8200/v1/sys/health

De actieve Vault-node antwoordt met een 200 terwijl de standby-node een 4xx-antwoord terugstuurt.

Het volgende is een voorbeeld van een configuratieblok van HAProxy ter illustratie:

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

Merk op dat het bovenstaande blok kan worden gegenereerd door Consul (met consul-template)wanneer een software load balancer wordt gebruikt. Dit kan het geval zijn wanneer de loadbalancer software is zoals Nginx, HAProxy of Apache.

Voorbeeld van Consul-template voor bovenstaand 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}}

“Client IP Address Handling

Er zijn twee ondersteunde methoden voor het afhandelen van client-IP-adressering achter een proxy of loadbalancer; X-Forwarded-ForHeadersen PROXYv1.Beide vereisen een vertrouwde loadbalancer en IP-adressen die als toegestane adressen moeten worden vermeld om aan de beste beveiligingspraktijken te voldoen.

“Aanvullende referenties

• De documentatie over de architectuur van Vault geeft uitleg over elk Vault onderdeel
• Om Vault met een bestaande LDAP server te integreren, raadpleeg de documentatie over deLDAP Auth Methode
• Refereer naar de AppRole Pull Authentication tutorial om programmatisch een token voor een machine of app te genereren
• Consul is een integraal onderdeel van het draaien van een veerkrachtig Vault cluster, onafhankelijk van de locatie. Raadpleeg de online Consuldocumentatie voor meer informatie.

“Volgende stappen

• Lees Productieharding om de beste praktijken te leren voor een productieharding van Vault.
• Lees Deployment Guide om de stappen te leren die nodig zijn om een enkel HashiCorp Vault-cluster te installeren en configureren.