Free Press

Obiectivul acestui document este de a recomanda practicile de implementare a Vault de la HashiCorp. Această arhitectură de referință transmite o arhitectură generalăcare ar trebui adaptată pentru a răspunde nevoilor specifice ale fiecărei implementări.

În acest ghid sunt abordate următoarele subiecte:

• Rezumatul proiectării
  • Conectivitatea rețelei
  • Toleranța la erori
• Arhitectura recomandată
  • Dezvoltare într-o singură regiune (Enterprise)
  • Dezvoltare în mai multe regiuni Deployment (Enterprise)
• Arhitectura de cel mai bun caz
  • Deployment of Vault in one Availability Zone (all)
  • Deployment of Vault in two Availability Zones (OSS)
  • Deployment of Vault in două zone de disponibilitate (Enterprise)
  • Dezvoltarea Vault în trei zone de disponibilitate (OSS)
• Vault Replication (numai pentru Enterprise)
• Cerințe de sistem pentru desfășurare
  • Hardware Considerații
• Echilibrarea sarcinii
• Referințe suplimentare

„Glosar

„Cluster Vault

Un cluster Vault este un set de procese Vault care împreună execută un serviciu Vault.Aceste procese Vault pot fi rulate pe servere fizice sau virtuale, sau în containere.

„Cluster de backend de stocare Consul

HashiCorp recomandă și susține utilizarea Consul ca backend de stocare pentruVault. Un cluster Consul este un set de procese de servere Consul care împreună execută un serviciuConsul. Aceste procese Consul ar putea rula pe servere fizice sau virtuale, sau în containere.

„Availability Zone

Un singur domeniu de eșec la nivel de locație care găzduiește o parte sau întregul clusterVault. Latența între zonele de disponibilitate ar trebui să fie de < 8ms pentru călătoria în jurul valorii de. Un singur cluster Vault poate fi răspândit în mai multe zone de disponibilitate.

Exemple de zonă de disponibilitate în acest context sunt:

• Un centru de date izolat
• O cușcă izolată într-un centru de date dacă este izolată de alte cuști prin toate celelalte mijloace (alimentare, rețea etc)
• O zonă de disponibilitate în AWS, Azure sau GCP

„Regiune

O colecție separată geografic de una sau mai multe zone de disponibilitate. O regiunear găzdui unul sau mai multe clustere Vault. Nu există o cerință de latență maximă definită între regiuni în arhitectura Vault. Un singur cluster Vault nu ar fi răspândit în mai multe regiuni.

„Rezumat al proiectului

Acest proiect este arhitectura recomandată pentru mediile de producție, deoarece oferă flexibilitate și rezistență.

Este o recomandare majoră de arhitectură ca serverele Consul să fie separatede serverele Vault și ca clusterul Consul să fie utilizat doar ca un backend de stocare pentru Vault și nu pentru alte funcționalități axate pe Consul (de exemplu, segmentarea serviciilor și descoperirea serviciilor) care pot introduce o utilizare imprevizibilă a resurselor. Separarea Vault și Consul permite ca fiecare dintre acestea să aibă un sistem care poate fi dimensionat în mod corespunzător în ceea ce privește CPU, memoria și discul. Consul este o aplicație cu utilizare intensivă a memoriei și, prin urmare, separarea acesteia de propriile resurse este avantajoasă pentru a preveni conflictul de resurse sau foametea. Dedicarea unui cluster Consul ca backend de stocare Vault este, de asemenea, avantajoasă, deoarece acest lucru permite ca clusterul Consul să fie actualizat doar în funcție de necesități pentru a îmbunătăți funcționalitatea backend-ului de stocare Vault.Acest lucru va fi probabil mult mai puțin frecvent decât un cluster Consul care este utilizat și pentru descoperirea și segmentarea serviciilor.

