Free Press

A dokumentum célja a HashiCorp Vault telepítési gyakorlatainak ajánlása. Ez a referenciaarchitektúra egy általános architektúrát közvetít, amelyet az egyes megvalósítások sajátos igényeihez kell igazítani.

Ez az útmutató a következő témákkal foglalkozik:

• Tervezési összefoglaló
  • Hálózati kapcsolódás
  • Hibatűrés
• Ajánlott architektúra
  • Egyetlen régió telepítése (Enterprise)
  • Több régió telepítése. Telepítés (Enterprise)
• Best Case Architecture
  • Deployment of Vault in one Availability Zone (all)
  • Deployment of Vault in two Availability Zones (OSS)
  • Deployment of Vault in két rendelkezésre állási zónában (Enterprise)
  • A Vault telepítése három rendelkezésre állási zónában (OSS)
• Vault replikáció (csak Enterprise)
• Telepítés rendszerkövetelmények
  • Hardware Megfontolások
• Load Balancing
• Kiegészítő hivatkozások

“Glossary

“Vault Cluster

A Vault fürt olyan Vault folyamatok összessége, amelyek együttesen egy Vault szolgáltatást futtatnak.Ezek a Vault-folyamatok futhatnak fizikai vagy virtuális kiszolgálókon, illetve konténerekben.

“Consul storage backend fürt

A HashiCorp ajánlja és támogatja a Consul használatát a Vault tárolási háttértáraként. A Consul fürt olyan Consul kiszolgálófolyamatok összessége, amelyek együttesen futtatják aConsul szolgáltatást. Ezek a Consul-folyamatok futhatnak fizikai vagy virtuáliskiszolgálókon, illetve konténerekben.

“Availability Zone

Egyetlen, helyszintű meghibásodási tartomány, amely aVault fürt egy részét vagy egészét befogadja. A rendelkezésre állási zónák közötti késleltetésnek < 8ms-nak kell lennie az utazás körül. Egyetlen Vault fürt több rendelkezésre állási zónára is szétterülhet.

Egy rendelkezésre állási zóna példái ebben a kontextusban a következők:

• Egy elszigetelt adatközpont
• Egy elszigetelt ketrec egy adatközpontban, ha az minden egyéb eszközzel (áram, hálózat stb.) el van szigetelve a többi ketrectől
• Egy rendelkezésre állási zóna az AWS-ben, Azure-ban vagy GCP-ben

“Régió

Egy vagy több rendelkezésre állási zóna földrajzilag elkülönített gyűjteménye. Egy régió egy vagy több Vault fürtnek ad otthont. A Vault architektúrában nincs meghatározott maximális késleltetési követelmény a régiók között. Egyetlen Vault fürt nem oszlik meg több régióban.

“Tervezési összefoglaló

Ez a tervezet a termelési környezetek számára ajánlott architektúra, mivel rugalmasságot és rugalmasságot biztosít.

Főbb architektúraajánlás, hogy a Consul kiszolgálók elkülönüljenek a Vault kiszolgálóktól, és hogy a Consul fürtöt csak a Vault tárolására használják, és ne más Consul-fókuszú funkciókhoz (pl. szolgáltatásegmentáció és szolgáltatásfelfedezés), amelyek kiszámíthatatlan erőforrás-kihasználást eredményezhetnek. A Vault és a Consul szétválasztása lehetővé teszi, hogy mindkét rendszer megfelelő méretű legyen a CPU, a memória és a lemez tekintetében. A Consul memóriaigényes alkalmazás, ezért a saját erőforrások elkülönítése előnyös az erőforrásokkal való versengés vagy éhezés elkerülése érdekében. A Consul fürtnek a Vault tárolási háttértárként való dedikálása szintén előnyös, mivel ez lehetővé teszi, hogy a Consul fürtöt csak akkor frissítsék, ha a Vault tárolási háttértár funkcionalitásának javításához szükséges.Ez valószínűleg sokkal ritkábban fordul elő, mint egy olyan Consul fürt esetében, amelyet szolgáltatásfelfedezésre és szolgáltatásszegmentálásra is használnak.

