Free Press

Tämän asiakirjan tavoitteena on suositella HashiCorp Vaultin käyttöönottokäytäntöjä. Tämä viitearkkitehtuuri välittää yleisen arkkitehtuurin, jota on mukautettava kunkin toteutuksen erityistarpeiden mukaan.

Tässä oppaassa käsitellään seuraavia aiheita:

• Suunnittelun yhteenveto
  • Verkkoyhteydet
  • Viansietokyky
• Suositeltu arkkitehtuuri
  • Yksittäisen alueen käyttöönotto (yritys)
  • Moninkertaisen alueen käyttöönotto. Deployment (Enterprise)
• Best Case Architecture
  • Deployment of Vault in one Availability Zone (all)
  • Deployment of Vault in two Availability Zones (OSS)
  • Deployment of Vault in kahdessa saatavuusvyöhykkeessä (Enterprise)
  • Vaultin käyttöönotto kolmessa saatavuusvyöhykkeessä (OSS)
• Vaultin replikointi (vain Enterprise)
• Käyttöönotto Järjestelmävaatimukset
  • Hardware Considerations
• Load Balancing
• Lisäviitteet

”Glossary

”Vault Cluster

Vault-klusteri on joukko Vault-prosesseja, jotka yhdessä ajavat Vault-palvelua.Nämä Vault-prosessit voivat olla käynnissä fyysisillä tai virtuaalisilla palvelimilla tai säiliöissä.

”Consul-tallennuksen backend-klusteri

HashiCorp suosittelee ja tukee Consulin käyttöä Vaultin tallennuksen backendinä. Consul-klusteri on joukko Consul-palvelinprosesseja, jotka yhdessä ajavatConsul-palvelua. Nämä Consul-prosessit voivat olla käynnissä fyysisillä tai virtuaalisilla palvelimilla tai säiliöissä.

”Saatavuusvyöhyke

Yksittäinen sijaintitason vikatoimialue, joka isännöi osaa tai kokoVault-klusterista. Käytettävyysvyöhykkeiden välisen viiveen tulisi olla < 8ms noin matkan ajan. Yksittäinen Vault-klusteri voi olla hajautettu useammalle saatavuusvyöhykkeelle.

Esimerkkejä saatavuusvyöhykkeistä tässä yhteydessä ovat:

• eristetty datakeskus
• eristetty häkki datakeskuksessa, jos se on eristetty muista häkkeistä kaikin muin keinoin (virta, verkko jne.)
• saatavuusvyöhyke AWS:ssä, Azuressa tai GCP:ssä

”Alue

Yhdestä tai useammasta saatavuusvyöhykkeestä koostuva maantieteellisesti erillinen kokoelma. Alue isännöi yhtä tai useampaa Vault-klusteria. Vault-arkkitehtuurissa ei ole määritelty alueiden välistä enimmäisviiveaikavaatimusta. Yhtä Vault-klusteria ei levitettäisi useille alueille.

”Suunnittelun yhteenveto

Tämä rakenne on suositeltu arkkitehtuuri tuotantoympäristöihin, koska se tarjoaa joustavuutta ja häiriönsietokykyä.

Se on tärkeä arkkitehtuurisuositus, että Consul-palvelimet ovat erillään Vault-palvelimista ja että Consul-klusteria käytetään vain Vaultin varastointipäätepisteenä eikä muihin Consuliin keskittyviin toimintoihin (esim. palveluiden eriyttämiseen ja palveluiden löytämiseen), jotka voivat aiheuttaa resurssien ennakoimatonta käyttöä. Vaultin ja Consulin erottaminen toisistaan mahdollistaa sen, että kummallakin on järjestelmä, joka voidaan mitoittaa tarkoituksenmukaisesti suorittimen, muistin ja levyn osalta. Consul on muistipainotteinen sovellus, joten sen erottaminen omiin resursseihinsa on eduksi resurssien riitelyn tai nälänhädän välttämiseksi. Consul-klusterin omistaminen Vault-tallennuksen taustaympäristöksi on myös edullista, koska näin Consul-klusteria voidaan päivittää vain tarpeen mukaan Vault-tallennuksen taustaympäristön toiminnallisuuden parantamiseksi.Tämä tapahtuu todennäköisesti paljon harvemmin kuin Consul-klusterissa, joka on tarkoitettu myös palveluiden löytämiseen ja segmentointiin.

