Free Press

Celem tego dokumentu jest zalecenie praktyk wdrożeniowych HashiCorp Vault. Ta architektura referencyjna przedstawia ogólną architekturę, która powinna być dostosowana do konkretnych potrzeb każdego wdrożenia.

W niniejszym przewodniku poruszono następujące tematy:

• Podsumowanie projektu
  • Połączenia sieciowe
  • Tolerancja awarii
• Zalecana architektura
  • Single Region Deployment (Enterprise)
  • Multiple Region Wdrożenie (Enterprise)
• Architektura najlepszego przypadku
  • Wdrożenie programu Vault w jednej strefie dostępności (wszystkie)
  • Wdrożenie programu Vault w dwóch strefach dostępności (OSS)
  • Wdrożenie programu Vault w dwóch strefach dostępności (Enterprise)
  • Wdrożenie programu Vault w trzech strefach dostępności (OSS)
• Replikacja programu Vault (tylko Enterprise)
• Wymagania systemowe dotyczące wdrażania
  • Sprzęt Considerations
• Load Balancing
• Additional References

„Glossary

„Vault Cluster

Klaster Vault to zestaw procesów Vault, które razem uruchamiają usługę Vault.Te procesy Vault mogą być uruchomione na serwerach fizycznych lub wirtualnych albo w kontenerach.

„Klaster zaplecza pamięci masowej Consul

HashiCorp zaleca i popiera używanie Consul jako zaplecza pamięci masowej dlaVault. Klaster Consul to zestaw procesów serwera Consul, które razem uruchamiają usługę Consul. Te procesy Consul mogą być uruchomione na serwerach fizycznych, wirtualnych lub w kontenerach.

„Strefa dostępności

Pojedyncza domena awarii na poziomie lokalizacji, która hostuje część lub całość klastraVault. Latencja między strefami dostępności powinna wynosić < 8 ms dla podróży dookoła. Pojedynczy klaster Vault może być rozmieszczony w wielu strefach dostępności.

Przykłady strefy dostępności w tym kontekście to:

• Odizolowane centrum danych
• Odizolowana klatka w centrum danych, jeśli jest odizolowana od innych klatek wszelkimi innymi środkami (zasilanie, sieć itp.)
• Strefa dostępności w AWS, Azure lub GCP

„Region

Oddzielony geograficznie zbiór jednej lub więcej stref dostępności. W regionie może znajdować się jeden lub więcej klastrów Vault. W architekturze Vault nie ma zdefiniowanych maksymalnych wymagań dotyczących opóźnień między regionami. Pojedynczy klaster Vault nie będzie rozmieszczony w wielu regionach.

„Design Summary

Ta konstrukcja jest zalecaną architekturą dla środowisk produkcyjnych, ponieważ zapewnia elastyczność i odporność.

Głównym zaleceniem architektury jest to, że serwery Consul są oddzielone od serwerów Vault i że klaster Consul jest używany tylko jako stacja końcowa pamięci masowej dla Vault, a nie dla innych funkcji skoncentrowanych na Consul (np. segmentacji usług i wykrywania usług), które mogą wprowadzać nieprzewidywalne wykorzystanie zasobów. Rozdzielenie Vault i Consul pozwala każdemu z nich mieć system, który może być odpowiednio zwymiarowany pod względem procesora, pamięci i dysku. Consul jest aplikacją intensywnie korzystającą z pamięci, więc wydzielenie jej do własnych zasobów jest korzystne, aby zapobiec rywalizacji zasobów lub ich zagłodzeniu. Dedykowanie klastra Consul jako zaplecza pamięci masowej Vault jest również korzystne, ponieważ pozwala na uaktualnianie klastra Consul tylko wtedy, gdy jest to wymagane do poprawienia funkcjonalności zaplecza pamięci masowej Vault. Będzie to prawdopodobnie znacznie rzadsze niż w przypadku klastra Consul, który służy także do wykrywania usług i segmentacji usług.

