Free Press

Cílem tohoto dokumentu je doporučit postupy nasazení Vaultu společnosti HashiCorp. Tato referenční architektura zprostředkovává obecnou architekturu, která by měla být přizpůsobena specifickým potřebám každé implementace.

V této příručce jsou řešena následující témata:

• Shrnutí návrhu
  • Síťové připojení
  • Tolerance selhání
• Doporučená architektura
  • Nasazení v jedné oblasti (Enterprise)
  • Více oblastí Nasazení (Enterprise)
• Nejlepší případ architektury
  • Nasazení Vaultu v jedné zóně dostupnosti (vše)
  • Nasazení Vaultu ve dvou zónách dostupnosti (OSS)
  • Nasazení Vaultu v dvou zónách dostupnosti (Enterprise)
  • Rozmístění Vaultu ve třech zónách dostupnosti (OSS)
• Replikace Vaultu (pouze Enterprise)
• Systémové požadavky na nasazení
  • Hardware Úvahy
• Vyrovnávání zátěže
• Další odkazy

„Slovníček

„Vault cluster

Vault cluster je sada Vault procesů, které společně provozují Vault službu.Tyto procesy Vaultu mohou běžet na fyzických nebo virtuálních serverech nebo v kontejnerech.

„Cluster backendu úložiště Consul

HashiCorp doporučuje a podporuje použití Consulu jako backendu úložiště pro službuVault. Cluster Consul je sada procesů serveru Consul, které společně provozují službuConsul. Tyto procesy Consul mohou běžet na fyzických nebo virtuálních serverech nebo v kontejnerech.

„Zóna dostupnosti

Jednotná doména selhání na úrovni umístění, která hostí část nebo celý clusterVault. Latence mezi zónami dostupnosti by měla být < 8 ms pro cestu kolem. Jeden cluster Vault může být rozprostřen ve více zónách dostupnosti.

Příklady zóny dostupnosti v tomto kontextu jsou následující:

• Oddělená datová klec v datovém centru
• Oddělená klec v datovém centru, pokud je izolována od ostatních klecí všemi ostatními prostředky (napájení, síť atd.)
• Zóna dostupnosti v AWS, Azure nebo GCP

„Region

Geograficky oddělený soubor jedné nebo více zón dostupnosti. Regionby mohl hostit jeden nebo více clusterů Vault. V architektuře Vault není definován požadavek na maximální latenci mezi regiony. Jeden cluster Vault by nebyl rozprostřen ve více regionech.“

„Shrnutí návrhu

Tento návrh je doporučenou architekturou pro produkční prostředí, protožezajišťuje flexibilitu a odolnost.

Jedná se o hlavní doporučení architektury, aby servery Consul byly odděleny od serverů Vault a aby se cluster Consul používal pouze jako úložiště pro Vault a ne pro další funkce zaměřené na Consul (např. segmentace služeb a zjišťování služeb), které mohou přinést nepředvídatelné využití zdrojů. Oddělení Vaultu a Consulu umožňuje, aby každý z nich měl systém, který může být vhodně dimenzován z hlediska procesoru, paměti a disku. Consul je aplikace náročná na paměť, a proto je výhodné oddělit ji od vlastních zdrojů, aby se zabránilo sporům o zdroje nebo jejich nedostatku. Vyčlenění clusteru Consul jako backendu úložiště Vault je také výhodné, protože to umožňuje, aby byl cluster Consul upgradován pouze v případě potřeby zlepšení funkčnosti backendu úložiště Vault, což bude pravděpodobně mnohem méně často než u clusteru Consul, který je také používán pro zjišťování služeb a segmentaci služeb.

Konektivita mezi clusterem Consul a backendem probíhá přes protokol HTTP a měla by být zabezpečena pomocí protokolu TLSa také pomocí tokenu Consul, který zajistí šifrování veškerého provozu. Další informace naleznete v příručce VaultDeployment Guide. Vzhledem k tomu, že cluster Consul pro úložiště Vault může být používán jako doplněk a odděleně od clusteru Consul pro zjišťování služeb, doporučuje se, aby byl proces Consul pro úložiště spuštěn na jiných než výchozích portech, aby nedocházelo ke konfliktům s jinými funkcemi clusteru Consul. Toho dosáhnete nastavením clusteru úložiště Consul na běh na portech 7xxx a použitím tohoto portu jako portu úložiště v konfiguraci Vaultu. Doporučuje se také, aby byl Consul spuštěn pomocí TLS.

