Free Press

Das Ziel dieses Dokuments ist es, Empfehlungen für die Implementierung von HashiCorp Vault zu geben. Diese Referenzarchitektur stellt eine allgemeine Architektur dar, die an die spezifischen Anforderungen der jeweiligen Implementierung angepasst werden sollte.

Die folgenden Themen werden in diesem Leitfaden behandelt:

• Designzusammenfassung
  • Netzwerkkonnektivität
  • Fehlertoleranz
• Empfohlene Architektur
  • Einzelregionale Bereitstellung (Unternehmen)
  • Mehrere Regionen Einsatz (Unternehmen)
• Best-Case-Architektur
  • Einsatz von Vault in einer Availability Zone (alle)
  • Einsatz von Vault in zwei Availability Zones (OSS)
  • Einsatz von Vault in zwei Availability Zones (Enterprise)
  • Einsatz von Vault in drei Availability Zones (OSS)
• Vault-Replikation (nur Enterprise)
• Einsatz Systemanforderungen
  • Hardware Überlegungen
• Lastausgleich
• Zusätzliche Referenzen

„Glossar

„Vault-Cluster

Ein Vault-Cluster ist eine Gruppe von Vault-Prozessen, die zusammen einen Vault-Dienst ausführen.Diese Vault-Prozesse können auf physischen oder virtuellen Servern oder in Containern ausgeführt werden.

„Consul Storage Backend Cluster

HashiCorp empfiehlt und unterstützt die Verwendung von Consul als Storage Backend fürVault. Ein Consul-Cluster ist eine Gruppe von Consul-Serverprozessen, die zusammen einen Consul-Dienst ausführen. Diese Consul-Prozesse können auf physischen oder virtuellen Servern oder in Containern ausgeführt werden.

„Availability Zone

Eine einzelne Ausfalldomäne auf Standortebene, die einen Teil oder den gesamtenVault-Cluster hostet. Die Latenzzeit zwischen den Verfügbarkeitszonen sollte < 8ms für die Hin- und Rückfahrt betragen. Ein einzelner Vault-Cluster kann über mehrere Verfügbarkeitszonen verteilt sein.

Beispiele für eine Verfügbarkeitszone in diesem Zusammenhang sind:

• Ein isoliertes Rechenzentrum
• Ein isolierter Käfig in einem Rechenzentrum, wenn er durch alle anderen Mittel (Strom, Netzwerk usw.) von anderen Käfigen isoliert ist
• Eine Verfügbarkeitszone in AWS, Azure oder GCP

„Region

Eine geografisch getrennte Sammlung von einer oder mehreren Verfügbarkeitszonen. Eine Region würde einen oder mehrere Vault-Cluster hosten. In der Vault-Architektur gibt es keine definierte maximale Latenzanforderung zwischen Regionen. Ein einzelner Vault-Cluster wird nicht über mehrere Regionen verteilt.

„Design Summary

Dieses Design ist die empfohlene Architektur für Produktionsumgebungen, da es Flexibilität und Ausfallsicherheit bietet.

Eine wichtige Empfehlung für die Architektur ist, dass die Consul-Server von den Vault-Servern getrennt sind und dass der Consul-Cluster nur als Speicher-Backend für Vault verwendet wird und nicht für andere Consul-fokussierte Funktionen (z.B. Service-Segmentierung und Service-Erkennung), die zu einer unvorhersehbaren Ressourcennutzung führen können. Die Trennung von Vault und Consul ermöglicht es, dass jedes System eine angemessene Größe in Bezug auf CPU, Speicher und Festplatte hat. Da Consul eine speicherintensive Anwendung ist, ist es von Vorteil, sie von ihren eigenen Ressourcen zu trennen, um Ressourcenkonflikte oder -mangel zu vermeiden. Die Dedizierung eines Consul-Clusters als Vault-Speicher-Backend ist ebenfalls von Vorteil, da der Consul-Cluster nur bei Bedarf aufgerüstet werden muss, um die Funktionalität des Vault-Speicher-Backends zu verbessern. Dies wird wahrscheinlich viel seltener der Fall sein als bei einem Consul-Cluster, der auch für die Service-Erkennung und Service-Segmentierung verwendet wird.