Vaultin ja Consul-taustaympäristön välinen yhteys tapahtuu HTTP:n välityksellä, ja se on suojattava TLS:llä sekä Consul-merkkivalinnalla, joka takaa kaiken liikenteen salauksen. Katso lisätietoja VaultDeployment Guide -oppaasta. Koska Vault-tallennuksen Consul-klusteria voidaan käyttää palveluhakuun tarkoitetun Consul-klusterin lisäksi ja erillään siitä, on suositeltavaa, että tallennuksen Consul-prosessia ajetaan muissa kuin oletusporteissa, jotta se ei ole ristiriidassa muiden Consul-toimintojen kanssa. Tämä saavutetaan asettamalla Consul-tallennusklusteri ajettavaksi 7xxxportilla ja käyttämällä tätä varastointiporttina Vault-konfiguraatiossa. On myös suositeltavaa, että Consulia ajetaan TLS:ää käyttäen.

”Verkkoyhteyksien yksityiskohdat

Seuraavassa taulukossa esitetään Vault-klusterin solmujen verkkoliikennevaatimukset.

”Vaihtoehtoiset verkkokonfiguraatiot

Vault voidaan konfiguroida useilla eri tavoillaVault- ja Consul-klustereiden välistä viestintää varten:

• Käyttämällä isännän IP-osoitteita tai isäntänimiä, jotka ovat ratkaistavissa vakiomuotoisen nimialajärjestelmän
• Käyttämällä kuorman tasaajan IP-osoitteita tai isäntänimiä, jotka ovat ratkaistavissa vakiomuotoisen nimialajärjestelmän
• Käyttämällä liitettyä Consul-klusteria. DNS as service discovery to resolve Vaultendpoints
• Erillisen Consul-palvelunhakuklusterin käyttäminen DNS as service discovery toresolve Vault endpoints

Kaikkea näitä vaihtoehtoja tarkastellaan tarkemmin Vaultin käyttöönotto-oppaassa.

”Vikasietoisuus

Vault on suunniteltu käsittelemään erilaisia vikaantumisskenaarioita, joilla on erilaiset todennäköisyydet. Vault-klusteria käyttöönotettaessa on otettava huomioon ja suunniteltava tarvittava vikasietoisuus. OSS Vaultissa suositellaan, että klusterissa on 3 instanssia, koska useammalla on vain rajallinen arvo. Vault Enterprisessa klusterissa suositellaan myös kolmea instanssia, mutta niitä voidaan käyttää enemmänkin, jos ne ovat suorituskykyisiä ja auttavat pelkän lukutyömäärän kanssa. Consul-klusteri on yhdestä seitsemään instanssia.Tämän pitäisi olla pariton määrä, jotta johtajavalinnat voidaan aina ratkaista. On suositeltavaa, että Consul-klusterissa on vähintään viisi instanssia, jotka on omistettu suorittamaan vain Vault-klusterin backend-tallennustoimintoja.

”Node

Vault- ja Consul-klusteriohjelmisto mahdollistaa vikatoimialueen solmutasolla replikoinnilla klusterin sisällä. Yksittäisessä HA Vault -klusterissa kaikki solmut jakavat saman taustalla olevan tallennustietopohjan ja siten myös tiedot. Vaulta ratkaisee tämän siten, että yksi Vault-palvelimista saa lukituksen tietovarastossa, jolloin siitä tulee aktiivinen Vault-solmu, jolla on kirjoitusoikeus. Jos johtava solmu menetetään, toinen Holvin solmu ottaa saumattomasti sen paikan johtavana solmuna. Jotta saavutettaisiin n-2 redundanssi (jolloin kahden objektin menetys vika-alueella voidaan sietää), ihanteellinen koko Vault-klusterille olisi 3.Consul saavuttaa replikoinnin ja johtajuuden käyttämällä konsensusprotokollaa ja gossip-protokollaa. Näissä protokollissa johtaja valitaan konsensuksella, joten aktiivisista palvelimista on aina oltava akvorum. Jotta saavutetaan n-2 redundanssi, Consul-klusterin ihanteellinen koko on 5. Katso lisätietoja kohdasta ConsulInternals.