Conectivitatea între Vault și backend-ul Consul se face prin HTTP și ar trebui să fie securizată cu TLS, precum și cu un token Consul pentru a asigura criptarea întregului trafic. Consultați Ghidul de implementare VaultDeployment pentru mai multe informații. Deoarece clusterul Consul pentru stocarea Vault poate fi utilizat în plus și separat de un cluster Consul pentru descoperirea de servicii, se recomandă ca procesul Consul de stocare să fie rulat pe porturi care nu sunt predefinite, astfel încât să nu intre în conflict cu alte funcționalități Consul. Setarea clusterului de stocare Consul pentru a rula pe porturile 7xxx și utilizarea acestuia ca port de stocare în configurația Vault va realiza acest lucru. De asemenea, se recomandă ca Consul să fie rulat folosind TLS.

„Network Connectivity Details

Următorul tabel prezintă cerințele privind traficul de rețea pentru nodurile cluster Vault.

.

.

„Configurații alternative de rețea

Vault poate fi configurat în mai multe moduri distincte pentru comunicațiile dintre clustereleVault și Consul:

• Utilizarea adreselor IP ale gazdelor sau a numelor de gazdă care pot fi rezolvate prin subsistemul cu nume standard
• Utilizarea adreselor IP ale echilibrului de sarcină sau a numelor de gazdă care pot fi rezolvate prin subsistemul cu nume standard
• Utilizarea clusterului Consul atașat. DNS as service discovery to resolve Vaultendpoints
• Utilizarea unui cluster de descoperire a serviciilor Consul separat DNS as service discovery toresolve Vault endpoints

Toate aceste opțiuni sunt explorate mai mult în Ghidul de implementare Vault.

„Failure Tolerance

Vault este conceput pentru a gestiona diferite scenarii de eșec care au diferiteprobabilități. Atunci când se implementează un cluster Vault, toleranța la eșecuri pe care o solicitați ar trebui să fie luată în considerare și proiectată. În OSS Vault, numărul recomandat de instanțe este de 3 într-un cluster, deoarece orice număr mai mare ar avea o valoare limitată. În Vault Enterprise, numărul recomandat este, de asemenea, de 3 într-un cluster, dar se pot folosi mai multe dacă acestea sunt instanțe de performanță pentru a contribui la un volum de lucru numai pentru citire. Clusterul Consul este de la una la șapte instanțe.Acesta ar trebui să fie un număr impar pentru a permite ca alegerile de conducere să se rezolve întotdeauna. Se recomandă ca clusterul Consul să fie de cel puțin cinci instanțe care sunt dedicate îndeplinirii funcțiilor de stocare backend doar pentru clusterul Vault.

„Node

Software-ul clusterului Vault și Consul permite un domeniu de eșec la nivel de nod, având replicare în cadrul clusterului. Într-un singur cluster HA Vault, toate nodurile împart același backend de stocare de bază și, prin urmare, aceleași date. Vaulta reușește să rezolve acest lucru prin obținerea de către unul dintre serverele Vault a unui blocaj în cadrul depozitului de date pentru a deveni nodul Vault activ, iar acesta are acces la scriere. Dacă, în orice moment, liderul se pierde, atunci un alt nod Vault îi va lua locul fără probleme. Pentru a obține o redundanță n-2 (în cazul în care se poate tolera pierderea a 2 obiecte din domeniul de eroare), dimensiunea ideală a unui cluster Vault ar fi de 3. Consul realizează replicarea și conducerea prin utilizarea protocoalelor sale de consens șigossip. În aceste protocoale, un lider este ales prin consens și astfel trebuie să existe întotdeauna un aquorum de servere active. Pentru a obține o redundanță n-2, dimensiunea ideală a unui cluster Consul este de 5. Pentru mai multe detalii, consultați ConsulInternals.

„Availability Zone

Distribuția tipică într-un mediu cloud este de a răspândi nodurile Consul/Vault în zone de disponibilitate (AZ) separate în cadrul unei rețele cu lățime de bandă mare și latență redusă, cum ar fi o regiune AWS, însă acest lucru poate să nu fie posibil într-o instalație de centru de date în care există doar un singur DC în cadrul nivelului de latență necesar.