Die Verbindung zwischen Vault und Consul-Backend erfolgt über HTTP und sollte mit TLS sowie einem Consul-Token gesichert werden, um den gesamten Datenverkehr zu verschlüsseln. Weitere Informationen finden Sie im VaultDeployment Guide. Da der Consul-Cluster für die Vault-Speicherung zusätzlich und getrennt von einem Consul-Cluster für die Service-Erkennung verwendet werden kann, wird empfohlen, dass der Consul-Prozess für die Speicherung auf nicht standardmäßigen Ports ausgeführt wird, damit er nicht mit anderen Consul-Funktionen in Konflikt gerät. Dies wird erreicht, indem der Consul-Speichercluster auf 7xxx Ports ausgeführt wird und dieser Port als Speicherport in der Vault-Konfiguration verwendet wird. Es wird außerdem empfohlen, Consul mit TLS auszuführen.

„Details zur Netzwerkkonnektivität

In der folgenden Tabelle sind die Anforderungen an den Netzwerkverkehr für Vault-Clusterknoten aufgeführt.

„Alternative Netzwerkkonfigurationen

Vault kann auf verschiedene Arten für die Kommunikation zwischen demVault und Consul Clustern konfiguriert werden:

• Verwendung von Host-IP-Adressen oder Hostnamen, die über das Standard-Namenssubsystem auflösbar sind
• Verwendung von Load Balancer-IP-Adressen oder Hostnamen, die über das Standard-Namenssubsystem auflösbar sind
• Verwendung des angeschlossenen Consul-Clusters DNS als Service Discovery zur Auflösung von Vaultendpunkten
• Verwendung eines separaten Consul Service Discovery Clusters DNS als Service Discovery zur Auflösung von Vault-Endpunkten

Alle diese Optionen werden im Vault Deployment Guide näher erläutert.

„Fehlertoleranz

Vault ist so konzipiert, dass verschiedene Fehlerszenarien mit unterschiedlichen Wahrscheinlichkeiten behandelt werden können. Bei der Bereitstellung eines Vault-Clusters sollte die von Ihnen benötigte Fehlertoleranz berücksichtigt und ausgelegt werden. In OSS Vault beträgt die empfohlene Anzahl von Instanzen 3 in einem Cluster, da jede weitere Instanz nur einen begrenzten Wert hätte. InVault Enterprise ist die empfohlene Anzahl ebenfalls 3 in einem Cluster, aber es können auch mehr Instanzen verwendet werden, wenn es sich um performancestarke Instanzen handelt, die bei reinen Lesevorgängen helfen. Der Consul-Cluster besteht aus einer bis sieben Instanzen, wobei es sich um eine ungerade Zahl handeln sollte, damit Führungswahlen immer gelöst werden können. Es wird empfohlen, dass der Consul-Cluster aus mindestens fünf Instanzen besteht, die ausschließlich Backend-Speicherfunktionen für den Vault-Cluster ausführen.

„Node

Die Vault- und Consul-Cluster-Software ermöglicht eine Ausfalldomäne auf Knotenebene durch Replikation innerhalb des Clusters. In einem einzelnen HA-Vault-Cluster teilen sich alle Knoten dasselbe zugrunde liegende Speicher-Backend und damit auch die Daten. Vault bewerkstelligt dies, indem einer der Vault-Server eine Sperre im Datenspeicher erhält, um der aktive Vault-Knoten zu werden, und dieser hat Schreibzugriff. Wenn der führende Server zu irgendeinem Zeitpunkt ausfällt, nimmt ein anderer Vault-Knoten nahtlos seinen Platz als führender Server ein. Um eine Redundanz von n-2 zu erreichen (wobei der Verlust von 2 Objekten innerhalb der Ausfalldomäne toleriert werden kann), wäre eine ideale Größe für einen Vault-Cluster 3.Consul erreicht Replikation und Führung durch die Verwendung seiner Konsens- und Gossip-Protokolle. Bei diesen Protokollen wird ein Leader durch Konsens gewählt, so dass immer ein Aquorum aktiver Server vorhanden sein muss. Um n-2-Redundanz zu erreichen, ist die ideale Größe eines Consul-Clusters 5. Weitere Einzelheiten finden Sie in den Consul-Interna.

„Availability Zone

Die typische Verteilung in einer Cloud-Umgebung besteht darin, Consul/Vault-Knoten in getrennten Availability Zones (AZs) innerhalb eines Netzwerks mit hoher Bandbreite und geringer Latenz zu verteilen, wie z. B. in einer AWS-Region, was jedoch in einer Rechenzentrumsinstallation, in der es nur einen DC mit der erforderlichen Latenz gibt, möglicherweise nicht möglich ist.