”Saatavuusvyöhyke

Tyypillinen jakelu pilviympäristössä on Consul/Vault-solmujen hajauttaminen erillisiin saatavuusvyöhykkeisiin (AZ) suuren kaistanleveyden ja alhaisen viiveen verkon, kuten AWS:n alueen, sisälle, mutta tämä ei kuitenkaan välttämättä ole mahdollista datakeskustietokoneiden asentamisessa, jossa on vain yksi DC vaadittavan viiveen sisällä.

On tärkeää ymmärtää muutos vaatimuksissa tai parhaissa käytännöissä, jotka ovat tulleet sen seurauksena, että on siirrytty vahvasti hajautettujen järjestelmien, kuten Consulin, laajempaan hyödyntämiseen. Kun käytetään ympäristöjä, jotka koostuvat hajautetuista järjestelmistä, tarvitaan muutosta taustalla olevien komponenttien redundanssikertoimessa. Consul perustuu konsensusneuvotteluihin tiedon organisoimiseksi ja monistamiseksi, joten ympäristön on tarjottava kolme ainutlaatuista resilienttipolkua mielekkään luotettavuuden takaamiseksi. Pohjimmiltaan konsensusjärjestelmä edellyttää, että yksinkertainen enemmistö solmuista on aina käytettävissä. Esimerkissä, jossa on 3 solmua, 2 solmua on oltava käytettävissä. Jos nämä kolme solmua on sijoitettu kahteen vika-alueeseen, on 50 prosentin todennäköisyys, että yhden vika-alueen menettäminen johtaa täydelliseen katkokseen.

”Alue

Suojautuakseen vikaantumiselta aluetasolla sekä tarjotakseen lisää maantieteellisiä skaalautumisominaisuuksia, Vault Enterprise tarjoaa:

• Katastrofista palautumisen replikointi
• suorituskykyinen replikointi

Katsokaa Vaultin replikoinnin suositeltuja malleja, jos haluatte saada täydellisen selostuksen näistä vaihtoehdoista.

Yllä lueteltujen rajoitusten vuoksi suositeltu arkkitehtuuri on sellainen, jossaVault ja Consul Enterprise on hajautettu kolmelle saatavuusalueelle klusterin sisällä ja klustereita replikoidaan alueiden välillä DR- ja Performance-replikoinnin avulla. On myös useita ”Best Case” -arkkitehtuuriratkaisuja yhdelle ja kahdelle saatavuusvyöhykkeelle sekä Consul OSS:lle. Nämä eivät ole suositeltu arkkitehtuuri, mutta ne ovat parhaita ratkaisuja, jos käyttöönottoa rajoittaa Consul-versio tai saatavuusvyöhykkeiden määrä.

”Suositeltava arkkitehtuuri

Alla oleva arkkitehtuuri on suositeltu paras lähestymistapa Vaultin käyttöönottoon, ja sen tulisi olla tavoitearkkitehtuuri kaikissa asennuksissa. Tämä on jaettu kahteen osaan:

• Vault-klusteri – Tämä on suositeltu arkkitehtuuri holviklusterille yksittäisenä kokonaisuutena, mutta sen tulisi myös käyttää replikointia toisen kaavion mukaisesti
• Vault-replikointi – Tämä on suositeltu arkkitehtuuri useille holviklustereille alueellisen, suorituskykyisen ja katastrofitilanteiden jälkeisen palautuksen mahdollistamiseksi.

”Yhden alueen käyttöönotto (Enterprise)