„Podrobnosti o síťovém připojení

Následující tabulka uvádí požadavky na síťový provoz pro uzly clusteru Vault.

„Alternativní konfigurace sítě

Vault lze nakonfigurovat několika samostatnými způsoby pro komunikaci mezi klastryVault a Consul:

• Pomocí IP adres hostitelů nebo názvů hostitelů, které jsou překládatelné prostřednictvím standardního jmenného subsystému
• Pomocí IP adres vyrovnávače zátěže nebo názvů hostitelů, které jsou překládatelné prostřednictvím standardního jmenného subsystému
• Pomocí připojeného clusteru Consul. DNS jako zjišťování služeb pro řešení koncových bodů Vaultu
• Použití samostatného clusteru Consul pro zjišťování služeb DNS jako zjišťování služeb pro řešení koncových bodů Vaultu

Všechny tyto možnosti jsou podrobněji probrány v Příručce k nasazení Vaultu.

„Tolerance selhání

Vault je navržen tak, aby zvládal různé scénáře selhání, které mají různoupravděpodobnost. Při nasazování clusteru Vault by měla být zvážena a navržena tolerance selhání, kteroupožadujete. V OSS Vault je doporučený počet instancí v clusteru 3, protože jakýkoli další počet by měl omezenou hodnotu. V systému Vault Enterprise je doporučený počet rovněž 3 v clusteru, ale lze jich použít více, pokud by byly výkonnostně odolné a pomáhaly by s pracovní zátěží pouze pro čtení. V clusteru Consul je od jedné do sedmi instancí. mělo by se jednat o lichý počet, aby bylo možné vždy vyřešit volby vedení. Doporučuje se, aby cluster Consul měl alespoň pět instancí, které jsou určeny k provádění funkcí backendového úložiště pouze pro cluster Vault.

„Uzel

Software clusteru Vault a Consul umožňuje doménu selhání na úrovni uzlů tím, že má replikaci v rámci clusteru. V jednom HA clusteru Vault sdílejí všechny uzly stejný základní backend úložiště, a tedy i data. Vault to řeší tak, že jeden ze serverů Vault získá zámek v rámci datového úložiště, aby se stal aktivním uzlem Vault, a ten má přístup k zápisu. Pokud kdykoli dojde ke ztrátě vedoucího uzlu, jeho místo plynule převezme jiný uzel Vault. Pro dosažení n-2 redundance (kdy lze tolerovat ztrátu 2 objektů v rámci domény selhání) by ideální velikost clusteru Vault byla 3. Consul dosahuje replikace a vedení pomocí svých protokolů consensus agossip. V těchto protokolech je vůdce volen konsensem, a proto musí vždy existovat aquorum aktivních serverů. Pro dosažení n-2 redundance je ideální velikost clusteru Consul 5. Další podrobnosti najdete v části ConsulInternals.

„Availability Zone

Typické rozložení v cloudovém prostředí spočívá v rozdělení uzlů Consul/Vault do jednotlivých zón dostupnosti (AZ) v rámci sítě s vysokou šířkou pásma a nízkou latencí, jako je například oblast AWS, což však nemusí být možné v instalaci datového centra, kde je pouze jedno DC v rámci požadované úrovně latence.

Je důležité pochopit změnu požadavku nebo osvědčených postupů, která nastala v důsledku přechodu k většímu využití vysoce distribuovaných systémů, jako je Consul. Při provozování prostředí složených zdistribuovaných systémů je nutný posun v koeficientu redundance podřízených komponent. Consul se při organizaci a replikaci informací spoléhá na konsenzuální vyjednávání, a proto musí prostředí poskytovat 3 unikátní resilientní cesty, aby byla zajištěna smysluplná spolehlivost. Konsensuálnísystém v podstatě vyžaduje, aby v každém okamžiku byla k dispozici prostá většina uzlů. Vpřípadě 3 uzlů musí být k dispozici 2 uzly. Pokud jsou tyto 3 uzly umístěny ve dvou poruchových doménách, existuje 50% šance, že ztráta jedné poruchové domény povede k úplnému výpadku.

„Region

Pro ochranu proti selhání na úrovni regionu a také pro zajištění dalších možností geografického škálování nabízí Vault Enterprise:

• Replikace pro obnovení po havárii
• Výkonná replikace

Plný popis těchto možností naleznete v Doporučených vzorech o replikaci Vault.

Vzhledem k výše uvedeným omezením je doporučená architektura sVault a Consul Enterprise distribuovanými ve třech zónách dostupnosti v rámci clusteru a pro clustery, které mají být replikovány napříč regiony pomocí DR aPerformance replikace. Existuje také několik „Best Case“ architekturřešení pro jednu a dvě zóny dostupnosti a také pro Consul OSS. Nejedná se o doporučenou architekturu, ale o nejlepší řešení, pokud je vaše nasazení omezeno verzí Consul nebo počtem zón dostupnosti.

„Doporučená architektura

Níže uvedená architektura je doporučeným nejlepším přístupem k nasazení Vaultu a měla by být cílovou architekturou pro každou instalaci. Ta je rozdělena na dvě části:

• Klastr trezorů – Toto je doporučená architektura pro klastr trezorů jako jedinou entitu, ale měla by také používat replikaci podle druhého schématu
• Replikace trezorů – Toto je doporučená architektura pro více klastrů trezorů, která umožňuje regionální, výkonnostní a disaster recovery.

„Nasazení v jednom regionu (Enterprise)

V tomto scénáři jsou uzly trezoru a jeho přidružený cluster Consul hostovány mezi třemi zónami dostupnosti. Toto řešení má n-2 na úrovni uzlů pro Vault a n-3 na úrovni uzlů pro Consul. Na úrovni zóny dostupnosti je Vault na úrovni n-2 a Consul na úrovni n-1. Od návrhu OSS se liší tím, že cluster Consul má šest uzlů, přičemž tři z nich jsou nehlasujícími členy. ClusterConsul je nastaven pomocí RedundancyZones tak, aby v případě selhání některého uzlu byl nehlasující člen povýšen autopilotem na plnohodnotného člena a bylo tak zachováno kvorum.

„Multiple Region Deployment (Enterprise)

„Reference Diagram Resilience against Region Failure

V tomto scénáři jsou clustery replikovány, aby se ochránily před selháním celého regionu. Existují tři clustery Performance Replica Vault (clustery A, B, C)každý s vlastním clusterem DR (clustery D, E, F) v jiném regionu. Každýcluster má svůj přidružený cluster Consul pro backend úložiště.

Tato architektura umožňuje n-2 na úrovni regionu za předpokladu, že všechny secrety a secrety engine jsou replikovány ve všech clusterech. Výpadek celého Regionu1 by vyžadoval povýšení clusteru DR F. Jakmile by se tak stalo, řešení Vaults by bylo plně funkční s určitou ztrátou redundance až do obnovení Regionu1. Aplikace by se nemusely znovu ověřovat, protože cluster DR pro každý selhaný cluster by obsahoval všechny pronájmy a tokeny.

„Referenční schéma Odolnost proti selhání clusteru

Toto řešení má plnou odolnost na úrovni clusteru, ale nechrání proti selhání regionu, protože clustery DR pro repliky Performance jsou ve stejném regionu. Existují určité případy použití, kdy se jedná o preferovanou metodu, kdy data nelze replikovat do jiných regionů z důvodu omezení správy, jako je například GDPR. Také některé infrastrukturní rámce nemusí mít možnost směrovat provoz aplikací do různých regionů.

„Best Case Architecture

V některých nasazeních mohou existovat nepřekonatelná omezení, která znamenají, že doporučená architektura není možná. To může být způsobeno nedostupností zón nebo použitím OSS Vault. V těchto případech níže uvedené architektury podrobně popisují nejlepší dostupné možnosti.

Všimněte si, že v těchto následujících architekturách může být vedoucím uzlem serveru Consul kterýkoli z pěti uzlů serveru Consul a aktivním uzlem Vaultu může být kterýkoli ze tří uzlů Vaultu

„Nasazení Vaultu v jedné zóně dostupnosti (všechny)

V tomto scénáři jsou všechny uzly Vaultu a jeho přidružený cluster Consul umístěny v jedné zóně dostupnosti. Toto řešení má jediný bod selhánína úrovni zóny dostupnosti, ale n-2 na úrovni uzlů pro Consul iVault. Toto není architektura doporučená společností Hashicorp pro produkční systémy, protože neexistuje žádná redundance na úrovni zóny dostupnosti. Také zde není možnost DR, a proto by minimálně toto mělo mít repliku DR voddělené oblasti.