Es ist wichtig, eine Änderung der Anforderungen oder Best Practices zu verstehen, die sich aus der Entwicklung hin zu einer stärkeren Nutzung von hochgradig verteilten Systemen wie Consul ergeben hat. Beim Betrieb von Umgebungen, die aus verteilten Systemen bestehen, ist eine Änderung des Redundanzkoeffizienten der zugrunde liegenden Komponenten erforderlich. Consul stützt sich auf Konsensverhandlungen, um Informationen zu organisieren und zu vervielfältigen, und daher muss die Umgebung drei einzigartige Ausweichpfade bieten, um eine sinnvolle Zuverlässigkeit zu gewährleisten. Im Wesentlichen erfordert ein Konsenssystem eine einfache Mehrheit von Knoten, die jederzeit verfügbar sein müssen. In dem Beispiel von 3 Knoten müssen 2 verfügbar sein. Wenn diese 3 Knoten in zwei Ausfalldomänen untergebracht sind, besteht eine 50-prozentige Chance, dass der Ausfall einer einzigen Ausfalldomäne zu einem vollständigen Ausfall führt.

„Region

Zum Schutz vor einem Ausfall auf Regionsebene sowie zur Bereitstellung zusätzlicher geografischer Skalierungsmöglichkeiten bietet Vault Enterprise:

• Disaster Recovery Replication
• Performance Replication

Eine vollständige Beschreibung dieser Optionen finden Sie in den empfohlenen Mustern zur Vault-Replikation.

Aufgrund der oben genannten Einschränkungen wird eine Architektur empfohlen, bei der Vault und Consul Enterprise über drei Verfügbarkeitszonen innerhalb eines Clusters verteilt sind und Cluster über Regionen hinweg mit DR- und Performance-Replikation repliziert werden. Es gibt auch mehrere „Best Case“-Architekturen, Lösungen für eine und zwei Availability Zones und auch für Consul OSS. Diese sind nicht die empfohlene Architektur, stellen aber die beste Lösung dar, wenn Ihre Bereitstellung durch die Consul-Version oder die Anzahl der Verfügbarkeitszonen eingeschränkt ist.

„Empfohlene Architektur

Die nachstehende Architektur ist der empfohlene beste Ansatz für die Vault-Bereitstellung und sollte die Zielarchitektur für jede Installation sein. Sie ist in zwei Teile aufgeteilt:

• Vault-Cluster – Dies ist die empfohlene Architektur für einen Vault-Cluster als einzelne Einheit, sollte aber auch die Replikation gemäß dem zweiten Diagramm verwenden
• Vault-Replikation – Dies ist die empfohlene Architektur für mehrere Vault-Cluster, um eine regionale, leistungsfähige und Notfallwiederherstellung zu ermöglichen.

„Single Region Deployment (Enterprise)

In diesem Szenario werden die Vault-Knoten und der zugehörige Consul-Cluster in drei Availability Zones gehostet. Diese Lösung hat ein n-2 auf der Knotenebene für Vault und ein n-3 auf der Knotenebene für Consul. Auf der Ebene der Availability Zones befindet sich Vault auf n-2 und Consul auf n-1. Der Unterschied zum OSS-Design besteht darin, dass der Consul-Cluster sechs Knoten hat, von denen drei nicht stimmberechtigte Mitglieder sind. Der Consul-Cluster ist unter Verwendung von Redundanzzonen so eingerichtet, dass bei einem Ausfall eines Knotens ein nicht stimmberechtigtes Mitglied von Autopilot zu einem Vollmitglied befördert wird und so das Quorum aufrechterhalten wird.

„Multiple Region Deployment (Enterprise)

„Reference Diagram Resilience against Region Failure

In diesem Szenario werden die Cluster repliziert, um einen Ausfall der gesamten Region zu verhindern. Es gibt drei Performance Replica Vault-Cluster (Cluster A, B, C) mit jeweils einem eigenen DR-Cluster (Cluster D, E, F) in einer anderen Region. Jeder Cluster verfügt über einen zugehörigen Consul-Cluster als Speicher-Backend.