A Vault és a Consul háttértár közötti kapcsolat HTTP-n keresztül történik, és TLS-sel, valamint Consul tokennel kell biztosítani a teljes forgalom titkosítását. További információkért lásd a VaultDeployment Guide (Vault telepítési útmutató) című dokumentumot. Mivel a Consul fürt a Vault tárolására a szolgáltatás felderítésére szolgáló Consul fürt mellett és attól elkülönítve is használható, ajánlott, hogy a tárolási Consul folyamatot nem alapértelmezett portokon futtassák, hogy ne ütközzön más Consul funkciókkal. Ha a Consul tárolási fürtöt úgy állítja be, hogy 7xxxporton fusson, és ezt használja tárolási portként a Vault konfigurációban, akkor ezt eléri. A Consul futtatása TLS használatával is ajánlott.

“A hálózati kapcsolat részletei

A következő táblázat a Vault klasztercsomópontok hálózati forgalmi követelményeit ismerteti.

.

“Alternatív hálózati konfigurációk

AVault többféleképpen is konfigurálható aVault és a Consul klaszterek közötti kommunikációhoz:

• A szabványos névalrendszerrel feloldható állomás IP-címek vagy állomásnevek használata
• A szabványos névalrendszerrel feloldható terheléselosztó IP-címek vagy állomásnevek használata
• A csatlakoztatott Consul fürt használata. DNS mint szolgáltatásfelfedezés a Vault végpontok feloldásához
• Egy külön Consul szolgáltatásfelfedező fürt használata DNS mint szolgáltatásfelfedezés a Vault végpontok feloldásához

Az említett lehetőségek mindegyikét a Vault telepítési útmutatója ismerteti részletesebben.

“Hibatűrés

A Vault-ot úgy tervezték, hogy különböző valószínűségű hibaforgatókönyveket kezeljen. A Vault fürt telepítésekor figyelembe kell venni és meg kell tervezni a szükséges hibatűrést. Az OSS Vaultban az ajánlott példányok száma 3 egy fürtben, mivel ennél több csak korlátozott értékkel bírna. A Vault Enterprise-ban az ajánlott példányszám szintén 3 egy fürtben, de több is használható, ha azok csak olvasásra korlátozódó munkaterhelést segítő teljesítménytesztek. A Consul fürt egytől hét példányig terjedhet.Ennek páratlan számnak kell lennie, hogy a vezetői választások mindig megoldódhassanak. Ajánlott, hogy a Consul fürt legalább öt példány legyen, amelyek kizárólag a Vault fürt háttértárolási funkcióinak ellátására szolgálnak.

“Node

A Vault és a Consul fürt szoftver a fürtön belüli replikációval lehetővé teszi a hibatartományt a csomóponti szinten. Egyetlen HA Vault fürtben minden csomópont ugyanazt a mögöttes tárolási háttértárolót és így az adatokat is megosztja. A Vaulta ezt úgy éri el, hogy az egyik Vault-kiszolgáló zárolást kap az adattárolón belül, hogy az aktív Vault-csomópont legyen, és ez írási hozzáféréssel rendelkezik. Ha a vezér bármikor kiesik, akkor egy másik Vault-csomópont zökkenőmentesen átveszi a helyét. Az n-2 redundancia eléréséhez (ahol 2 objektum elvesztése a hibatartományon belül tolerálható) a Vault fürt ideális mérete 3 lenne.A Consul a replikációt és a vezetést a konszenzus és agossip protokollok használatával éri el. Ezekben a protokollokban a vezetőt konszenzussal választják meg, és így az aktív szerverekből mindig kell aquorumnak léteznie. Az n-2 redundancia eléréséhez a Consul fürt ideális mérete 5. További részletekért lásd ConsulInternals.

“Availability Zone

A felhőkörnyezetben a tipikus elosztás a Consul/Vault csomópontok különálló Availability Zone-okba (AZ) való elosztása egy nagy sávszélességű, alacsony késleltetésű hálózaton belül, mint például egy AWS régió, azonban ez nem biztos, hogy lehetséges egy adatközpont-telepítésben, ahol csak egy DC van a szükséges késleltetési szinten belül.

Fontos megérteni a követelményben vagy a legjobb gyakorlatban bekövetkezett változást, amely a nagymértékben elosztott rendszerek, például a Consul nagyobb mértékű kihasználása felé való elmozdulás eredményeként következett be. Amikor elosztott rendszerekből álló környezeteket üzemeltetnek, váltásra van szükség a mögöttes komponensek redundancia-koefficiensében. A Consul az információk szervezésében és sokszorosításában a konszenzusos tárgyalásra támaszkodik, ezért a környezetnek 3 egyedi rugalmassági útvonalat kell biztosítania az értelmes megbízhatóság érdekében. Lényegében a konszenzusos rendszer megköveteli, hogy a csomópontok egyszerű többsége bármikor rendelkezésre álljon. A 3 csomópontos példában 2 csomópontnak elérhetőnek kell lennie. Ha ez a 3 csomópont két meghibásodási tartományban van elhelyezve, akkor 50% az esélye annak, hogy egyetlen meghibásodási tartomány elvesztése teljes kiesést eredményez.