„Nasazení Vaultu ve dvou zónách dostupnosti (OSS)

V tomto scénáři jsou uzly Vaultu a jeho přidružený cluster Consul umístěny mezi dvěma zónami dostupnosti. Toto řešení má n-2 na úrovni uzlů pro Vault a Consul a n-1 pro Vault na úrovni zóny dostupnosti, alepřidání zóny dostupnosti výrazně nezvyšuje dostupnost clusteru Consul. Je to proto, že protokol Raft vyžaduje aquorum (n/2)+1, a pokud by ve výše uvedeném diagramu selhala zóna B, pak by cluster nebyl usnášeníschopný, a proto by také selhal. Toto není architektura doporučená společností Hashicor pro produkční systémy, protože na úrovni zóny dostupnosti existuje pouze částečná redundance a selhání zóny dostupnosti nemusí mít za následek výpadek.

„Nasazení Trezoru ve dvou zónách dostupnosti (Enterprise)

Vzhledem k potřebě udržet kvorum v clusteru Consul není ideální mít pouze dvě zóny dostupnosti. Neexistuje způsob, jak rozložit cluster Consulve dvou AZ s jakoukoli zárukou přidané odolnosti. Nejlepším řešením v systému Vault Enterprise je považovat oba AZ za regiony a v každém z nich mít samostatné Vaultclustery.

Sekundární Vault cluster může být buď Performance Replica, nebo DR Replica, přičemž každý z nich má své vlastní výhody:

• PR secondary: Pokud je adresa Vaultu spravována Consul nebo load balancerem, pak selhání jednoho z clusterů povede k přesměrování provozu do druhého clusteru bez výpadku za předpokladu, že ve vaší aplikaci nebo agentovi Vaultu existuje logika pro správu opětovného vyžádání tokenů, které nejsou replikoványmezi clustery.
• DR sekundární: V tomto případě bude výpadek primárního clusteru mít za následek nutnost zásahu operátora pro povýšení DR na primární, ale protože jsou všechny smlouvy a tokeny replikovány, nebude potřeba žádná dodatečná logika v aplikaci, která by to řešila.

„Nasazení Vaultu ve třech zónách dostupnosti (OSS)

V tomto scénáři jsou uzly Vaultu a přidružený cluster Consul umístěny mezi tři zóny dostupnosti. Toto řešení má n-2 na úrovni uzlů pro Vault a Consul a n-2 pro Vault na úrovni zóny dostupnosti. n-1 na úrovni zóny dostupnosti pro Consul a jako takové jepovažováno za nejodolnější ze všech architektur pro jeden cluster Vaults backendem úložiště Consul pro produkt OSS.

„Vault Replication (Enterprise Only)

V těchto architekturách je Vault Cluster znázorněn jako jediná entita a byl by jedním z jednotlivých clusterů podrobně popsaných výše na základě počtu zón dostupnosti. Více clusterů Vault, které fungují jako jediné řešení Vaults a replikují se mezi sebou, je k dispozici pouze v produktu Enterprise Vault. OSSVault lze nastavit ve více clusterech, ale každý z nich by byl samostatným řešením Vault a nepodporoval by replikaci mezi clustery.

Dokumentace k Vaultu poskytuje podrobnější informace o možnostech replikace v rámci VaultEnterprise.

„Replikace výkonu

Replikace výkonu Vaultu umožňuje správu tajemství na mnoha místech.Statická tajemství, metody ověřování a zásady autorizace jsou replikovány tak, aby byly aktivní a dostupné ve více lokalitách, avšak leasestokeny a dynamická tajemství nikoli.

„Replikace pro zotavení po havárii

Replikace pro zotavení po havárii Vaultu zajišťuje, aby byl pohotovostní cluster Vaultu synchronizován klíči s aktivním clusterem Vaultu. Tento režim replikace zahrnujedata, jako jsou efemérní autentizační tokeny, časové informace o tokenech a také údaje o používání tokenů. To zajišťuje agresivní cíl bodu obnovy v prostředích, kde je největším zájmem zabránit ztrátě efemérních provozních dat. V každém podnikovém řešení jsou repliky pro zotavení po havárii považovány za nezbytné.

„Poškození nebo sabotáž Disaster Recovery