Este important să se înțeleagă o modificare a cerințelor sau a celor mai bune practici care a apărut ca urmare a evoluției către o mai mare utilizare a sistemelor cu grad ridicat de distribuție, cum ar fi Consul. Atunci când se exploatează medii compuse din sistemedistribuite, este necesară o schimbare a coeficientului de redundanță a componentelor subiacente. Consul se bazează pe negocierea consensuală pentru a organiza și a reproduce informațiile și, prin urmare, mediul trebuie să ofere 3 căi de reziliență unice pentru a asigura o fiabilitate semnificativă. În esență, un sistem de consens necesită ca o majoritate simplă de noduri să fie disponibilă în orice moment. În exemplul celor 3 noduri, trebuie să existe 2 noduri disponibile. Dacă aceste 3 noduri sunt plasate în două domenii de avarie, există o șansă de 50% ca pierderea unui singur domeniu de avarie să ducă la o întrerupere completă.

„Region

Pentru a se proteja împotriva unei defecțiuni la nivel de regiune, precum și pentru a oferi capacități suplimentare de scalare geografică, Vault Enterprise oferă:

• Disaster Recovery Replication
• Performance Replication

Vă rugăm să consultați Recommended Patterns on Vault Replication pentru o descriere completă a acestor opțiuni.

Din cauza constrângerilor enumerate mai sus, arhitectura recomandată este cuVault și Consul Enterprise distribuite în trei zone de disponibilitate în cadrul unui cluster și pentru ca clusterele să fie replicate între regiuni utilizând replicarea DR șiPerformance. Există, de asemenea, mai multe soluții de arhitectură „Best Case” pentru una și două zone de disponibilitate și, de asemenea, pentru Consul OSS. Acestea nu reprezintă arhitectura recomandată, dar sunt cele mai bune soluții în cazul în care implementarea dumneavoastră este restricționată de versiunea Consul sau de numărul de zone de disponibilitate.

„Arhitectura recomandată

Arhitectura de mai jos este cea mai bună abordare recomandată pentru implementarea Vault șiar trebui să fie arhitectura țintă pentru orice instalare. Aceasta este împărțită în două părți:

• Vault cluster – Aceasta este arhitectura recomandată pentru un vault cluster ca entitate unică, dar ar trebui, de asemenea, să utilizeze replicarea conform celei de-a doua diagrame
• Vault replication – Aceasta este arhitectura recomandată pentru mai multe vaultclustere pentru a permite o recuperare regională, de performanță și în caz de dezastru.

„Single Region Deployment (Enterprise)

În acest scenariu, nodurile Vault și clusterul Consul asociat acestora sunt găzduite între trei Zone de disponibilitate. Această soluție are un n-2 la nivel de nod pentru Vault și un n-3 la nivel de nod pentru Consul. La nivelul Zonei de disponibilitate, Vault se află la n-2 și Consul la n-1. Această soluție diferă de proiectul OSS prin faptul că clusterul Consul are șase noduri, dintre care trei sunt membri fără drept de vot. Clusterul Consul este configurat folosind RedundancyZones astfel încât, dacă vreun nod ar eșua, un membru fără drept de vot ar fi promovat de Autopilot pentru a deveni membru cu drepturi depline și a menține astfel cvorumul.

„Multiple Region Deployment (Enterprise)

„Reference Diagram Resilience against Region Failure

În acest scenariu, clusterele sunt replicate pentru a se proteja împotriva unei eșecuri a întregii regiuni. Există trei clustere Performance Replica Vault (clusterele A, B, C)fiecare cu propriul său cluster DR (clusterele D, E, F) într-o regiune diferită. Fiecare cluster are clusterul Consul asociat pentru backend-ul de stocare.