Łączność między Vault a zapleczem Consul odbywa się przez HTTP i powinna być zabezpieczona protokołem TLS oraz tokenem Consul, aby zapewnić szyfrowanie całego ruchu. Więcej informacji można znaleźć w Przewodniku wdrażania Vault. Ponieważ klaster Consul do przechowywania danych Vault może być używany dodatkowo i niezależnie od klastra Consul do wykrywania usług, zaleca się, aby proces Consul do przechowywania danych był uruchamiany na niestandardowych portach, aby nie kolidował z innymi funkcjami Consul. Ustawienie klastra pamięci masowej Consul tak, aby działał na porcie 7xxx i użycie go jako portu pamięci masowej w konfiguracji skarbca pozwoli osiągnąć ten cel. Zaleca się także uruchamianie Consul przy użyciu protokołu TLS.

„Szczegóły dotyczące połączeń sieciowych

W poniższej tabeli przedstawiono wymagania dotyczące ruchu sieciowego dla węzłów klastrów Vault.

„Alternatywne konfiguracje sieciowe

Vault może być skonfigurowany na kilka różnych sposobów do komunikacji między klastramiVault i Consul:

• Używanie adresów IP hostów lub nazw hostów, które są rozwiązywalne za pomocą standardowego podsystemu nazw
• Używanie adresów IP load balancerów lub nazw hostów, które są rozwiązywalne za pomocą standardowego podsystemu nazw
• Używanie dołączonego klastra Consul. DNS as service discovery to resolve Vaultendpoints
• Użycie oddzielnego klastra Consul service discovery DNS as service discovery toresolve Vault endpoints

Wszystkie te opcje są omówione bardziej szczegółowo w podręczniku Vault Deployment Guide.

„Tolerancja awarii

Vault jest zaprojektowany do obsługi różnych scenariuszy awarii, które mają różne prawdopodobieństwa. Podczas wdrażania klastra Vault należy rozważyć i zaprojektować wymaganą tolerancję na awarie. W OSS Vault zalecana liczba instancji to 3 w klastrze, ponieważ każda większa liczba miałaby ograniczoną wartość. WVault Enterprise zalecana liczba instancji to również 3 w klastrze, ale można użyć większej liczby, jeśli są to instancje performancestandbys, które pomagają w obciążeniu pracą tylko do odczytu. Klaster Consul to od jednej do siedmiu instancji. Powinna to być liczba nieparzysta, aby wybory na lidera zawsze były rozstrzygane. Zaleca się, aby klaster Consul składał się z co najmniej pięciu instancji, które są przeznaczone do wykonywania funkcji zaplecza pamięci masowej wyłącznie dla klastra Vault.

„Node

Oprogramowanie klastrów Vault i Consul pozwala na tworzenie domeny awarii na poziomie węzłów dzięki replikacji wewnątrz klastra. W pojedynczym klastrze HA Vault wszystkie węzły współdzielą ten sam bazowy backend pamięci masowej, a więc i dane. Vault rozwiązuje ten problem w ten sposób, że jeden z serwerów Vault uzyskuje blokadę w magazynie danych, aby stać się aktywnym węzłem Vault, który ma dostęp do zapisu. Jeśli w dowolnym momencie lider zostanie utracony, inny węzeł Vault bezproblemowo zajmie jego miejsce jako lider. Aby osiągnąć redundancję n-2 (gdzie utrata 2 obiektów w domenie awarii może być tolerowana), idealny rozmiar klastra Vault to 3.Consul osiąga replikację i przywództwo za pomocą protokołów consensus igossip. W tych protokołach lider jest wybierany przez konsensus, a więc akworum aktywnych serwerów musi istnieć zawsze. Aby osiągnąć redundancję n-2, idealna wielkość klastra Consul to 5. Zobacz ConsulInternals, aby uzyskać więcej szczegółów.

„Strefa dostępności

Typowa dystrybucja w środowisku chmury polega na rozmieszczeniu węzłów Consul/Vault w oddzielnych strefach dostępności (AZ) w ramach sieci o wysokiej przepustowości i małych opóźnieniach, takich jak region AWS, jednak może to nie być możliwe w instalacji w centrum danych, gdzie jest tylko jeden DC w ramach wymaganego poziomu opóźnień.