Dalším běžným scénářem ochrany, který se častěji vyskytuje v cloudových prostředích, jež poskytují velmi vysokou úroveň vnitřní odolnosti, může být úmyslné nebo náhodné poškození dat a konfigurace a/nebo ztráta kontroly nad cloudovým účtem. Replikace DR služby Vault je navržena tak, aby replikovala živá data,která by šířila úmyslné nebo náhodné poškození či smazání dat. Pro ochranu před těmito možnostmi byste měli zálohovat backend úložiště Vault.To je podporováno funkcí ConsulSnapshot, kterou lze automatizovat pro pravidelné archivní zálohování. Studenou lokalitu nebo novou infrastrukturu lze opětovně hydratovat ze snímku Consul.

„Poznámky k replikaci

Není stanoven žádný limit počtu clusterů v rámci replikační sady. Největší nasazení se dnes pohybují v rozmezí 30+ klastrů. Ke clusteru Performance Replica může být přidružen cluster Disaster Recovery a může se také replikovat do více clusterů Disaster Recovery.

Když může cluster Vault vlastnit replikační roli (nebo role), nejsou vyžadovány žádné zvláštní ohledy na infrastrukturu a clustery mohou převzít (nebo být povýšeny či degradovány) do jiné role. Zvláštní okolnosti související s filtry připojení a použitím hardwarového bezpečnostního modulu (HSM) mohou omezitpřemístění rolí, ale ty jsou založeny na specifických konfiguracích organizace.

„Úvahy související s integrací HSM

Použití replikace s klastry Vault integrovanými s hardwarovým bezpečnostním modulem (HSM) nebo cloudovými zařízeními pro automatické odpečetění má některépodrobnosti, kterým je třeba porozumět ve fázi plánování.

• Pokud primární výkonný cluster používá HSM, musí všechny ostatní clustery v rámci této replikační sady používat HSM také.
• Pokud výkonný primární cluster NEpoužívá HSM (používá metodu sdílení tajemství Shamir), mohou být clustery v rámci této replikační sady smíšené, takže některé mohou používat HSM, jiné Shamir.

Toto chování je v návrhu. Navazující cluster Shamir představuje potenciálnívektor útoku v replikační skupině, protože prahová hodnota držitelů klíčů by mohlaznovu vytvořit hlavní klíč; tedy obejít ochranu klíčů navazujícího HSM.

„Požadavky na systém nasazení

Následující tabulka obsahuje pokyny pro dimenzování serveru. Za zvláštní zmínku stojí důrazné doporučení vyhnout se procesorům s nefixním výkonem, neboli BurstableCPU v terminologii AWS, jako jsou instance řady T.

„Sizing for Vault Servers

.

„Sizing for Consul Servers

„Hardware Considerations

Kategorie malých rozměrů by byla vhodná pro většinu počátečních produkčních nasazení nebo pro vývojová/testovací prostředí.

Kategorie velkých rozměrů je určena pro produkční prostředí, kde je trvale vysoké pracovní zatížení. To může být velký počet transakcí, velký počettajností nebo kombinace obojího.

Obecně budou požadavky na zpracování záviset na zátěži šifrování a zátěži zpráv (operace za sekundu a typy operací). Požadavky na paměť budou záviset na celkové velikosti tajemství/klíčů uložených vpaměti a měly by být dimenzovány podle těchto údajů (stejně jako úložiště na pevném disku). Samotný Trezor má minimální požadavky na úložiště, ale základní úložný backend by měl mít relativně výkonný subsystém pevného disku.

Pokud se často generuje/rotuje mnoho tajemství, bude třeba tyto informace často vyplavovat na disk a může to mít vliv na výkon, pokud se používají pomalejší pevné disky.

Funkcí serverů Consul v tomto nasazení je sloužit jako úložný backend pro Trezor. To znamená, že veškerý obsah uložený pro perzistenci ve Vaultu jezašifrován Vaultem a v klidovém stavu zapsán do backendu úložiště. Tato data se zapisují do sekce úložiště klíč-hodnota katalogu služeb Consul, kterýjevyžadováno, aby byl celý uložen v paměti na každém serveru Consul. To znamená, že paměť může být omezením při škálování s tím, jak se více klientů ověřuje do Vaultu, více tajemství je trvale uloženo ve Vaultu a více dočasných tajemství je pronajato z Vaultu. To má také za následek nutnost vertikálního škálování paměti serveruConsul, pokud je požadováno další místo, protože celý katalog služeb je uložen v paměti na každém serveru Consul.