Diese Architektur ermöglicht n-2 auf Regionsebene, vorausgesetzt, dass alle Secrets und Secrets-Engines in allen Clustern repliziert werden. Bei einem Ausfall der vollständigen Region1 müsste der DR-Cluster F befördert werden. Sobald dies geschehen ist, wäre die Vaultsolution mit einem gewissen Redundanzverlust voll funktionsfähig, bis die Region1 wiederhergestellt ist. Die Anwendungen müssten sich nicht neu authentifizieren, da der DR-Cluster für jeden ausgefallenen Cluster alle Leases und Tokens enthalten würde.

„Referenzdiagramm Ausfallsicherheit bei Clusterausfällen

Diese Lösung bietet volle Ausfallsicherheit auf Clusterebene, schützt aber nicht vor dem Ausfall einer Region, da die DR-Cluster für die Leistungsreplikate in derselben Region liegen. Es gibt bestimmte Anwendungsfälle, in denen dies die bevorzugte Methode ist, wenn Daten aufgrund von Governance-Einschränkungen wie GDPR nicht in andere Regionen repliziert werden können. Auch einige Infrastruktur-Frameworks sind möglicherweise nicht in der Lage, den Anwendungsverkehr in verschiedene Regionen zu leiten.

„Best Case Architecture

Bei einigen Implementierungen kann es unüberwindbare Einschränkungen geben, die bedeuten, dass die empfohlene Architektur nicht möglich ist. Das kann an fehlenden Verfügbarkeitszonen liegen oder an der Verwendung von Vault OSS. In diesen Fällen stellen die nachstehenden Architekturen die besten verfügbaren Optionen dar.

Beachten Sie, dass in diesen folgenden Architekturen der Consul-Leader einer der fünf Consul-Serverknoten und der aktive Vault-Knoten einer der drei Vault-Knoten sein kann

„Bereitstellung von Vault in einer Availability Zone (alle)

In diesem Szenario werden alle Vault-Knoten und der zugehörige Consul-Cluster in einer Availability Zone gehostet. Diese Lösung hat einen Single Point of Failure auf der Ebene der Availability Zone, aber einen n-2 auf der Knotenebene für Consul und Vault. Dies ist keine von Hashicorp empfohlene Architektur für Produktionssysteme, da es keine Redundanz auf der Ebene der Availability Zone gibt. Außerdem gibt es keine DR-Fähigkeit, so dass zumindest ein DR-Replikat in einer anderen Region vorhanden sein sollte.

„Bereitstellung von Vault in zwei Availability Zones (OSS)

In diesem Szenario werden die Vault-Knoten und der zugehörige Consul-Cluster in zwei Availability Zones gehostet. Diese Lösung hat ein n-2 auf der Knotenebene für Vault und Consul und ein n-1 für Vault auf der Ebene der Availability Zone, aber das Hinzufügen einer Availability Zone erhöht die Verfügbarkeit des Consul-Clusters nicht wesentlich. Dies liegt daran, dass das Raft-Protokoll ein Aquorum von (n/2)+1 erfordert, und wenn Zone B im obigen Diagramm ausfallen würde, wäre der Cluster nicht beschlussfähig und würde daher ebenfalls ausfallen. Dies ist keine von Hashicorp empfohlene Architektur für Produktionssysteme, da auf der Ebene der Availability Zones nur eine teilweise Redundanz besteht und ein Ausfall einer Availability Zone möglicherweise nicht zu einem Ausfall führt.

„Einsatz von Vault in zwei Availability Zones (Enterprise)

Aufgrund der Notwendigkeit, das Quorum im Consul-Cluster aufrechtzuerhalten, ist es nicht ideal, nur 2 Availability Zones zu haben. Es gibt keine Möglichkeit, einen Consul-Cluster über zwei AZs zu verteilen, die eine zusätzliche Ausfallsicherheit garantieren. Die beste Lösung inVault Enterprise ist es, die beiden AZs als Regionen zu behandeln und in jeder separate Vault-Cluster zu haben.

Der sekundäre Vault-Cluster kann entweder ein Performance-Replikat oder ein DR-Replikat sein, die beide ihre eigenen Vorteile haben:

• PR sekundär: Wenn die Vault-Adresse von Consul oder einem Load Balancer verwaltet wird, führt ein Ausfall eines der beiden Cluster dazu, dass der Datenverkehr ohne Ausfall auf den anderen Cluster umgeleitet wird, vorausgesetzt, es gibt eine Logik in Ihrer Anwendung oder dem Vault-Agenten, um die erneute Anforderung von Token zu verwalten, die nicht zwischen den Clustern repliziert werden.
• DR sekundär: In diesem Fall führt der Ausfall des primären Clusters dazu, dass der Operator eingreifen muss, um den DR zum primären zu befördern, aber da alle Leases und Token repliziert werden, ist keine zusätzliche Logik in der Anwendung erforderlich, um dies zu handhaben.