“Régió

A régiószintű meghibásodás elleni védelem, valamint további földrajzi skálázási lehetőségek biztosítása érdekében a Vault Enterprise a következőket kínálja:

• Katasztrófa utáni helyreállítási replikáció
• Teljesítményreprodukció

A lehetőségek teljes leírását lásd a Vault replikáció ajánlott mintáiban.

A fent felsorolt korlátozások miatt az ajánlott architektúra aVault és a Consul Enterprise három rendelkezésre állási zónára elosztva egy klaszteren belül, valamint a klaszterek régiók közötti replikációja a DR és aPerformance replikáció segítségével. Számos “Best Case” architektúramegoldás létezik egy és két rendelkezésre állási zónára, valamint a Consul OSS-re is. Ezek nem az ajánlott architektúrák, de a legjobb megoldások, ha a telepítést a Consul verzió vagy a rendelkezésre állási zónák száma korlátozza.

“Ajánlott architektúra

Az alábbi architektúra a Vault telepítésének ajánlott legjobb megközelítése, és minden telepítés célarchitektúrájának kell lennie. Ez két részre oszlik:

• Vault fürt – Ez az ajánlott architektúra a vault fürthöz mint egyetlen egységhez, de a második ábra szerinti replikációt is használnia kell
• Vault replikáció – Ez az ajánlott architektúra több vault fürthöz a regionális, teljesítmény és katasztrófa utáni helyreállítás lehetővé tétele érdekében.

“Egyetlen régió telepítése (Enterprise)

Ebben a forgatókönyvben a Vault csomópontok és a hozzájuk tartozó Consul fürt három rendelkezésre állási zóna között vannak elhelyezve. Ez a megoldás a Vault esetében n-2 csomóponti szinten, a Consul esetében pedig n-3 csomóponti szinten rendelkezik. A rendelkezésre állási zóna szintjén a Vault az n-2, a Consul pedig az n-1 szinten van. Ez abban különbözik az OSS tervezéstől, hogy a Consul fürt hat csomóponttal rendelkezik, amelyek közül három nem szavazó tag. AConsul fürtöt a RedundancyZones használatával úgy állították be, hogy ha bármelyik csomópont meghibásodna, az Autopilot egy nem szavazó tagot teljes jogú taggá léptetne elő, és így fenntartaná a határozatképességet.

“Több régió telepítése (Enterprise)

“Referenciadiagram Rugalmasság a régió meghibásodása ellen

Ebben a forgatókönyvben a fürtök replikálva vannak a teljes régió meghibásodása ellen. Három Performance Replica Vault klaszter van (A, B, C klaszterek)egyenként saját DR klaszterrel (D, E, F klaszterek) egy másik régióban. Mindegyik klaszterhez tartozik egy saját Consul klaszter a tárolási háttértárhoz.

Ez az architektúra lehetővé teszi az n-2-t a régió szintjén, feltéve, hogy minden titok és titokmotor replikálva van az összes klaszterben. A teljes Region1 meghibásodása esetén a DR F fürtöt kellene előléptetni. Amint ez megtörtént, a Vaultsolution teljes mértékben működőképes lenne, némi redundanciaveszteséggel, amíg a Region1 helyre nem áll. Az alkalmazásoknak nem kellene újra hitelesíteniük magukat, mivel az egyes meghibásodott fürtök DR-klaszterei tartalmaznák az összes bérleti szerződést és tokent.

“Referenciadiagram Rugalmasság a fürtök meghibásodása ellen

Ez a megoldás teljes rugalmassággal rendelkezik fürt szinten, de nem véd a régió meghibásodása ellen, mivel a teljesítmény replikák DR-klaszterei ugyanabban a régióban vannak. Vannak olyan felhasználási esetek, amikor ez az előnyben részesített módszer, amikor az adatok nem replikálhatók más régiókba olyan irányítási korlátozások miatt, mint például a GDPR. Egyes infrastrukturális keretrendszerek nem képesek az alkalmazások forgalmát különböző régiókba irányítani.

“Best Case Architecture