Ważne jest, aby zrozumieć zmianę w wymaganiach lub najlepszych praktykach, która nastąpiła w wyniku przejścia w kierunku większego wykorzystania wysoce rozproszonych systemów, takich jak Consul. Podczas obsługi środowisk składających się z systemów rozproszonych wymagana jest zmiana współczynnika redundancji podstawowych komponentów. Consul opiera się na negocjacjach konsensualnych w celu uporządkowania i powielania informacji, a zatem środowisko musi zapewnić 3 unikalne ścieżki odporności, aby zapewnić znaczącą niezawodność. Zasadniczo system konsensualny wymaga, aby zwykła większość węzłów była dostępna w dowolnym momencie. W przykładzie z 3 węzłami, musisz mieć 2 dostępne. Jeśli te 3 węzły są umieszczone w dwóch domenach awarii, istnieje 50% szans, że utrata jednej domeny awarii spowoduje całkowity przestój.

„Region

Aby zabezpieczyć się przed awarią na poziomie regionu, a także zapewnić dodatkowe możliwości skalowania geograficznego, program Vault Enterprise oferuje:

• Replikację po katastrofie
• Replikację wydajną

Proszę zapoznać się z zalecanymi wzorcami na temat replikacji Vault w celu uzyskania pełnego opisu tych opcji.

Z powodu ograniczeń wymienionych powyżej zalecana architektura to Vault i Consul Enterprise rozproszone w trzech strefach dostępności w ramach klastra oraz klastry replikowane w regionach przy użyciu replikacji DR i replikacji wydajnościowej. Istnieje również kilka architektur „Best Case” dla jednej i dwóch stref dostępności, a także dla Consul OSS. Nie są to architektury zalecane, ale stanowią najlepsze rozwiązania, jeśli wdrożenie jest ograniczone wersją programu Consul lub liczbą stref dostępności.

„Architektura zalecana

Poniższa architektura to zalecane najlepsze podejście do wdrożenia programu Vault i powinna być docelową architekturą każdej instalacji. Jest ona podzielona na dwie części:

• Klaster skarbców – Jest to zalecana architektura dla klastra skarbców jako pojedynczej jednostki, ale powinna również używać replikacji zgodnie z drugim diagramem
• Replikacja skarbców – Jest to zalecana architektura dla wielu klastrów skarbców w celu umożliwienia odtworzenia regionalnego, wydajnościowego i po awarii.

„Single Region Deployment (Enterprise)

W tym scenariuszu węzły programu Vault i powiązany z nimi klaster Consul są hostowane między trzema strefami dostępności. To rozwiązanie ma n-2 na poziomie węzła dla Vault i n-3 na poziomie węzła dla Consul. Na poziomie AvailabilityZone, Vault jest na poziomie n-2, a Consul na poziomie n-1. Różni się to od projektu OSS tym, że klaster Consul ma sześć węzłów, a trzy z nich są członkami niegłosującymi. Klaster Consul jest skonfigurowany przy użyciu RedundancyZones, tak aby w przypadku awarii któregokolwiek węzła członek bez prawa głosu został awansowany przez Autopilota na pełnoprawnego członka i w ten sposób utrzymał kworum.

„Multiple Region Deployment (Enterprise)

„Reference Diagram Resilience against Region Failure

W tym scenariuszu klastry są replikowane, aby zabezpieczyć się przed awarią całego regionu. Istnieją trzy klastry Performance Replica Vault (klastry A, B, C), z których każdy ma własny klaster DR (klastry D, E, F) w innym regionie. Każdy klaster ma powiązany z nim klaster Consul do obsługi backendu pamięci masowej.

Ta architektura pozwala na n-2 na poziomie regionu pod warunkiem, że wszystkie sekrety i silniki sekretów są replikowane we wszystkich klastrach. Awaria pełnego Regionu1 wymagałaby awansowania klastra DR F. Po wykonaniu tej czynności rozwiązanie Vaultsolution byłoby w pełni funkcjonalne z pewną utratą redundancji do czasu przywrócenia Regionu1. Aplikacje nie musiałyby się ponownie uwierzytelniać, ponieważ klaster DR dla każdego uszkodzonego klastra zawierałby wszystkie dzierżawy i tokeny.