Tässä skenaariossa Vault-solmut ja niihin liittyvä Consul-klusteri sijaitsevat kolmen saatavuusvyöhykkeen välillä. Tässä ratkaisussa Vaultin solmutasolla on n-2 ja Consulin solmutasolla n-3. AvailabilityZone-tasolla Vault on n-2:ssa ja Consul n-1:ssä. Tämä eroaa OSS-suunnittelusta siinä, että Consul-klusterissa on kuusi solmua, joista kolme on ei-äänivaltaisia jäseniä. Consul-klusteri on perustettu RedundancyZoneja käyttäen siten, että jos jokin solmu vikaantuisi, Autopilot ylentäisi ei-äänivaltaisen jäsenen täysjäseneksi ja säilyttäisi näin päätösvaltaisuuden.

”Multiple Region Deployment (Enterprise)

”Viitekaavio Resilienssi alueen vikaantumisen varalta

Tässä skenaariossa klusterit replikoidaan suojautumisessa alueen täydeltä vikaantumiselta. On kolme Performance Replica Vault -klusteria (klusterit A, B, C)joilla kullakin on oma DR-klusterinsa (klusterit D, E, F) eri alueella. Kullakin klusterilla on oma Consul-klusterinsa tallennuksen taustajärjestelmää varten.

Tämä arkkitehtuuri mahdollistaa n-2:n alueellisella tasolla edellyttäen, että kaikki salaisuudet ja salaisuusmoottorit replikoidaan kaikkiin klustereihin. Koko Region1:n vikaantuminen edellyttäisi DR-klusterin F ylentämistä. Kun tämä on tehty, Vaultsolution olisi täysin toimintakykyinen, mutta redundanssia olisi jonkin verran menetetty, kunnes Region1 olisi palautettu. Sovellusten ei tarvitsisi autentikoitua uudelleen, koska kunkin vikaantuneen klusterin DR-klusteri sisältäisi kaikki vuokrasopimukset ja tunnukset.

”Viitekaavio Kestävyys klusterin vikaantumisen varalta

Tässä ratkaisussa on täysi häiriönsietokyky klusteritasolla, mutta se ei suojaa alueen vikaantumisen varalta, koska Suorituskykykopioiden DR-klusterit ovat samassa alueessa. Tietyissä käyttötapauksissa tämä on suositeltavin menetelmä, kun tietoja ei voida replikoida muille alueille hallintorajoitusten, kuten GDPR:n, vuoksi. Joillakin infrastruktuurikehyksillä ei myöskään välttämättä ole kykyä reitittää sovellusliikennettä eri alueille.

”Paras tapausarkkitehtuuri

Joissakin käyttöönotoissa voi olla ylitsepääsemättömiä rajoituksia, jotka tarkoittavat, että suositeltu arkkitehtuuri ei ole mahdollinen. Tämä voi johtua saatavuusalueiden puutteesta tai Vault OSS:n käytöstä. Näissä tapauksissa alla olevat arkkitehtuurit ovat parhaita mahdollisia vaihtoehtoja.

Huomaa, että näissä seuraavissa arkkitehtuureissa Consulin johtaja voi olla mikä tahansa viidestä Consul-palvelinsolmusta ja Vaultin aktiivinen solmu voi olla mikä tahansa kolmestaVault-solmusta

”Vaultin käyttöönotto yhdellä saatavuusvyöhykkeellä (kaikki)

Tämässä skenaariossa kaikki Vault-solmut ja niihin liittyvä Consul-klusteri sijaitsevat yhdellä saatavuusvyöhykkeellä. Tässä ratkaisussa on yksi vikaantumispistesaatavuusvyöhyketasolla, mutta n-2 solmutasolla sekä Consulin ettäVaultin osalta. Tämä ei ole Hashicorpin suosittelema arkkitehtuuri tuotantojärjestelmille, koska saatavuusvyöhyketasolla ei ole redundanssia. Myöskään DR-kapasiteettia ei ole, joten vähintäänkin tässä pitäisi olla DR-replika erillisellä alueella.

”Vaultin käyttöönotto kahdessa saatavuusvyöhykkeessä (OSS)