„Einsatz von Vault in drei Availability Zones (OSS)

In diesem Szenario werden die Nodes in Vault und der zugehörige Consul-Cluster in drei Availability Zones gehostet. Diese Lösung hat ein n-2 auf der Knotenebene für Vault und Consul und ein n-2 für Vault auf der Ebene der Availability Zones. n-1 auf der Ebene der Availability Zones für Consul wird als die stabilste aller Architekturen für einen einzelnen Vault-Cluster mit einem Consul-Speicher-Backend für das OSS-Produkt angesehen.

„Vault Replication (Enterprise Only)

In diesen Architekturen wird der Vault-Cluster als eine einzelne Einheit dargestellt und wäre einer der oben beschriebenen einzelnen Cluster, basierend auf der Anzahl der Availability Zones. Mehrere Vault-Cluster, die als eine einzige Vault-Lösung fungieren und zwischen denen repliziert wird, sind nur in Enterprise Vault verfügbar. OSSVault kann in mehreren Clustern eingerichtet werden, aber sie wären jeweils individuelle Vault-Lösungen und würden keine Replikation zwischen Clustern unterstützen.

Die Vault-Dokumentation enthält detailliertere Informationen zu den Replikationsfunktionen in VaultEnterprise.

„Performance Replication

Vault Performance Replication ermöglicht die Verwaltung von Geheimnissen über viele Standorte hinweg.Statische Geheimnisse, Authentifizierungsmethoden und Autorisierungsrichtlinien werden repliziert, um an mehreren Standorten aktiv und verfügbar zu sein, jedoch nicht Leasestokens und dynamische Geheimnisse.

„Disaster Recovery Replication

Die Disaster Recovery Replikation von Vault stellt sicher, dass ein Standby-Vault-Cluster mit einem aktiven Vault-Cluster keptsynchronisiert ist. Dieser Replikationsmodus umfasst Daten wie ephemere Authentifizierungs-Tokens, zeitbasierte Token-Informationen sowie Token-Nutzungsdaten. Dies ermöglicht einen aggressiven Wiederherstellungspunkt in Umgebungen, in denen die Vermeidung des Verlusts von ephemeren Betriebsdaten von größter Bedeutung ist. In jeder Unternehmenslösung werden Disaster Recovery Replicas als unverzichtbar angesehen.

„Korruption oder Sabotage Disaster Recovery

Ein weiteres häufiges Szenario, gegen das man sich schützen muss und das in Cloud-Umgebungen, die ein sehr hohes Maß an intrinsischer Resilienz bieten, häufiger vorkommt, ist die absichtliche oder versehentliche Beschädigung von Daten und Konfigurationen und/oder der Verlust der Kontrolle über Cloud-Konten. Die DR-Replikation von Vault ist so konzipiert, dass sie Live-Daten repliziert, die eine absichtliche oder versehentliche Beschädigung oder Löschung von Daten weitergeben würden. Um sich gegen diese Möglichkeiten zu schützen, sollten Sie das Speicher-Backend von Vault sichern. Dies wird durch die ConsulSnapshot-Funktion unterstützt, die für regelmäßige Archivierungs-Backups automatisiert werden kann. Ein kalter Standort oder eine neue Infrastruktur kann mit einem Consul-Snapshot wiederhergestellt werden.

„Replikationshinweise

Es gibt keine Begrenzung der Anzahl von Clustern innerhalb eines Replikationssets. Die größten Deployments liegen heute im Bereich von 30+ Clustern. Einem Performance Replica-Cluster kann ein Disaster Recovery-Cluster zugeordnet werden, und er kann auch zu mehreren Disaster Recovery-Clustern replizieren.

Ein Vault-Cluster kann zwar eine Replikationsrolle (oder mehrere Rollen) besitzen, es sind jedoch keine besonderen Überlegungen in Bezug auf die Infrastruktur erforderlich, und Cluster können eine andere Rolle annehmen (oder befördert oder degradiert werden). Besondere Umstände im Zusammenhang mit Mount-Filtern und der Verwendung von Hardware-Sicherheitsmodulen (HSM) können das Umschalten von Rollen einschränken, aber diese basieren auf spezifischen Organisationskonfigurationen.