„Schemat referencyjny Odporność na awarię klastra

Rozwiązanie to ma pełną odporność na poziomie klastra, ale nie chroni przed awarią regionu, ponieważ klastry DR dla replik Performance znajdują się w tym samym regionie. Istnieją pewne przypadki użycia, w których jest to preferowana metoda, gdy dane nie mogą być replikowane do innych regionów ze względu na ograniczenia związane z zarządzaniem, takie jak GDPR. Również niektóre ramy infrastrukturalne mogą nie mieć możliwości kierowania ruchu aplikacji do różnych Regionów.

„Best Case Architecture

W niektórych wdrożeniach mogą istnieć ograniczenia nie do pokonania, które oznaczają, że zalecana architektura nie jest możliwa. Może to wynikać z braku stref dostępności lub z powodu użycia Vault OSS. W takich przypadkach poniższe architektury przedstawiają najlepsze dostępne opcje.

Zauważ, że w poniższych architekturach liderem Consul może być dowolny z pięciu węzłów serwera Consul, a aktywnym węzłem Vault może być dowolny z trzech węzłów Vault

„Wdrożenie Vault w jednej strefie dostępności (wszystkie)

W tym scenariuszu wszystkie węzły Vault i powiązany z nimi klaster Consul są hostowane w jednej strefie dostępności. To rozwiązanie ma pojedynczy punkt awarii na poziomie strefy dostępności, ale n-2 na poziomie węzła zarówno dla Consul, jak i Vault. Nie jest to architektura zalecana przez Hashicorp dla systemów produkcyjnych, ponieważ nie ma redundancji na poziomie strefy dostępności. Nie ma też możliwości DR, więc jako minimum powinna mieć przynajmniej replikę DR w oddzielnym regionie.

„Wdrożenie Vault w dwóch strefach dostępności (OSS)

W tym scenariuszu węzły Vault i powiązany z nimi klaster Consul są hostowane między dwiema strefami dostępności. To rozwiązanie ma n-2 na poziomie węzłów dla Vault i Consul oraz n-1 dla Vault na poziomie Strefy Dostępności, ale dodanie Strefy Dostępności nie zwiększa znacząco dostępności klastra Consul. Dzieje się tak dlatego, że protokół Raft wymaga aquorum na poziomie (n/2)+1, a jeśli Strefa B miałaby zawieść na powyższym diagramie, klaster nie byłby quorate, a więc również by zawiódł. Nie jest to architektura zalecana przez Hashicor dla systemów produkcyjnych, ponieważ istnieje tylko częściowa redundancja na poziomie strefy dostępności, a awaria strefy dostępności może nie spowodować przestoju.

„Wdrożenie Vault w dwóch strefach dostępności (Enterprise)

Z powodu konieczności utrzymania kworum w klastrze Consul posiadanie tylko dwóch stref dostępności nie jest idealnym rozwiązaniem. Nie ma sposobu na rozłożenie klastra Consul w dwóch AZ z jakąkolwiek gwarancją dodatkowej odporności. Najlepszym rozwiązaniem wVault Enterprise jest traktowanie dwóch AZ jako regionów i posiadanie w każdym z nich oddzielnych klastrów Vault.

Podstawowy klaster Vault może być albo repliką wydajnościową, albo repliką DR, z których każda ma swoje zalety:

• PR secondary: Jeśli adres Vault jest zarządzany przez Consul lub przez load balancerthen, awaria któregokolwiek z klastrów spowoduje, że ruch zostanie skierowany do drugiego klastra bez przestojów, pod warunkiem, że w Twojej aplikacji lub w agencie Vault istnieje logika pozwalająca zarządzać ponownymi zapytaniami o tokeny, które nie są replikowane między klastrami.
• DR drugorzędny: W tym przypadku awaria klastra podstawowego spowoduje konieczność interwencji operatora w celu promowania DR na podstawowy, ale ponieważ wszystkie dzierżawy i tokeny są replikowane, nie będzie potrzeby żadnej dodatkowej logiki w aplikacji, aby to obsłużyć.