Această arhitectură permite n-2 la nivel de regiune cu condiția ca toate secretele și motoarele de secrete să fie replicate în toate clusterele. Eșecul regiunii1 complete ar necesita promovarea clusterului DR F. Odată ce acest lucru a fost făcut, soluția Vaultsolution ar fi pe deplin funcțională cu o anumită pierdere de redundanță până la restabilirea Region1. Aplicațiile nu ar trebui să se autentifice din nou, deoarece clusterul DR pentru fiecare cluster eșuat ar conține toate contractele de închiriere și token-urile.

„Diagrama de referință Reziliența împotriva eșecului clusterului

Această soluție are o reziliență completă la nivel de cluster, dar nu se protejează împotriva eșecului de regiune, deoarece clusterele DR pentru replicile de performanță se află în aceeași regiune. Există anumite cazuri de utilizare în care aceasta este metoda preferată atunci când datele nu pot fi replicate în alte regiuni din cauza unor restricții de guvernanță, cum ar fi GDPR. De asemenea, este posibil ca unele cadre de infrastructură să nu aibă capacitatea de a direcționa traficul aplicațiilor către diferite regiuni.

„Best Case Architecture

În unele implementări pot exista restricții insurmontabile care înseamnă că arhitectura recomandată nu este posibilă. Acest lucru se poate datora lipsei de zone disponibile sau din cauza utilizării Vault OSS. În aceste cazuri, arhitecturile de mai jos detaliază cele mai bune opțiuni disponibile.

Rețineți că, în aceste arhitecturi următoare, liderul Consul ar putea fi oricare dintre cele cinci noduri de server Consul, iar nodul activ Vault ar putea fi oricare dintre cele trei noduri Vault

„Deployment of Vault in one Availability Zone (all)

În acest scenariu, toate nodurile Vault și clusterul Consul asociat sunt găzduite într-o singură zonă de disponibilitate. Această soluție are un singur punct de eșec la nivelul zonei de disponibilitate, dar un n-2 la nivel de nod atât pentru Consul, cât și pentruVault. Aceasta nu este arhitectura recomandată de Hashicorp pentru sistemele de producție, deoarece nu există redundanță la nivelul zonei de disponibilitate. De asemenea, nu există nici o capabilitate de DR și astfel, cel puțin acest lucru ar trebui să aibă cel puțin o replică DR într-o Regiune separată.

„Deployment of Vault in two Availability Zones (OSS)

În acest scenariu, nodurile Vault și clusterul Consul asociat acestuia sunt găzduite între două Zone de Disponibilitate. Această soluție are un n-2 la nivel de nod pentru Vault și Consul și un n-1 pentru Vault la nivel de zonă de disponibilitate, daradăugarea unei zone de disponibilitate nu crește semnificativ disponibilitatea clusterului Consul. Acest lucru se datorează faptului că protocolul Raft necesită un cvorum de (n/2)+1, iar dacă Zona B ar eșua în diagrama de mai sus, atunci clusterul nu ar avea cvorum și, prin urmare, ar eșua și el. Aceasta nu este o arhitectură recomandată de Hashicor pentru sistemele de producție, deoarece există doar o redundanță parțială la nivelul Zonei de disponibilitate, iar o defecțiune a unui primar al Zonei de disponibilitate ar putea să nu ducă la o întrerupere.

„Implementarea Vault în două Zone de disponibilitate (Enterprise)

Datorită necesității de a menține cvorumul în clusterul Consul, a avea doar 2Zone de disponibilitate nu este ideal. Nu există nicio modalitate de a răspândi un cluster Consulîn două AZ-uri cu vreo garanție de reziliență suplimentară. Cea mai bună soluție înVault Enterprise este de a trata cele două AZ ca regiuni și de a avea Vaultclustere separate în fiecare dintre ele.

Clusterul Vault secundar poate fi fie o replică de performanță, fie o replică DR, fiecare având propriile avantaje:

• PR secundar: Dacă adresa Vault este gestionată de Consul sau de un load balancer, atunci o defecțiune a oricăruia dintre cele două clustere va avea ca rezultat direcționarea traficului către celălalt cluster fără întreruperi, cu condiția să existe o logică în aplicația dvs. sau în agentul Vault pentru a gestiona re-solicitarea de jetoane care nu sunt replicateîntre clustere.
• DR secundar: În acest caz, eșecul clusterului primar va avea ca rezultat necesitatea intervenției operatorului pentru a promova DR în clusterul primar, dar, deoarece toate contractele de închiriere și token-urile sunt replicate, nu ar fi nevoie de nicio logică suplimentară în aplicație pentru a gestiona acest lucru.

„Deployment of Vault in three Availability Zones (OSS)

În acest scenariu, nodurile din Vault și clusterul Consul asociat sunt găzduite între trei zone de disponibilitate. Această soluție are un n-2 la nivel de nod pentru Vault și Consul și n-2 pentru Vault la nivel de zonă de disponibilitate.Aceasta are, de asemenea, un n-1 la nivel de zonă de disponibilitate pentru Consul și, ca atare, esteconsiderată cea mai rezistentă dintre toate arhitecturile pentru un singur cluster Vaultcu un backend de stocare Consul pentru produsul OSS.

„Vault Replication (Enterprise Only)

În aceste arhitecturi, clusterul Vault este ilustrat ca o singură entitate și ar fi unul dintre clusterele unice detaliate mai sus în funcție de numărul de zone de disponibilitate. Clusterele multiple Vault care acționează ca o singură soluție Vaultsolution și replicarea între ele este disponibilă numai în Enterprise Vault. OSSVault poate fi configurat în mai multe clustere, dar fiecare dintre acestea ar fi soluțiiVault individuale și nu ar suporta replicarea între clustere.

Documentația Vault oferă informații mai detaliate despre capacitățile de replicare din VaultEnterprise.

„Performance Replication

Replicarea performanței Vault permite gestionarea secretelor pe mai multe site-uri.Secretele statice, metodele de autentificare și politicile de autorizare sunt replicate pentru a fi active și disponibile în mai multe locații, însă leasestokens și secretele dinamice nu sunt.

„Disaster Recovery Replication

Replicarea pentru recuperarea în caz de dezastru a Vault asigură că un cluster Vault în așteptare este keptsincronizat cu un cluster Vault activ. Acest mod de replicare includedate cum ar fi jetoane de autentificare efemere, informații despre jetoane bazate pe timp, precum și date de utilizare a jetoanelor. Acest lucru asigură un obiectiv agresiv al punctului de recuperare în mediile în care prevenirea pierderii datelor operaționale efemere este cea mai mare preocupare. În orice soluție de întreprindere, replicile de recuperare în caz de dezastru suntconsiderate esențiale.

„Corupție sau sabotaj Recuperare în caz de dezastru

Un alt scenariu comun împotriva căruia trebuie să ne protejăm, mai răspândit în mediile cloud care oferă niveluri foarte ridicate de reziliență intrinsecă, ar putea fi coruperea intenționată sau accidentală a datelor și a configurației și/sau o pierdere a controlului asupra contului cloud. Replicarea DR a Vault este concepută pentru a replica date live,ceea ce ar propaga corupția sau ștergerea intenționată sau accidentală a datelor. Pentru a vă proteja împotriva acestor posibilități, ar trebui să faceți o copie de rezervă a backend-ului de stocare al Vault.Acest lucru este susținut prin intermediul funcției ConsulSnapshot, care poate fi automatizată pentru copii de rezervă arhivate periodic. Un site rece sau o infrastructură nouăpoate fi rehidratat de la un instantaneu Consul.

„Replication Notes

Nu există o limită stabilită pentru numărul de clustere în cadrul unui set de replicare. Cele mai mari implementări de astăzi sunt în intervalul de peste 30 de clustere. Un cluster Performance Replica poate avea asociat un cluster Disaster Recovery și poate, de asemenea, replica către mai multe clustere Disaster Recovery.