„Überlegungen zur HSM-Integration

Die Verwendung von Replikation mit Vault-Clustern, die mit Hardware-Sicherheitsmodulen (HSM) oder Cloud-Geräten zur automatischen Entsiegelung für automatisierte Entsiegelungsvorgänge integriert sind, hat einige Details, die während der Planungsphase verstanden werden sollten.

• Wenn ein primärer Leistungscluster ein HSM verwendet, müssen alle anderen Cluster innerhalb dieses Replikationssatzes ebenfalls ein HSM verwenden.
• Wenn ein primärer Leistungscluster KEIN HSM verwendet (sondern die Shamir-Geheimhaltungsmethode), können die Cluster innerhalb dieses Replikationssatzes gemischt werden, so dass einige ein HSM und andere Shamir verwenden.

Dieses Verhalten ist beabsichtigt. Ein nachgelagerter Shamir-Cluster stellt einen potenziellen Angriffsvektor in der Replikationsgruppe dar, da ein Schwellenwert von Schlüsselinhabern den Hauptschlüssel neu erstellen und somit den vorgelagerten HSM-Schlüsselschutz umgehen könnte.

„Deployment System Requirements

Die folgende Tabelle enthält Richtlinien für die Servergröße. Besonders hervorzuheben ist die dringende Empfehlung, CPUs mit nicht fester Leistung, oder BurstableCPU in AWS-Begriffen, wie z. B. Instanzen der T-Serie, zu vermeiden.

„Sizing for Vault Servers

„Sizing für Consul Server

„Hardware Considerations

Die kleine Größenkategorie ist für die meisten anfänglichen Produktionsimplementierungen oder für Entwicklungs-/Testumgebungen geeignet.

Die große Größe ist für Produktionsumgebungen geeignet, in denen eine gleichbleibend hohe Arbeitslast herrscht. Das kann eine große Anzahl von Transaktionen, eine große Anzahl von Geheimnissen oder eine Kombination aus beidem sein.

Im Allgemeinen hängen die Verarbeitungsanforderungen von der Verschlüsselungslast und der Nachrichtenlast (Operationen pro Sekunde und Arten von Operationen) ab. Der Speicherbedarf hängt von der Gesamtgröße der gespeicherten Geheimnisse/Schlüssel ab und sollte dementsprechend dimensioniert werden (ebenso wie der Festplattenspeicher). Vault selbst hat minimale Speicheranforderungen, aber das zugrundeliegende Speicher-Backend sollte über ein relativ leistungsstarkes Festplattensubsystem verfügen.

Wenn viele Geheimnisse häufig generiert/rotiert werden, müssen diese Informationen häufig auf die Festplatte geflusht werden, was sich auf die Leistung auswirken kann, wenn langsamere Festplatten verwendet werden.

Die Funktion des Consul-Servers in dieser Bereitstellung ist es, als Speicher-Backend für Vault zu dienen. Das bedeutet, dass alle Inhalte, die für die Persistenz in Vault gespeichert werden, von Vault verschlüsselt und im Ruhezustand in das Speicher-Backend geschrieben werden. Diese Daten werden in den Key-Value-Store-Bereich des Consul-Servicekatalogs geschrieben, der auf jedem Consul-Server vollständig im Arbeitsspeicher gespeichert sein muss. Dies bedeutet, dass der Speicher bei der Skalierung eine Einschränkung darstellen kann, wenn sich mehr Clients bei Vault authentifizieren, mehr Geheimnisse dauerhaft im Vault gespeichert werden und mehr temporäre Geheimnisse von Vault geleast werden. Dies hat auch zur Folge, dass der Speicher des Consul-Servers vertikal skaliert werden muss, wenn zusätzlicher Speicherplatz benötigt wird, da der gesamte Service-Katalog im Speicher jedes Consul-Servers gespeichert wird.

Außerdem ist der Netzwerkdurchsatz ein gemeinsamer Gesichtspunkt für Vault und Consuls-Server. Da beide Systeme HTTPS-API-gesteuert sind, verbrauchen alle eingehenden Anfragen, die Kommunikation zwischen Vault und Consul, die zugrundeliegende Gossip-Kommunikation zwischen den Mitgliedern des Consul-Clusters, die Kommunikation mit externen Systemen (per Auth- oder Secretengine-Konfiguration und einige Audit-Protokollierungskonfigurationen) und die Antworten Netzwerkbandbreite.