„Wdrożenie Vault w trzech strefach dostępności (OSS)

W tym scenariuszu węzły w Vault i powiązany klaster Consul są hostowane między trzema strefami dostępności. To rozwiązanie ma n-2 na poziomie węzłów dla Vault i Consul oraz n-2 dla Vault na poziomie strefy dostępności. Ma również n-1 na poziomie strefy dostępności dla Consul i jako takie jest uważane za najbardziej odporną ze wszystkich architektur dla pojedynczego klastra Vault z zapleczem pamięci masowej Consul dla produktu OSS.

„Vault Replication (Enterprise Only)

W tych architekturach klaster Vault jest przedstawiony jako pojedynczy podmiot i może być jednym z pojedynczych klastrów opisanych powyżej w zależności od liczby stref dostępności. Wiele klastrów Vault działających jako jedno rozwiązanie Vault i replikujących między sobą jest dostępnych tylko w Enterprise Vault. OSSVault można skonfigurować w wielu klastrach, ale każdy z nich byłby indywidualnym rozwiązaniem Vault i nie obsługiwałby replikacji między klastrami.

Dokumentacja Vaultdocumentation dostarcza bardziej szczegółowych informacji na temat możliwości replikacji w ramach VaultEnterprise.

„Replikacja wydajnościowa

Replikacja wydajnościowa Vault pozwala na zarządzanie sekretami w wielu lokalizacjach.Statyczne sekrety, metody uwierzytelniania i polityki autoryzacji są replikowane, aby były aktywne i dostępne w wielu lokalizacjach, natomiast sekrety leasestokenów i sekrety dynamiczne nie są replikowane.

„Replikacja po awarii

Replikacja po awarii programu Vault zapewnia synchronizację keptsynchroniczną klastra Vault w stanie gotowości z aktywnym klastrem Vault. Ten tryb replikacji obejmuje takie dane, jak efemeryczne tokeny uwierzytelniające, informacje o tokenach oparte na czasie oraz dane o użyciu tokenów. Umożliwia to osiągnięcie agresywnego celu punktu odzyskiwania w środowiskach, w których zapobieganie utracie efemerycznych danych operacyjnych jest kwestią najwyższej wagi. W każdym rozwiązaniu korporacyjnym repliki Disaster Recovery są uważane za niezbędne.

„Corruption or Sabotage Disaster Recovery

Innym częstym scenariuszem, przed którym należy się zabezpieczyć, bardziej powszechnym w środowiskach chmurowych, które zapewniają bardzo wysoki poziom wewnętrznej odporności, może być celowe lub przypadkowe uszkodzenie danych i konfiguracji, i/lub utrata kontroli nad kontem w chmurze. Replikacja DR w Vault jest zaprojektowana do replikacji danych na żywo, które mogłyby propagować celowe lub przypadkowe uszkodzenie lub usunięcie danych. Aby zabezpieczyć się przed tymi możliwościami, należy wykonać kopię zapasową pamięci masowej Vault. Jest to obsługiwane przez funkcję ConsulSnapshot, którą można zautomatyzować w celu regularnego wykonywania archiwalnych kopii zapasowych. Zimną witrynę lub nową infrastrukturę można ponownie utworzyć z migawki Consul.

„Uwagi dotyczące replikacji

Nie ma ustalonego limitu liczby klastrów w zestawie replikacji. Największe wdrożenia są obecnie w zakresie 30+ klastrów. Klaster Performance Replica może mieć powiązany z nim klaster Disaster Recovery i może również replikować do wielu klastrów Disaster Recovery.

Pomimo że klaster Vault może posiadać rolę (lub role) replikacji, nie ma specjalnych uwarunkowań wymaganych pod względem infrastruktury, a klastry mogą przyjąć (lub zostać awansowane bądź zdegradowane) do innej roli. Specjalne okoliczności związane z filtrami montowania i wykorzystaniem Hardware Security Module (HSM) mogą ograniczyć zamianę ról, ale są one oparte na specyficznych konfiguracjach organizacji.