Tässä skenaariossa Vaultin solmut ja siihen liittyvä Consul-klusteri sijaitsevat kahden saatavuusvyöhykkeen välillä. Tässä ratkaisussa on n-2 solmutasolla Vaultin ja Consulin osalta ja n-1 Vaultin osalta saatavuusvyöhyketasolla, mutta saatavuusvyöhykkeen lisääminen ei merkittävästi lisää Consul-klusterin käytettävyyttä. Tämä johtuu siitä, että Raft-protokolla vaatii (n/2)+1:n akvorumin, ja jos vyöhyke B pettäisi yllä olevassa kaaviossa, klusteri ei olisi päätösvaltainen, joten myös se pettäisi. Tämä ei ole Hashicorin suosittelema arkkitehtuuri tuotantojärjestelmille, koska saatavuusvyöhyketasolla on vain osittaista redundanssia ja saatavuusvyöhykkeen vikaantuminen ei välttämättä johda käyttökatkokseen.

”Vaultin käyttöönotto kahdessa saatavuusvyöhykkeessä (Enterprise)

Koska Consul-klusterissa on ylläpidettävä quorumia, vain 2 saatavuusvyöhykettä ei ole ihanteellista. Ei ole mitään tapaa hajauttaa Consul-klusteria kahteen AZ-alueeseen siten, että lisäkestävyys olisi taattu. Paras ratkaisu Vault Enterprisessa on käsitellä kahta AZ:tä alueina ja käyttää kummassakin erillisiä Vault-klustereita.

Toissijainen Vault-klusteri voi olla joko Performance Replica tai DR Replica, joilla kummallakin on omat etunsa:

• PR secondary: Jos Vault-osoitetta hallinnoidaan Consulilla tai kuormantasaajalla, jommankumman klusterin vikaantuessa liikenne ohjataan toiselle klusterille ilman katkoksia, edellyttäen, että sovelluksessasi tai Vault-agentissa on logiikka, jolla voidaan hallinnoida tokeneiden uudelleenkyselyä, joita ei ole replikoitu klustereiden välillä.
• Toissijainen DR: Tässä tapauksessa ensisijaisen klusterin vikaantuminen johtaa siihen, että operaattorin on puututtava asiaan DR:n nostamiseksi ensisijaiseksi, mutta koska kaikki vuokrasopimukset ja tokenit replikoidaan, sovelluksessa ei tarvita lisälogiikkaa tämän hoitamiseksi.

”Vaultin käyttöönotto kolmessa saatavuusvyöhykkeessä (OSS)

Tässä skenaariossa Vaultin solmut ja siihen liittyvä Consul-klusteri sijaitsevat kolmen saatavuusvyöhykkeen välillä. Tässä ratkaisussa on n-2 solmutasolla Vaultin ja Consulin osalta ja n-2 Vaultin osalta saatavuusvyöhyketasolla.Tässä ratkaisussa on myös n-1 saatavuusvyöhyketasolla Consulin osalta, ja näin ollen sitä pidetään kestävimpänä kaikista arkkitehtuureista, jotka koskevat yksittäistä Vault-klusteria, jossa on Consul-tallennustietokanta OSS-tuotetta varten.

”Vault Replication (Enterprise Only)

Näissä arkkitehtuureissa Vault-klusteri on kuvattu yksittäisenä yksikkönä, ja se olisi yksi edellä esitetyistä yksittäisistä klustereista käytettävyysvyöhykkeiden määrän perusteella. Useat Vault-klusterit, jotka toimivat yhtenä Vault-ratkaisuna ja replikoivat niitä keskenään, ovat käytettävissä vain Enterprise Vaultissa. OSSVault voidaan perustaa useisiin klustereihin, mutta ne ovat kukin yksittäisiäVault-ratkaisuja eivätkä tue klustereiden välistä replikointia.

Vaultin dokumentaatiossa on yksityiskohtaisempaa tietoa VaultEnterprisen replikointiominaisuuksista.

”Suorituskykyinen replikointi