În timp ce un cluster Vault poate deține un rol (sau mai multe roluri) de replicare, nu sunt necesare considerații speciale în ceea ce privește infrastructura, iar clusterele pot asuma (sau pot fi promovate sau retrogradate) un alt rol. Circumstanțe speciale legate de filtrele de montare și de utilizarea Hardware Security Module (HSM) pot limita schimbarea rolurilor, dar acestea se bazează pe configurațiile specifice ale organizației.

„Considerații legate de integrarea HSM

Utilizarea replicării cu clustere Vault integrate cu dispozitive Hardware Security Module(HSM) sau dispozitive de desigilare automată în cloud pentru operațiuni automate de desigilare are uneledetalii care trebuie înțelese în timpul fazei de planificare.

• Dacă un cluster primar de performanță utilizează un HSM, toate celelalte clustere din cadrul acelui set de replicare trebuie să utilizeze și ele un HSM.
• Dacă un cluster primar de performanță NU utilizează un HSM (utilizează metoda de partajare a secretelor Shamir), clusterele din cadrul acelui set de replicare pot fi amestecate, astfel încât unele pot utiliza un HSM, iar altele pot utiliza Shamir.

Acest comportament este proiectat. Un cluster Shamir din aval prezintă un potențial vector de atac în grupul de replicare, deoarece un prag de deținători de chei ar putearecrea cheia principală; prin urmare, ocolind protecția cheilor HSM din amonte.

„Deployment System Requirements

Următorul tabel oferă orientări pentru dimensionarea serverului. De reținut în mod special esterecomandarea puternică de a evita procesoarele cu performanță nefixă, sau BurstableCPU în termeni AWS, cum ar fi instanțele din seria T.

„Sizing for Vault Servers

.

„Sizing for Consul Servers

„.

„Considerații hardware

Categoria de dimensiuni mici ar fi potrivită pentru majoritatea implementărilor inițiale de producție sau pentru mediile de dezvoltare/testare.

Categoria de dimensiuni mari este destinată mediilor de producție în care există o sarcină de lucru mare și constantă. Aceasta ar putea fi un număr mare de tranzacții, un număr mare de secrete sau o combinație a celor două.

În general, cerințele de procesare vor fi dependente de volumul de lucru de criptare și de volumul de lucru de mesagerie (operațiuni pe secundă și tipuri de operațiuni). Cerințele de memorie vor depinde de dimensiunea totală a secretelor/cheilor stocate în memorie și ar trebui să fie dimensionate în funcție de aceste date (la fel ca și stocarea pe hard disk). Vault în sine are cerințe minime de stocare, dar backend-ul de stocare subiacent ar trebui să aibă un subsistem de hard disk relativ performant.Dacă multe secrete sunt generate/întoarse frecvent, aceste informații vor trebui să fie descărcate des pe disc și pot avea un impact asupra performanței dacă sunt utilizate hard disk-uri mai lente.

Funcția serverelor Consul în această implementare este de a servi ca backend de stocare pentru Vault. Acest lucru înseamnă că tot conținutul stocat pentru persistență în Vault estecriptat de Vault și scris pe backend-ul de stocare în repaus. Aceste date sunt scrise în secțiunea „key-value store” a Catalogului de servicii Consul, care trebuie să fie stocată integral în memorie pe fiecare server Consul. Acest lucru înseamnă că memoria poate fi o constrângere în scalare pe măsură ce mai mulți clienți se autentifică la Vault, mai multe secrete sunt stocate în mod persistent în Vault și mai multe secrete temporare sunt închiriate de la Vault. Acest lucru are, de asemenea, efectul de a necesita o scalare verticală a memoriei serveruluiConsul în cazul în care este nevoie de spațiu suplimentar, deoarece întregul ServiceCatalog este stocat în memorie pe fiecare server Consul.

În plus, debitul rețelei este un considerent comun pentru Vault și Consulservers. Deoarece ambele sisteme sunt conduse de HTTPS API, toate solicitările primite,comunicațiile dintre Vault și Consul, comunicațiile subiacente de bârfă între membrii clusterului Consulul, comunicațiile cu sistemele externe (conform configurației auth sau secretengine și unele configurații de logare a auditului) și răspunsurilorconsumă lățime de bandă de rețea.