„Considerations Related to HSM Integration

Używanie replikacji z klastrami Vault zintegrowanymi z Hardware Security Module (HSM) lub urządzeniami do automatycznego odpieczętowywania w chmurze w celu wykonywania operacji automatycznego odpieczętowywania ma pewne szczegóły, które należy zrozumieć w fazie planowania.

• Jeśli klaster główny wydajności używa HSM, wszystkie inne klastry w ramach tego zestawu replikacji muszą również używać HSM.
• Jeśli klaster performance primary NIE używa HSM (używa metody Shamir secretsharing), klastry w ramach tego zestawu replikacyjnego mogą być mieszane, tak że niektóre mogą używać HSM, a inne Shamir.

To zachowanie jest zamierzone. Podrzędny klaster Shamir stanowi potencjalny wektor ataku w grupie replikacyjnej, ponieważ próg posiadaczy kluczy mógłby odtworzyć klucz główny; omijając w ten sposób ochronę klucza HSM w górnej części łańcucha.

„Wymagania systemowe dotyczące wdrożenia”

Następująca tabela zawiera wytyczne dotyczące rozmiaru serwera. Na szczególną uwagę zasługuje silne zalecenie, aby unikać procesorów o niestałej wydajności lub BurstableCPU w terminologii AWS, takich jak instancje serii T.

„Sizing for Vault Servers

.

„Sizing for Consul Servers

.

„Hardware Considerations

Kategoria małych rozmiarów byłaby odpowiednia dla większości początkowych wdrożeń produkcyjnych lub dla środowisk rozwojowych/testowych.

Duży rozmiar jest dla środowisk produkcyjnych, w których występuje stałe wysokie obciążenie pracą. Może to być duża liczba transakcji, duża liczba sekretów lub kombinacja tych dwóch czynników.

Ogólnie, wymagania dotyczące przetwarzania będą zależały od obciążenia związanego z szyfrowaniem i przesyłaniem wiadomości (operacje na sekundę i typy operacji). Zapotrzebowanie na pamięć będzie zależało od całkowitego rozmiaru sekretów/kluczy przechowywanych w pamięci i powinno być dostosowane do tych danych (podobnie jak dysk twardy). Sam Vault ma minimalne wymagania dotyczące pamięci masowej, ale bazowy backend pamięci masowej powinien mieć stosunkowo wydajny podsystem dysku twardego.Jeśli wiele sekretów jest często generowanych/obracanych, informacje te będą musiały być często przepłukiwane na dysk i mogą wpływać na wydajność, jeśli używane są wolniejsze dyski twarde.

Funkcją serwerów Consul w tym wdrożeniu jest służenie jako zaplecze pamięci masowej dla Vault. Oznacza to, że cała zawartość przechowywana dla trwałości w Vault jest szyfrowana przez Vault i zapisywana w stanie spoczynku na zapleczu pamięci masowej. Dane te są zapisywane do sekcji key-value store w katalogu usług Consul, który musi być w całości przechowywany w pamięci na każdym serwerze Consul. Oznacza to, że pamięć może być ograniczeniem w skalowaniu, ponieważ więcej klientów uwierzytelnia się w Vault, więcej sekretów jest trwale przechowywanych w Vault, a więcej tymczasowych sekretów jest dzierżawionych z Vault. Ma to również wpływ na konieczność pionowego skalowania pamięci serwera Consul, jeśli wymagane jest dodatkowe miejsce, ponieważ cały katalog usług jest przechowywany w pamięci na każdym serwerze Consul.

Ponadto, przepustowość sieci jest wspólną kwestią dla Vault i Consulservers. Ponieważ oba systemy są oparte na interfejsie API HTTPS, wszystkie przychodzące żądania, komunikacja między Vault i Consul, bazowa komunikacja plotkowa między członkami klastra Consul, komunikacja z systemami zewnętrznymi (zgodnie z konfiguracją auth lub secretengine oraz niektórymi konfiguracjami rejestrowania audytów) i odpowiedzi zużywają przepustowość sieci.