Vaultin suorituskykyinen replikointi mahdollistaa salaisuuksien hallinnan useissa toimipisteissä.Staattiset salaisuudet, todennusmenetelmät ja valtuutuskäytännöt replikoidaan aktiivisiksi ja käytettävissä oleviksi useissa toimipisteissä, mutta leasesokenit ja dynaamiset salaisuudet eivät.

”Disaster Recovery Replication

Vaultin disaster recovery -replikointi varmistaa, että valmiustilassa oleva Vault-klusteri on kepsynkronoitu aktiivisen Vault-klusterin kanssa. Tämä replikointitapa sisältäätiedot, kuten ephemeral-todennuskoodit, aikapohjaiset kooditiedot sekä koodien käyttötiedot. Tämä mahdollistaa aggressiivisen toipumispistetavoitteen ympäristöissä, joissa lyhytaikaisten operatiivisten tietojen katoamisen estäminen on tärkeintä. Kaikissa yritysratkaisuissa Disaster Recovery Replicas ovat välttämättömiä.

”Corruption or Sabotage Disaster Recovery

Toinen yleinen skenaario, jota vastaan on suojauduttava ja joka on yleisempi pilviympäristöissä, jotka tarjoavat erittäin korkean luontaisen häiriönsietokyvyn, voi olla tietojen ja konfiguraatioiden tarkoituksellinen tai vahingossa tapahtuva korruptoituminen ja/tai pilvitilien hallinnan menetys. Vaultin DR-replikointi on suunniteltu replikoimaan reaaliaikaista dataa, joka levittäisi tahallista tai tahatonta datan korruptoitumista tai poistamista. Näiltä mahdollisuuksilta suojaudutaan varmuuskopioimalla Vaultin tallennustietokanta.Tätä tukee ConsulSnapshot-toiminto, joka voidaan automatisoida säännöllisiä arkistointitallennuksia varten. Kylmää sivustoa tai uutta infrastruktuuriavoidaan kosteuttaa uudelleen Consulin tilannekuvasta.

”Replikointia koskevia huomautuksia

Replikointisarjan sisällä olevien klustereiden lukumäärälle ei ole asetettu rajoitusta. Suurimmat käyttöönotot ovat nykyään yli 30 klusterin luokkaa. Performance Replica -klusteriin voi liittyä Disaster Recovery -klusteri, ja se voi myös replikoida useisiin Disaster Recovery -klustereihin.

Vault-klusterilla voi olla replikointirooli (tai -rooleja), mutta infrastruktuurin osalta ei tarvita erityisiä näkökohtia, ja klusterit voivat omaksua (tai ne voidaan ylentää tai alentaa) toiseen rooliin. Kiinnityssuodattimiin ja laitteiston turvamoduulin (HSM) käyttöön liittyvät erityisolosuhteet voivat rajoittaa roolien vaihtamista, mutta ne perustuvat organisaatiokohtaisiin kokoonpanoihin.

”HSM-integraatioon liittyvät näkökohdat

Replikoinnin käyttämiseen Vault-klustereiden kanssa, jotka on integroitu laitteiston turvamoduulin (HSM) tai pilvipalvelun automaattisten purkulaitteiden kanssa automatisoituja purkamisoperaatioita varten, liittyy joitain yksityiskohtia, jotka on ymmärrettävä suunnitteluvaiheen aikana.

• Jos suorituskyvyn ensisijainen klusteri käyttää HSM:ää, kaikkien muidenkin kyseiseen replikaatiosarjaan kuuluvien klustereiden on käytettävä HSM:ää.
• Jos suorituskyvyn ensisijainen klusteri EI käytä HSM:ää (käyttää Shamir-salaisuudenjakomenetelmää), kyseisen replikaatiojoukon sisällä olevat klusterit voivat olla sekoittuneita siten, että toiset voivat käyttää HSM:ää ja toiset Shamiria.