Egyes telepítésekben olyan leküzdhetetlen korlátozások lehetnek, amelyek miatt a javasolt architektúra nem lehetséges. Ennek oka lehet a rendelkezésre álló zónák hiánya vagy a Vault OSS használata. Ezekben az esetekben az alábbi architektúrák a rendelkezésre álló legjobb lehetőségeket mutatják be.

Megjegyezzük, hogy ezekben az alábbi architektúrákban a Consul vezetője lehet az öt Consul kiszolgáló csomópont bármelyike, és a Vault aktív csomópontja lehet a három Vault csomópont bármelyike

“A Vault telepítése egy rendelkezésre állási zónában (minden)

Ebben a forgatókönyvben az összes Vault csomópont és a hozzá tartozó Consul fürt egy rendelkezésre állási zónában van elhelyezve. Ebben a megoldásban egyetlen hibapont van a rendelkezésre állási zóna szintjén, de n-2 a csomópontok szintjén mind a Consul, mind aVault esetében. Ez nem a Hashicorp által ajánlott architektúra a termelési rendszerekhez, mivel nincs redundancia a rendelkezésre állási zóna szintjén. Szintén nincs DR-kapacitás, ezért legalább egy DR-replikának külön régióban kell lennie.

“A Vault telepítése két rendelkezésre állási zónában (OSS)

Ebben a forgatókönyvben a Vault csomópontok és a hozzájuk tartozó Consul fürt két rendelkezésre állási zóna között vannak elhelyezve. Ez a megoldás n-2 a Vault és a Consul csomóponti szintjén és n-1 a Vault esetében a rendelkezésre állási zóna szintjén, dea rendelkezésre állási zóna hozzáadása nem növeli jelentősen a Consul fürt rendelkezésre állását. Ennek az az oka, hogy a Raft protokoll (n/2)+1-es aquorumot igényel, és ha a fenti ábrán a B zóna meghibásodna, akkor a fürt nem lenne határozatképes, és így szintén meghibásodna. Ez nem a Hashicorprecommended architecture for production systems as there is only partialredundancy at the Availability Zone level and an Availability Zone failure may not result an outage.

“Deployment of Vault in two Availability Zones (Enterprise)

Due to the need to maintain quorum in the Consul cluster, having only 2Availability Zones is not ideal. Nincs mód arra, hogy egy Consul fürtöt két AZ-ra terjesszen szét úgy, hogy garantált legyen a hozzáadott rugalmasság. A Vault Enterprise-ban a legjobb megoldás az, ha a két AZ-t régióként kezeli, és mindegyikben külön Vaultclustert hoz létre.

A másodlagos Vault fürt lehet egy Performance Replica vagy egy DR Replica, mindegyiknek megvannak a maga előnyei:

• PR másodlagos: Ha a Vault címet a Consul vagy egy terheléselosztó kezeli, akkor bármelyik fürt meghibásodása azt eredményezi, hogy a forgalmat a másik fürtre irányítják, kiesés nélkül, feltéve, hogy van logika az alkalmazásban vagy a Vault ügynökben a tokenek újrakérésének kezelésére, amelyek nem replikálódnak a fürtök között.
• DR másodlagos: Ebben az esetben az elsődleges fürt meghibásodása azt eredményezi, hogy az üzemeltetőnek be kell avatkoznia a DR-t az elsődlegesbe, de mivel minden bérlet és token replikálva van, nincs szükség további logikára az alkalmazásban ennek kezeléséhez.

“A Vault telepítése három rendelkezésre állási zónában (OSS)

Ebben a forgatókönyvben a Vault csomópontjai és a kapcsolódó Consul fürt három rendelkezésre állási zóna között vannak elhelyezve. Ez a megoldás a Vault és a Consul esetében n-2 a csomópontok szintjén, a Vault esetében pedig n-2 a rendelkezésre állási zónák szintjén.Ez a megoldás a Consul esetében is n-1 a rendelkezésre állási zónák szintjén, és mint ilyen, az összes architektúra közül az egyetlen Vault fürt és a Consul tárolási háttértároló OSS termék esetében a legellenállóbbnak tekinthető.

“Vault Replication (Enterprise Only)

Ezekben az architektúrákban a Vault fürt egyetlen egységként van ábrázolva, és a rendelkezésre állási zónák száma alapján a fent részletezett egyetlen fürtök egyike lenne. Több Vault fürt egyetlen Vaultsolutionként való működése és a közöttük történő replikáció csak az Enterprise Vaultban érhető el. Az OSSVault több fürtben is beállítható, de ezek mindegyike egyedi Vault-megoldás lenne, és nem támogatná a fürtök közötti replikációt.