Datorită considerațiilor privind performanța rețelei în operațiunile clusterului Consul, replicarea seturilor de date Vault peste granițele rețelei ar trebui realizată prin Performance sau DR Replication, mai degrabă decât prin răspândirea clusterului Consul peste granițele de rețea și fizice. Dacă un singur cluster Consul este răspândit între segmente de rețea care sunt îndepărtate sau interregionale, acest lucru poate cauza probleme de sincronizare în cadrul clusterului sau costuri suplimentare de transfer de date la unii furnizori de cloud.

„Other Considerations

Vault Production Hardening Recommendationsprovides guidance on best practices for a production hardened deployment ofVault.

„Echilibrarea încărcăturii

„Echilibrarea încărcăturii utilizând interfața Consul

Consul poate oferi capacități de echilibrare a încărcăturii prin descoperirea serviciilor, dar este necesar ca orice client Vault să fie conștient de Consul. Acest lucru înseamnă că un client caneither utilizează interfețele Consul DNS sau API pentru a rezolva nodul Vault activ. Un client ar putea accesa Vault prin intermediul unei adrese URL precum următoarea:http://active.vault.service.consul:8200

Aceasta se bazează pe sistemul de rezolvare DNS al sistemului de operare, iar cererea ar putea fi redirecționată către Consul pentru a primi răspunsul la adresa IP reală. Operațiunea poate fi complet transparentă pentru aplicațiile tradiționale și ar funcționa la fel ca o operațiune atipică de rezoluție DNS. Pentru mai multe informații, consultați Consul DNSforwarding

„Load Balancing Using External Load Balancer

Balansatoarele de sarcină externe sunt acceptate ca punct de intrare la un cluster Vault. Echilibratorul de sarcină extern ar trebui să sondeze endpoint-ul thesys/health pentru a detecta nodul activ și a direcționa traficul în consecință. Echilibratorul de sarcină ar trebui să fie configurat pentru a face o cerere HTTP pentru următorul URL către fiecare nod din cluster pentru: http://<Vault Node URL>:8200/v1/sys/health

Nodul activ Vault va răspunde cu un 200, în timp ce nodurile de rezervă vor returna un răspuns 4xx.

Cel de mai jos este un exemplu de bloc de configurare din HAProxy pentru a ilustra:

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

Rețineți că blocul de mai sus ar putea fi generat de Consul (cu consul-template)atunci când se utilizează un load balancer software. Acesta ar putea fi cazul când loadbalancerul este un software precum Nginx, HAProxy sau Apache.

Exemplu de șablon Consul pentru blocul HAProxy de mai sus:

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

„Gestionarea adreselor IP ale clienților

Există două metode acceptate pentru gestionarea adreselor IP ale clienților în spatele unui proxy sau al unui load balancer; X-Forwarded-ForHeadersși PROXYv1.Ambele necesită un load balancer de încredere și o adresă IP care să fie listate ca adrese permise pentru a adera la cele mai bune practici de securitate.

„Referințe suplimentare

• Documentația privind arhitectura Vault explicăfiecare componentă Vault
• Pentru a integra Vault cu un server LDAP existent, consultați documentațiaLDAP Auth Method
• Referiți-vă la tutorialul AppRole PullAuthentication pentru a genera în mod programatic un token pentru o mașină sau o aplicație
• Consul este o parte integrantă a funcționării unui cluster Vault rezistent, indiferent de locație. Consultați documentația online Consuldocumentation pentru a afla mai multe.

„Pași următori

• Citiți Production Hardening pentru a învăța cele mai bune practici pentru o desfășurare de hardening de producție a Vault.
• Citiți Deployment Guide pentru a afla pașii necesari pentru a instala și configura un singur cluster HashiCorp Vault.

.