Dále je pro servery Vault a Consul společným hlediskem propustnost sítě. Vzhledem k tomu, že oba systémy jsou řízeny rozhraním HTTPS API, všechny příchozí požadavky,komunikace mezi Vaultem a Consul, základní drbová komunikace mezi členy clusteru Consul, komunikace s externími systémy (podle konfigurace auth nebo secretengine a některých konfigurací protokolování auditu) a odpovědi spotřebovávají šířku pásma sítě.

Vzhledem k síťovému výkonu při provozu clusteru Consul by replikace datových sad Vaultu přes hranice sítě měla být dosažena spíše prostřednictvím replikace výkonu nebo DR, než rozprostřením clusteru Consul přes síť a fyzické hranice. Pokud je jeden cluster Consul rozprostřen napříč vzdálenými nebo meziregionálními segmenty sítě, může to u některých poskytovatelů cloudu způsobit problémy se synchronizací v rámci clusteru nebo dodatečné poplatky za přenos dat.

„Další úvahy

Doporučení pro produkční zabezpečení systému Vaultposkytují pokyny pro osvědčené postupy pro produkční zabezpečení nasazení systému Vault.

„Vyrovnávání zátěže

„Vyrovnávání zátěže pomocí rozhraní Consul

Consul může poskytovat funkce vyrovnávání zátěže prostřednictvím zjišťování služeb, ale vyžaduje, aby všichni klienti Vaultu znali Consul. To znamená, že klient můžepoužívat rozhraní Consul DNS nebo API k určení aktivního uzlu Trezoru. Klient může přistupovat ke službě Vault prostřednictvím adresy URL, jako je následující:http://active.vault.service.consul:8200

Toto spoléhá na systém rozlišení DNS operačního systému a požadavek by mohl být předán službě Consul, aby získala odpověď na skutečnou adresu IP. Tato operace může být pro starší aplikace zcela transparentní a fungovala by stejně jako atypická operace rozlišení DNS. Další informace naleznete v části Consul DNSforwarding

„Vyrovnávání zátěže pomocí externího vyrovnávače zátěže

Externí vyrovnávače zátěže jsou podporovány jako vstupní bod do clusteru Vault. Externí vyrovnávač zátěže by měl dotazovat koncový bodsys/health, aby zjistil aktivní uzel a podle toho směroval provoz. Vyrovnávač zátěže by měl být nakonfigurován tak, aby každému uzlu v clusteru zaslal požadavek HTTP na následující adresu URL: http://<Vault Node URL>:8200/v1/sys/health

Aktivní uzel Vault odpoví 200, zatímco pohotovostní uzly vrátí odpověď 4xx.

Následující příklad konfiguračního bloku z HAProxy pro ilustraci:

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

Všimněte si, že výše uvedený blok by mohl být generován pomocí Consul (s consul-template)při použití softwarového load balanceru. To by mohl být případ, kdy je loadbalancer softwarový, například Nginx, HAProxy nebo Apache.

Příklad šablony Consul pro výše uvedený blok 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}}

„Zpracování adres IP klienta

Existují dvě podporované metody zpracování adres IP klienta za proxy serverem nebo zařízením pro vyrovnávání zátěže: X-Forwarded-ForHeadersa PROXYv1.Obě vyžadují důvěryhodný load balancer a IP adresu, která musí být uvedena jako povolenáadresa, aby byly dodrženy osvědčené bezpečnostní postupy.

„Další odkazy

• Dokumentace architektury Vault vysvětlujekaždou komponentu Vault
• Chcete-li integrovat Vault se stávajícím serverem LDAP, nahlédněte do dokumentaceLDAP Auth Method
• Pro programové generování tokenu pro stroj nebo aplikaci nahlédněte do návodu AppRole PullAuthentication
• Consul je nedílnou součástí provozu odolného clusteru Vault bez ohledu na umístění. Chcete-li se dozvědět více, nahlédněte do online dokumentace Consuldu.

„Další kroky

• Přečtěte si příručku Production Hardening, kde se dozvíte osvědčené postupy pro produkční nasazení Vaultu.
• Přečtěte si příručku Deployment Guide, kde se dozvíte kroky potřebné k instalaci a konfiguraci jednoho clusteru HashiCorp Vault.

.