Aufgrund von Überlegungen zur Netzwerkleistung im Consul-Cluster-Betrieb sollte die Replikation von Vault-Datensätzen über Netzwerkgrenzen hinweg durch Performance- oder DR-Replikation erfolgen, anstatt den Consul-Cluster über Netzwerk- und physische Grenzen hinweg zu verteilen. Wenn ein einzelner Consul-Cluster über weit entfernte oder überregionale Netzwerksegmente verteilt wird, kann dies zu Synchronisierungsproblemen innerhalb des Clusters oder zu zusätzlichen Datenübertragungsgebühren bei einigen Cloud-Anbietern führen.

„Andere Überlegungen

Vault Production Hardening Recommendationsprovider bietet eine Anleitung zu Best Practices für eine produktionssichere Bereitstellung vonVault.

„Load Balancing

„Load Balancing Using Consul Interface

Consul kann Load Balancing-Funktionen durch Service Discovery bereitstellen, setzt aber voraus, dass alle Vault-Clients Consul-kompatibel sind. Das bedeutet, dass ein Client weder die DNS- noch die API-Schnittstellen von Consul verwenden kann, um den aktiven Vault-Knoten aufzulösen. Ein Client könnte über eine URL wie die folgende auf Vault zugreifen:http://active.vault.service.consul:8200

Dies beruht auf dem DNS-Auflösungssystem des Betriebssystems, und die Anfrage könnte an Consul weitergeleitet werden, um die tatsächliche IP-Adresse zu erhalten. Der Vorgang kann für Legacy-Anwendungen völlig transparent sein und würde genauso funktionieren wie ein typischer DNS-Auflösungsvorgang. Weitere Informationen finden Sie unter Consul DNS-Weiterleitung

„Load Balancing mit externem Load Balancer

Externe Load Balancer werden als Einstiegspunkt in einen Vault-Cluster unterstützt. Der externe Load Balancer sollte den Endpunkt sys/health abfragen, um den aktiven Knoten zu erkennen und den Datenverkehr entsprechend zu routen. Der Load Balancer sollte so konfiguriert werden, dass er eine HTTP-Anfrage für die folgende URL an jeden Knoten im Cluster stellt: http://<Vault Node URL>:8200/v1/sys/health

Der aktive Vault-Knoten antwortet mit einer 200, während die Standby-Knoten eine 4xx-Antwort zurücksenden.

Zur Veranschaulichung folgt ein Beispielkonfigurationsblock von HAProxy:

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

Beachten Sie, dass der obige Block von Consul (mit consul-template) generiert werden könnte, wenn ein Software-Loadbalancer verwendet wird. Dies könnte der Fall sein, wenn der Loadbalancer eine Software wie Nginx, HAProxy oder Apache ist.

Beispiel Consul-Vorlage für den obigen 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}}

„Client IP Address Handling

Es gibt zwei unterstützte Methoden für die Behandlung von Client-IP-Adressen hinter einem Proxy oder Load Balancer; X-Forwarded-ForHeadersund PROXYv1.Beide erfordern einen vertrauenswürdigen Load Balancer und eine IP-Adresse, die als erlaubte Adressen aufgelistet wird, um die besten Sicherheitspraktiken einzuhalten.

„Zusätzliche Referenzen

• Die Dokumentation zur Vault-Architektur erläutert jede Vault-Komponente
• Um Vault in einen vorhandenen LDAP-Server zu integrieren, lesen Sie die Dokumentation zur LDAP-Authentifizierungsmethode
• Beziehen Sie sich auf das AppRole PullAuthentication-Tutorial, um ein Token für einen Computer oder eine Anwendung programmatisch zu generieren
• Consul ist ein integraler Bestandteil des Betriebs eines stabilen Vault-Clusters, unabhängig vom Standort. Lesen Sie die Online-Dokumentation zu Consuld, um mehr darüber zu erfahren.

„Nächste Schritte

• Lesen Sie Production Hardening, um die Best Practices für eine Production Hardening-Bereitstellung von Vault kennenzulernen.
• Lesen Sie den Deployment Guide, um die erforderlichen Schritte für die Installation und Konfiguration eines einzelnen HashiCorp Vault-Clusters zu erfahren.