Tämä käyttäytyminen on suunniteltu. Alempana oleva Shamir-klusteri muodostaa mahdollisen hyökkäysvektorin replikaatioryhmässä, koska avaimenhaltijoiden kynnysarvo voisiluoda pääavaimen; näin ollen se ohittaisi ylempänä olevan HSM-avaimen suojauksen.

”Käyttöönottojärjestelmävaatimukset

Seuraavassa taulukossa on ohjeita palvelimen mitoitusta varten. Erityisen huomionarvoista onvahva suositus välttää muita kuin kiinteän suorituskyvyn suorittimia eli AWS:n termein BurstableCPU:ta, kuten T-sarjan instansseja.

”Vault-palvelimien mitoitus

.

”Sizing for Consul Servers

”Laitteistoon liittyviä näkökohtia

Pieni kokoluokka sopisi useimpiin ensimmäisiin tuotantokäyttöönottoihin tai kehitys-/testausympäristöihin.

Suuri koko sopii tuotantoympäristöihin, joissa on jatkuvasti suuri työmäärä. Tämä voi olla suuri määrä transaktioita, suuri määrä salaisuuksia tai näiden kahden yhdistelmä.

Yleisesti ottaen käsittelyvaatimukset riippuvat salauksen työmäärästä ja viestinnän työmäärästä (operaatiot sekunnissa ja operaatiotyypit). Muistivaatimukset riippuvat muistiin tallennettujen salaisuuksien/avainten kokonaiskoosta, ja ne olisi mitoitettava näiden tietojen mukaan (samoin kuin kiintolevyvarasto). Vaultilla itsellään on minimaaliset tallennustilavaatimukset, mutta taustalla olevalla tallennuksen taustajärjestelmällä tulisi olla suhteellisen suorituskykyinen kiintolevyalijärjestelmä.Jos salaisuuksia luodaan/pyöritetään usein, nämä tiedot on huuhdottava levylle usein, mikä voi vaikuttaa suorituskykyyn, jos käytetään hitaampia kiintolevyjä.

Consul-palvelimen tehtävänä tässä käytössä on toimia Vaultin tallennuksen taustajärjestelmänä. Tämä tarkoittaa, että Vault salaa kaiken Vaultissa säilytettäväksi tallennetun sisällön ja kirjoittaa sen levossa tallennustietokantaan. Nämä tiedot kirjoitetaan Consulin palveluluettelon avain-arvosäilön osioon, joka on tallennettava kokonaisuudessaan muistiin jokaiselle Consul-palvelimelle. Tämä tarkoittaa, että muisti voi olla rajoitteena skaalautumisessa, kun useammat asiakkaat tunnistautuvat Holviin, enemmän salaisuuksia tallennetaan pysyvästi Holviin ja enemmän väliaikaisia salaisuuksia vuokrataan Holvista. Tämä vaikuttaa myös siihen, että Consul-palvelimen muistin vertikaalinen skaalautuminen on tarpeen, jos lisätilaa tarvitaan, koska koko palvelukatalogi tallennetaan muistiin jokaiselle Consul-palvelimelle.

Lisäksi verkon läpäisykyky on yleinen näkökohta Vault- ja Consul-palvelimille. Koska molemmat järjestelmät ovat HTTPS API-ohjattuja, kaikki saapuvat pyynnöt, Vaultin ja Consulin välinen viestintä, taustalla oleva juoruviestintä Consul-klusterin jäsenten välillä, viestintä ulkoisten järjestelmien kanssa (auth- tai secretengine-konfiguraatioiden ja joidenkin auditointilokituskonfiguraatioiden mukaan) ja vastaukset kuluttavat verkon kaistanleveyttä.

Verkkosuorituskykyyn liittyvien näkökohtien vuoksi Consul-klusterin toiminnoissa Vaultin tietokokonaisuuksien replikointi verkon rajapinnoilla tulisi toteuttaa suorituskyky- tai DR-replikoinnilla sen sijaan, että Consul-rypäle levitettäisiin verkon rajojen yli. Jos yksittäinen Consul-klusteri on hajautettu etäisten tai alueiden välisten verkkosegmenttien yli, tämä voi aiheuttaa synkronointiongelmia klusterin sisällä tai ylimääräisiä tiedonsiirtomaksuja joillakin pilvipalveluntarjoajilla.