A Vaultdokumentáció részletesebb információt nyújt a VaultEnterprise replikációs lehetőségeiről.

“Teljesítményreplikáció

A Vault teljesítményreplikációja lehetővé teszi a titkok kezelését több helyszínen.A statikus titkokat, hitelesítési módszereket és engedélyezési házirendeket úgy replikálják, hogy azok több helyen is aktívak és elérhetőek legyenek, a leasingokenseket és a dinamikus titkokat azonban nem.

“Katasztrófa utáni helyreállítási replikáció

A Vault katasztrófa utáni helyreállítási replikáció biztosítja, hogy a készenléti Vault fürt kepszinkronizálva legyen az aktív Vault fürttel. Ez a replikációs mód magában foglaljaaz olyan adatokat, mint az efemer hitelesítési tokenek, az időalapú tokeninformációk, valamint a tokenhasználati adatok. Ez biztosítja az agresszív helyreállítási pont célkitűzését olyan környezetekben, ahol az efemer működési adatok elvesztésének megakadályozása a legfontosabb szempont. Minden vállalati megoldásban a katasztrófa-visszaállítási replikák nélkülözhetetlenek.

“Korrupció vagy szabotázs katasztrófa utáni helyreállítás

Egy másik gyakori forgatókönyv, amely ellen védekezni kell, és amely a felhőkörnyezetekben, amelyek nagyon magas szintű belső rugalmasságot biztosítanak, gyakrabban fordul elő, lehet az adatok és a konfiguráció szándékos vagy véletlen sérülése és/vagy a felhőszámla-ellenőrzés elvesztése. A Vault DR replikációját úgy tervezték, hogy élő adatokat replikáljon, amelyek szándékos vagy véletlen adatsérülést vagy törlést terjesztenének. Ezen lehetőségek ellen védekezve a Vault tároló háttértárolójáról biztonsági mentést kell készítenie.Ezt a ConsulSnapshot funkció támogatja, amely automatizálható a rendszeres archiválási biztonsági mentésekhez. Egy hideg telephelyet vagy új infrastruktúrát egy Consul pillanatképből újra lehet hidratálni.

“Replikációs megjegyzések

A replikációs készleten belüli fürtök számának nincs meghatározott korlátja. A legnagyobb telepítések ma a 30+ fürtös tartományban vannak. Egy Performance Replica fürthöz tartozhat egy Disaster Recovery fürt, és több Disaster Recovery fürtbe is replikálhat.

Míg egy Vault fürt rendelkezhet replikációs szereppel (vagy szerepekkel), az infrastruktúra szempontjából nincs szükség különleges megfontolásokra, és a fürtök átvehetnek (vagy előléptethetők vagy visszaminősíthetők) más szerepet. A csatlakoztatási szűrőkkel és a hardveres biztonsági modul (HSM) használatával kapcsolatos különleges körülmények korlátozhatják a szerepek átcserélését, de ezek a konkrét szervezeti konfigurációkon alapulnak.

“A HSM integrációval kapcsolatos megfontolások

A hardveres biztonsági modullal (HSM) vagy felhő automatikus feloldási eszközökkel integrált Vault fürtökkel történő replikáció használata az automatikus feloldási műveletekhez tartalmaz néhány olyan részletet, amelyet a tervezési fázisban meg kell érteni.

• Ha egy elsődleges teljesítményű fürt HSM-et használ, akkor a replikációs készleten belüli összes többi fürtnek is HSM-et kell használnia.
• Ha egy elsődleges teljesítményű fürt NEM használ HSM-et (Shamir titokmegosztási módszert használ), az adott replikációs készleten belüli fürtök vegyesen is lehetnek, így egyesek használhatnak HSM-et, mások pedig Shamirt.

Ez a viselkedés a terv szerint történik. Egy downstream Shamir fürt potenciális támadási vektort jelent a replikációs csoportban, mivel a kulcstulajdonosok küszöbértéke létrehozhatja a mesterkulcsot; így megkerülve az upstream HSM kulcsvédelmet.

“Telepítési rendszerkövetelmények

A következő táblázat a kiszolgáló méretezésére vonatkozó iránymutatásokat tartalmazza. Külön kiemelendő a nem fix teljesítményű CPU-k, vagy AWS-kifejezéssel BurstableCPU-k, például a T-sorozatú példányok elkerülésének határozott ajánlása.

“Vault szerverek méretezése

.

“Méretezés a Consul szerverekhez

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

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