Ze względu na względy wydajności sieci w operacjach klastra Consul replikacja zbiorów danych Vault ponad granicami sieci powinna być realizowana za pomocą replikacji Performance lub DR, a nie przez rozprzestrzenianie klastra Consul ponad granicami sieci i fizycznymi. Jeśli pojedynczy klaster Consul jest rozmieszczony w odległych lub międzyregionalnych segmentach sieci, może to powodować problemy z synchronizacją w klastrze lub dodatkowe opłaty za transfer danych u niektórych dostawców usług w chmurze.

„Inne rozważania

Zalecenia dotyczące utwardzania produkcyjnego środowiska Vault” zawierają wskazówki dotyczące najlepszych praktyk w zakresie utwardzania produkcyjnego środowiska Vault.

„Równoważenie obciążenia

„Równoważenie obciążenia przy użyciu interfejsu Consul

Consul może zapewnić możliwości równoważenia obciążenia przez wykrywanie usług, ale wymaga, aby wszystkie klienty programu Vault były świadome Consul. Oznacza to, że klient nie może używać interfejsów DNS lub API Consul do określania aktywnego węzła Vault. Klient może uzyskać dostęp do Vault za pośrednictwem adresu URL takiego jak poniższy: http://active.vault.service.consul:8200

Polega to na systemie rozwiązywania DNS systemu operacyjnego, a żądanie może zostać przekazane do Consul w celu uzyskania odpowiedzi na temat rzeczywistego adresu IP. Operacja ta może być całkowicie przezroczysta dla starszych aplikacji i będzie działać tak samo jak nietypowa operacja rozwiązywania DNS. Więcej informacji można znaleźć w sekcji Consul DNSforwarding

„Load Balancing Using External Load Balancer

Zewnętrzne load balancery są obsługiwane jako punkt wejścia do klastra Vault. Zewnętrzny load balancer powinien odpytywać punkt końcowysys/health w celu wykrycia aktywnego węzła i odpowiednio kierować ruch. Load balancer powinien być skonfigurowany tak, aby do każdego węzła w klastrze kierował żądanie HTTP o następującym adresie URL: http://<Vault Node URL>:8200/v1/sys/health

Aktywny węzeł Vault odpowie odpowiedzią 200, podczas gdy węzły rezerwowe zwrócą odpowiedź 4xx.

Następnie przedstawiono przykładowy blok konfiguracyjny z HAProxy w celu zilustrowania:

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

Zauważ, że powyższy blok mógłby zostać wygenerowany przez Consul (za pomocą consul-template)w przypadku użycia programowego load balancera. Tak może być w przypadku, gdy loadbalancer jest oprogramowaniem takim jak Nginx, HAProxy, czy Apache.

Przykładowy szablon Consul dla powyższego bloku HAProxy:

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

„Obsługa adresów IP klienta

Istnieją dwie obsługiwane metody obsługi adresów IP klienta za proxy lub load balancerem; X-Forwarded-ForHeadersi PROXYv1.Obie wymagają zaufanego load balancera i adresu IP, który ma być wymieniony na liście dozwolonych adresów, aby przestrzegać najlepszych praktyk bezpieczeństwa.

„Dodatkowe źródła

• Dokumentacja architektury Vault wyjaśnia każdy komponent Vault
• Aby zintegrować Vault z istniejącym serwerem LDAP, zapoznaj się z dokumentacjąLDAP Auth Method
• Patrz samouczek AppRole PullAuthentication, aby programowo wygenerować token dla maszyny lub aplikacji
• Consul jest integralną częścią działania prężnego klastra Vault, niezależnie od lokalizacji. Aby dowiedzieć się więcej, zapoznaj się z dokumentacją Consul online.

„Kolejne kroki

• Zapoznaj się z poradnikiem Production Hardening, aby poznać najlepsze praktyki dotyczące wdrażania Vault na poziomie produkcyjnym.
• Zapoznaj się z poradnikiem Deployment Guide, aby poznać kroki wymagane do zainstalowania i skonfigurowania pojedynczego klastra HashiCorp Vault.

.