”Muita näkökohtia

Vaultin tuotantokarkaisusuosituksissa annetaan ohjeita parhaista käytännöistä Vaultin tuotantokarkaistua käyttöönottoa varten.

”Kuormituksen tasaus

”Kuormituksen tasaus Consul-rajapinnan avulla

Consul voi tarjota kuorman tasausominaisuuksia palveluhavainnon kautta, mutta se edellyttää, että kaikki Vault-asiakkaat ovat Consul-tietoisia. Tämä tarkoittaa, että asiakas ei voi käyttää Consulin DNS- tai API-rajapintoja aktiivisen Holvin solmun määrittämiseen. Asiakas voi käyttää Vaultia seuraavan kaltaisen URL-osoitteen kautta:http://active.vault.service.consul:8200

Tämä luottaa käyttöjärjestelmän DNS-resoluutiojärjestelmään, ja pyyntö voidaan välittää Consulille vastausta varten todellisen IP-osoitteen saamiseksi. Operaatio voi olla täysin läpinäkyvä vanhoille sovelluksille, ja se toimisi aivan kuten epätyypillinen DNS-resoluutio-operaatio. Katso lisätietoja kohdasta Consul DNSforwarding

”Kuorman tasapainottaminen ulkoisen kuormantasaajan avulla

Ulkoisia kuormantasaajia tuetaan Vault-klusterin tulopisteenä. Ulkoisen kuormanpainottajan tulisi kysellä theesys/health-päätepistettä aktiivisen solmun havaitsemiseksi ja liikenteen reitittämiseksi sen mukaisesti. Kuormantasaajan tulisi olla määritetty tekemään HTTP-pyyntö seuraavasta URL-osoitteesta jokaiselle klusterin solmulle: http://<Vault Node URL>:8200/v1/sys/health

Aktiivinen Holvin solmu vastaa 200:lla, kun taas varasolmut palauttavat 4xx-vastauksen.

Seuraavassa on esimerkki konfigurointilohkosta HAProxysta havainnollistamaan:

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

Huomaa, että ylläoleva lohko voitaisiin luoda Consulilla (consul-template-ohjelmalla)kun käytetään ohjelmistokuorman tasaajan ohjelmistoa. Näin voi olla silloin, kun kuormantasaajana on ohjelmisto, kuten Nginx, HAProxy tai Apache.

Esimerkki Consul-mallista yllä olevalle HAProxy-lohkolle:

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

”Asiakkaan IP-osoitteen käsittely

Välityspalvelimen tai kuorman tasaajan takana olevan asiakkaan IP-osoitteen käsittelyyn on kaksi tuettua menetelmää; X-Forwarded-ForHeadersja PROXYv1.Molemmat edellyttävät luotettavan kuormantasaajan ja IP-osoitteen luettelointia sallituiksi osoitteiksi parhaiden turvallisuuskäytäntöjen noudattamiseksi.

”Lisäviitteet

• Vault-arkkitehtuurin dokumentaatiossa selitetään kukin Vault-komponentti
• Yhdistääksesi Vaultin olemassa olevaan LDAP-palvelimeen, tutustuLDAP Auth Method -dokumentaatioon
• Viittaa AppRole PullAuthentication -oppaaseen, kun haluat ohjelmallisesti generoida tunnisteen konetta tai sovellusta varten
• Konsolista on olennainen osa joustavan Holttiklusterin pyörittämistä sijainnista riippumatta. Tutustu verkossa olevaan Consuld -dokumentaatioon oppiaksesi lisää.

”Seuraavat vaiheet

• Lue Production Hardening oppiaksesi parhaita käytäntöjä Vaultin tuotantokäyttöönottoa varten.
• Lue Deployment Guide oppiaksesi vaiheet, joita tarvitaan yksittäisen HashiCorp Vaultin klusterin asentamiseen ja konfiguroimiseen.