Free Press

Lo scopo di questo documento è di raccomandare le pratiche di implementazione del Vault HashiCorp. Questa architettura di riferimento trasmette un’architettura generale che dovrebbe essere adattata per accomodare i bisogni specifici di ogni implementazione.

I seguenti argomenti sono trattati in questa guida:

• Riassunto della progettazione
  • Connettività di rete
  • Tolleranza ai guasti
• Architettura consigliata
  • Distribuzione in una sola regione (impresa)
  • Distribuzione in più regioni Deployment (Enterprise)
• Architettura del caso migliore
  • Deployment di Vault in una Availability Zone (all)
  • Deployment di Vault in due Availability Zones (OSS)
  • Deployment di Vault in due Availability Zones (Enterprise)
  • Deployment di Vault in tre Availability Zones (OSS)
• Vault Replication (Enterprise Only)
• Requisiti di sistema
  • Hardware Considerazioni
• Bilanciamento del carico
• Riferimenti aggiuntivi

“Glossario

“Cluster Vault

Un cluster Vault è un insieme di processi Vault che insieme eseguono un servizio Vault.Questi processi Vault possono essere eseguiti su server fisici o virtuali, o in contenitori.

“Cluster di backend di archiviazione Consul

HashiCorp raccomanda e supporta Consul come backend di archiviazione perVault. Un cluster Consul è un insieme di processi server Consul che insieme eseguono un servizio Consul. Questi processi Consul potrebbero essere eseguiti su server fisici o virtuali, o in container.

“Availability Zone

Un singolo dominio di fallimento a livello di località che ospita parte o tutto un cluster diVault. La latenza tra le zone di disponibilità dovrebbe essere < 8ms per circa un viaggio. Un singolo cluster Vault può essere distribuito su più zone di disponibilità.

Esempi di una zona di disponibilità in questo contesto sono:

• Un datacenter isolato
• Una gabbia isolata in un datacenter se è isolata da altre gabbie con tutti gli altri mezzi (potenza, rete, ecc)
• Una zona di disponibilità in AWS, Azure o GCP

“Regione

Un insieme geograficamente separato di una o più zone di disponibilità. Una regione può ospitare uno o più cluster di Vault. Non c’è un requisito di latenza massima definito tra le regioni nell’architettura Vault. Un singolo cluster Vault non sarebbe distribuito su più regioni.

“Design Summary

Questo design è l’architettura raccomandata per gli ambienti di produzione, poiché fornisce flessibilità e resilienza.

È una raccomandazione importante per l’architettura che i server Consul siano separati dai server Vault e che il cluster Consul sia usato solo come storagebackend per Vault e non per altre funzionalità focalizzate su Consul (ad esempio la segmentazione dei servizi e la scoperta dei servizi) che possono introdurre un utilizzo imprevedibile delle risorse. Separare Vault e Consul permette a ciascuno di avere un sistema che può essere dimensionato adeguatamente in termini di CPU, memoria e disco. Consul è un’applicazione ad alta intensità di memoria e quindi separarla dalle proprie risorse è vantaggioso per prevenire la contesa o la fame di risorse. Dedicare un cluster di Consul come backend per lo storage di Vault è anche vantaggioso, perché questo permette di aggiornare il cluster di Consul solo se necessario per migliorare la funzionalità del backend dello storage di Vault, che probabilmente sarà molto meno frequente di un cluster di Consul usato anche per il service discovery e la segmentazione dei servizi.

La connettività tra Consul e il backend di Vault avviene tramite HTTP e dovrebbe essere protetta con TLS e con un token Consul per fornire la crittografia di tutto il traffico. Vedi la Guida alla distribuzione di Vault per maggiori informazioni. Poiché il cluster Consul per lo storage del Vault può essere usato in aggiunta e separato da un cluster Consul per il service discovery, si raccomanda che il processo Consul per lo storage sia eseguito su porte non predefinite in modo da non entrare in conflitto con altre funzionalità Consul. Impostando il cluster di archiviazione Consul per l’esecuzione su 7xxxporte e utilizzando questa come porta di archiviazione nella configurazione del Vault si otterrà questo risultato. Si raccomanda inoltre che Consul venga eseguito utilizzando TLS.

“Dettagli sulla connettività di rete

La seguente tabella delinea i requisiti del traffico di rete per i clusternodes di Vault.

“Configurazioni di rete alternative

Vault può essere configurato in diversi modi per le comunicazioni tra i clusterault e Consul:

• Utilizzando indirizzi IP di host o nomi di host risolvibili tramite il sottosistema di nomi standard
• Utilizzando indirizzi IP di bilanciatori di carico o nomi di host risolvibili tramite il sottosistema di nomi standard
• Utilizzando il cluster Consul allegato DNS come service discovery per risolvere gli endpoint del Vault
• Utilizzando un cluster Consul separato DNS come service discovery per risolvere gli endpoint del Vault

Tutte queste opzioni sono approfondite nella Guida alla distribuzione del Vault.

“Tolleranza ai guasti

Vault è progettato per gestire diversi scenari di guasto che hanno diverse probabilità. Quando si distribuisce un cluster di Vault, la tolleranza ai guasti che si richiede dovrebbe essere considerata e progettata. In OSS Vault il numero raccomandato di istanze è 3 in un cluster in quanto qualsiasi altro avrebbe un valore limitato. In Vault Enterprise il numero raccomandato è anche 3 in un cluster, ma se ne possono usare di più se sono performanti per aiutare il carico di lavoro di sola lettura. Il cluster Consul è da una a sette istanze, che dovrebbe essere un numero dispari per permettere che le elezioni della leadership si risolvano sempre. Si raccomanda che il cluster Consul sia di almeno cinque istanze che sono dedicate ad eseguire funzioni di backend storage solo per il cluster Vault.

“Node

Il software dei cluster Vault e Consul permette un dominio di fallimento a livello di nodo avendo la replica all’interno del cluster. In un singolo cluster HA Vault tutti i nodi condividono lo stesso backend di storage sottostante e quindi i dati. Vaultachieves questo da uno dei server Vault ottenendo un blocco all’interno del data storereto diventare il nodo Vault attivo e questo ha accesso in scrittura. Se in qualsiasi momento il leader viene perso, un altro nodo Vault prenderà perfettamente il suo posto come leader. Per ottenere una ridondanza n-2 (dove la perdita di 2 oggetti all’interno del dominio di fallimento può essere tollerata), una dimensione ideale per un cluster Vault sarebbe 3.Consul ottiene la replica e la leadership attraverso l’uso dei suoi protocolli di consenso e di gossip. In questi protocolli, un leader viene eletto per consenso e quindi deve sempre esistere un aquorum di server attivi. Per ottenere una ridondanza n-2, la dimensione ideale di un cluster Consul è 5. Vedere ConsulInternals per maggiori dettagli.

“Availability Zone

La distribuzione tipica in un ambiente cloud è quella di distribuire i nodi Consul/Vault in Zone di Disponibilità (AZ) separate all’interno di una rete ad alta larghezza di banda e bassa latenza, come una regione AWS, tuttavia questo potrebbe non essere possibile in un’installazione di datacenter dove c’è solo un DC con il livello di latenza richiesto.

È importante capire un cambiamento nel requisito o nelle migliori pratiche che si è verificato come risultato dello spostamento verso un maggiore utilizzo di sistemi altamente distribuiti come Consul. Quando si opera in ambienti composti da sistemi distribuiti, è necessario un cambiamento nel coefficiente di ridondanza dei componenti sottostanti. Consul si basa sulla negoziazione del consenso per organizzare e replicare le informazioni e quindi l’ambiente deve fornire 3 percorsi resilienti unici per fornire un’affidabilità significativa. Essenzialmente, un sistema di consenso richiede che una semplice maggioranza di nodi sia disponibile in qualsiasi momento. Nell’esempio di 3 nodi, è necessario averne 2 disponibili. Se questi 3 nodi sono collocati in due domini di fallimento, c’è una probabilità del 50% che la perdita di un singolo dominio di fallimento comporti un’interruzione completa.

“Regione

Per proteggere da un guasto a livello di regione, oltre a fornire ulteriori capacità di scaling geografico, Vault Enterprise offre:

• Disaster Recovery Replication
• Performance Replication

Per una descrizione completa di queste opzioni, consultare gli schemi consigliati su Vault Replication.

A causa dei vincoli elencati sopra, l’architettura raccomandata è conVault e Consul Enterprise distribuiti in tre zone di disponibilità all’interno di un cluster e per i cluster da replicare attraverso le regioni utilizzando la replica DR e Performance. Ci sono anche diverse architetture “Best Case” per una e due Availability Zone e anche per Consul OSS. Queste non sono le architetture raccomandate, ma sono le migliori soluzioni se il tuo deployment è limitato dalla versione di Console o dal numero di zone di disponibilità.

“Architettura raccomandata

L’architettura sottostante è il miglior approccio raccomandato per il deployment di Vault e dovrebbe essere l’architettura di destinazione per qualsiasi installazione. Questa è divisa in due parti:

• Cluster del vault – Questa è l’architettura raccomandata per un cluster del vault come singola entità, ma dovrebbe anche usare la replica come da secondo diagramma
• Replicazione del vault – Questa è l’architettura raccomandata per più cluster del vault per permettere il recupero regionale, le prestazioni e il disastro.

“Single Region Deployment (Enterprise)

In questo scenario, i nodi del Vault e il suo cluster Consul associato sono ospitati tra tre Availability Zones. Questa soluzione ha un n-2 a livello di nodo per Vault e un n-3 a livello di nodo per Consul. A livello di AvailabilityZone, Vault è a n-2 e Consul a n-1. Questo differisce dal progetto OSS in quanto il cluster Consul ha sei nodi con tre di essi come membri non votanti. Il cluster Consul è impostato usando RedundancyZones in modo che se un qualsiasi nodo dovesse fallire, un membro non votante verrebbe promosso da Autopilot per diventare un membro effettivo e mantenere così il quorum.

“Multiple Region Deployment (Enterprise)

“Reference Diagram Resilience against Region Failure

In questo scenario, i cluster sono replicati per proteggersi dal fallimento di una regione completa. Ci sono tre cluster di Performance Replica Vault (cluster A, B, C) ciascuno con il proprio cluster DR (cluster D, E, F) in una regione diversa. Ogni cluster ha il suo cluster Consul associato per lo storage backend.

Questa architettura consente n-2 a livello di regione a condizione che tutti i segreti e i motori dei segreti siano replicati in tutti i cluster. Il fallimento della Region1 completa richiederebbe la promozione del cluster DR F. Una volta fatto questo, la Vaultsolution sarebbe pienamente funzionale con una certa perdita di ridondanza fino a quando Region1 fosse ripristinata. Le applicazioni non dovrebbero riautenticarsi poiché il DRcluster per ogni cluster fallito conterrebbe tutti i lease e i token.

“Diagramma di riferimento Resilienza contro il fallimento del cluster

Questa soluzione ha piena resilienza a livello di cluster, ma non protegge dal fallimento della regione poiché i cluster DR per le repliche delle prestazioni sono nella regione. Ci sono alcuni casi d’uso in cui questo è il metodo preferito wheredata non può essere replicato in altre regioni a causa di restrizioni di governance come GDPR. Inoltre alcuni framework di infrastruttura potrebbero non avere la capacità di instradare il traffico dell’applicazione a diverse regioni.

“Best Case Architecture

In alcune implementazioni ci possono essere restrizioni insormontabili che significano che l’architettura consigliata non è possibile. Questo potrebbe essere dovuto alla mancanza di zone disponibili o all’uso di Vault OSS. In questi casi, le architetture sottostanti dettagliano le migliori opzioni disponibili.

Nota che in queste architetture seguenti il leader Consul potrebbe essere uno qualsiasi dei cinque nodi server Consul e il nodo attivo Vault potrebbe essere uno qualsiasi dei tre nodi Vault

“Deployment di Vault in una Availability Zone (all)

In questo scenario, tutti i nodi Vault e il suo cluster Consul associato sono ospitati all’interno di una Availability Zone. Questa soluzione ha un singolo punto di errore a livello di zona di disponibilità, ma un n-2 a livello di nodo sia per Consul che per Vault. Questa non è l’architettura raccomandata da Hashicorp per i sistemi di produzione perché non c’è ridondanza a livello di zona di disponibilità. Inoltre non c’è capacità di DR e quindi come minimo questo dovrebbe avere almeno una replica DR in una Regione separata.

“Deployment di Vault in due Availability Zone (OSS)

In questo scenario, i nodi di Vault e il suo cluster Console associato sono ospitati tra due Availability Zone. Questa soluzione ha un n-2 a livello di nodo per Vault e Consul e n-1 per Vault a livello di Availability Zone, ma l’aggiunta di una Availability Zone non aumenta significativamente la disponibilità del cluster Consul. Questo perché il protocollo Raft richiede un quorum di (n/2)+1 e se la Zona B dovesse fallire nel diagramma precedente, allora il cluster non sarebbe in quorum e quindi fallirebbe anch’esso. Questa non è l’architettura raccomandata da Hashicor per i sistemi di produzione, poiché c’è solo una parziale ridondanza a livello di zona di disponibilità e un fallimento della zona di disponibilità potrebbe non risultare in un’interruzione di servizio.

“Distribuzione di Vault in due zone di disponibilità (Enterprise)

A causa della necessità di mantenere il quorum nel cluster Consul, avere solo 2 zone di disponibilità non è ideale. Non c’è modo di distribuire un cluster Consul su due AZs con alcuna garanzia di resilienza aggiunta. La soluzione migliore inVault Enterprise è trattare le due AZ come regioni e avere cluster Vault separati in ciascuna.

Il cluster secondario di Vault può essere sia una Performance Replica che una DR Replica, ognuna con i propri vantaggi:

• PR secondario: Se l’indirizzo di Vault è gestito da Consul o da un load balancer, allora un guasto di uno dei due cluster farà sì che il traffico sia diretto all’altro cluster senza interruzioni, sempre che ci sia una logica nella vostra applicazione o nell’agente Vault per gestire la ri-richiesta dei token che non sono replicati tra i cluster.
• DR secondario: In questo caso il fallimento del cluster primario comporterà la necessità di un intervento dell’operatore per promuovere il DR al primario, ma poiché tutti i rilasci e i token sono replicati, non ci sarebbe bisogno di alcuna logica aggiuntiva nell’applicazione per gestire questo.

“Deployment di Vault in tre Availability Zones (OSS)

In questo scenario, i nodi di Vault e il cluster Consul associato sono ospitati tra tre Availability Zones. Questa soluzione ha un n-2 a livello di nodo per Vault e Consul e n-2 per Vault a livello di Zona di Disponibilità; ha anche un n-1 a livello di Zona di Disponibilità per Consul e come tale è considerata la più resiliente di tutte le architetture per un singolo cluster Vault con un backend di storage Consul per il prodotto OSS.

“Vault Replication (Enterprise Only)

In queste architetture il cluster Vault è illustrato come una singola entità, e sarebbe uno dei singoli cluster descritti sopra in base al numero di Availability Zone. Cluster multipli di Vault che agiscono come una singola soluzione di Vault e replicano tra di loro è disponibile solo in Enterprise Vault. OSSVault può essere configurato in più cluster, ma ognuno di essi sarebbe una soluzione Vault individuale e non supporterebbe la replica tra i cluster.

La documentazione di Vault fornisce informazioni più dettagliate sulle capacità di replica all’interno di VaultEnterprise.

“Performance Replication

La replica delle prestazioni di Vault consente la gestione dei segreti in molti siti.I segreti statici, i metodi di autenticazione e i criteri di autorizzazione sono replicati per essere attivi e disponibili in più sedi, mentre i leasestokens e i segreti dinamici non lo sono.

“Disaster Recovery Replication

Vault disaster recovery replication assicura che un cluster Vault standby sia mantenuto sincronizzato con un cluster Vault attivo. Questa modalità di replica include dati come i token di autenticazione effimeri, informazioni sui token basati sul tempo e dati sull’uso dei token. Questo fornisce un obiettivo di punto di recupero aggressivo in ambienti in cui prevenire la perdita di dati operativi effimeri è della massima preoccupazione. In qualsiasi soluzione aziendale, le repliche di Disaster Recovery sono considerate essenziali.

“Corruzione o sabotaggio del Disaster Recovery

Un altro scenario comune da cui proteggersi, più diffuso negli ambienti cloud che forniscono livelli molto elevati di resilienza intrinseca, potrebbe essere la corruzione intenzionale o accidentale dei dati e della configurazione e/o una perdita di controllo degli account cloud. DR Replication di Vault è progettato per replicare i dati in tempo reale, il che propagherebbe la corruzione o l’eliminazione intenzionale o accidentale dei dati. Per proteggersi da queste possibilità, è necessario eseguire il backup dello storage backend di Vault, supportato dalla funzione ConsulSnapshot, che può essere automatizzata per eseguire regolarmente i backup di archivio. Un sito freddo o una nuova infrastruttura potrebbero essere reidratati da uno snapshot Consul.

“Replication Notes

Non c’è un limite stabilito sul numero di cluster all’interno di un set di replica. Le distribuzioni più grandi oggi sono nell’intervallo di 30+ cluster. Un cluster di Performance Replica può avere un cluster di Disaster Recovery associato ad esso e può anche replicare a più cluster di Disaster Recovery.

Mentre un cluster Vault può possedere un ruolo (o più ruoli) di replica, non sono richieste particolari considerazioni in termini di infrastruttura e i cluster possono assumere (o essere promossi o retrocessi) un altro ruolo. Circostanze speciali relative ai filtri di montaggio e all’uso dell’Hardware Security Module (HSM) possono limitare la sostituzione dei ruoli, ma queste sono basate su configurazioni specifiche dell’organizzazione.

“Considerazioni relative all’integrazione dell’HSM

L’uso della replica con cluster Vault integrati con l’Hardware Security Module (HSM) o con dispositivi di auto-sigillazione del cloud per operazioni di smascheramento automatico ha alcuni dettagli che dovrebbero essere compresi durante la fase di pianificazione.

• Se un cluster primario di prestazioni utilizza un HSM, anche tutti gli altri cluster all’interno di quel set di replica devono utilizzare un HSM.
• Se un performance primary cluster NON usa un HSM (usa il metodo di condivisione dei segreti Shamir), i cluster all’interno di quel set di replicazione possono essere misti, così che alcuni possono usare un HSM, altri possono usare Shamir.

Questo comportamento è progettato. Un cluster Shamir a valle presenta un potenziale vettore di attacco nel gruppo di replica poiché una soglia di possessori di chiavi potrebbe ricreare la chiave principale; quindi, bypassando la protezione delle chiavi HSM a monte.

“Deployment System Requirements

La seguente tabella fornisce linee guida per il dimensionamento dei server. Di particolare nota è la forte raccomandazione di evitare CPU a prestazioni non fisse, o BurstableCPU in termini AWS, come le istanze della serie T.

“Dimensionamento dei server Vault

“Dimensionamento per Console Servers

“Considerazioni sull’hardware

La categoria di piccole dimensioni sarebbe appropriata per la maggior parte delle distribuzioni di produzione iniziale, o per ambienti di sviluppo/test.

La grande dimensione è per ambienti di produzione dove c’è un alto carico di lavoro costante. Questo potrebbe essere un grande numero di transazioni, un grande numero di segreti, o una combinazione dei due.

In generale, i requisiti di elaborazione dipenderanno dal carico di lavoro di crittografia e dal carico di lavoro di messaggistica (operazioni al secondo e tipi di operazioni). I requisiti di memoria dipenderanno dalla dimensione totale dei segreti/chiavi memorizzati in memoria e dovrebbero essere dimensionati in base a quei dati (così come l’hard disk). Vault in sé ha requisiti minimi di memorizzazione, ma il backend di memorizzazione sottostante dovrebbe avere un sottosistema di hard disk relativamente performante.Se molti segreti vengono generati/ruotati frequentemente, queste informazioni avranno bisogno di eseguire spesso il flush su disco e possono avere un impatto sulle prestazioni se vengono utilizzati hard disk più lenti.

La funzione dei server Consul in questa implementazione è di servire come backendfor Vault di memorizzazione. Questo significa che tutti i contenuti memorizzati per la persistenza in Vault sono criptati da Vault e scritti sul backend di archiviazione a riposo. Questi dati vengono scritti nella sezione key-value store del Service Catalog di Consul, che deve essere memorizzato interamente in memoria su ogni server Consul. Questo significa che la memoria può essere un vincolo nella scalabilità man mano che più client si autenticano a Vault, più segreti vengono memorizzati in modo persistente in Vault e più segreti temporanei vengono affittati da Vault. Questo ha anche l’effetto di richiedere uno scaling verticale sulla memoria del server Consul se è richiesto ulteriore spazio, poiché l’intero ServiceCatalog è memorizzato nella memoria di ogni server Consul.

Inoltre, il throughput di rete è una considerazione comune per Vault e Consulservers. Poiché entrambi i sistemi sono guidati da API HTTPS, tutte le richieste in entrata, le comunicazioni tra Vault e Console, le comunicazioni gossip sottostanti tra i membri del cluster Consul, le comunicazioni con i sistemi esterni (per la configurazione auth o secretengine, e alcune configurazioni di audit logging) e le risposte consumano larghezza di banda di rete.

A causa delle considerazioni sulle prestazioni di rete nelle operazioni del cluster Consul, la replica dei dataset Vault attraverso i confini di rete dovrebbe essere realizzata attraverso Performance o DR Replication, piuttosto che distribuire il cluster Consul attraverso i confini di rete e fisici. Se un singolo cluster di Consul è distribuito su segmenti di rete distanti o interregionali, ciò può causare problemi di sincronizzazione all’interno del cluster o costi di trasferimento dati aggiuntivi in alcuni fornitori di cloud.

“Other Considerations

Vault Production Hardening Recommendationsfornisce una guida sulle migliori pratiche per una distribuzione hardened di produzione diVault.

“Load Balancing

“Load Balancing Using Consul Interface

Consul può fornire capacità di bilanciamento del carico attraverso il service discovery, ma richiede che ogni client di Vault sia consapevole di Consul. Questo significa che un client non può usare il DNS di Consul o le interfacce API per risolvere il nodo attivo del Vault. Un cliente potrebbe accedere a Vault tramite un URL come il seguente:http://active.vault.service.consul:8200

Questo si basa sul sistema di risoluzione DNS del sistema operativo, e la richiesta potrebbe essere inoltrata a Consul per la risposta dell’indirizzo IP effettivo. L’operazione può essere completamente trasparente alle applicazioni legacy e funzionerebbe proprio come un’operazione di risoluzione DNS atipica. Vedi Consul DNSforwarding per maggiori informazioni

“Load Balancing Using External Load Balancer

I load balancer esterni sono supportati come punto d’ingresso in un cluster Vault. Il load balancer esterno dovrebbe eseguire il polling dell’endpointsys/health per rilevare il nodo attivo e instradare il traffico di conseguenza. Il load balancer dovrebbe essere configurato per fare una richiesta HTTP per il seguente URL ad ogni nodo nel cluster: http://<Vault Node URL>:8200/v1/sys/health

Il nodo attivo del Vault risponderà con un 200 mentre i nodi in standby restituiranno una risposta 4xx.

Il seguente è un blocco di configurazione di esempio da HAProxy per illustrare:

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

Nota che il blocco sopra potrebbe essere generato da Consul (con consul-template) quando viene usato un software load balancer. Questo potrebbe essere il caso quando il loadbalancer è un software come Nginx, HAProxy o Apache.

Esempio di template Console per il blocco HAProxy di cui sopra:

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

“Client IP Address Handling

Ci sono due metodi supportati per gestire l’indirizzo IP del client dietro un proxy o load balancer; X-Forwarded-ForHeaders e PROXYv1.Entrambi richiedono un bilanciatore di carico affidabile e un indirizzo IP da elencare come indirizzi consentiti per aderire alle migliori pratiche di sicurezza.

“Ulteriori riferimenti

• La documentazione dell’architettura di Vault spiega ogni componente di Vault
• Per integrare Vault con un server LDAP esistente, fare riferimento alla documentazione sul metodo di autenticazioneLDAP
• Riferimento al tutorial AppRole PullAuthentication per generare programmaticamente un token per una macchina o un’applicazione
• Consul è parte integrante dell’esecuzione di un cluster Vault resiliente, indipendentemente dalla posizione. Fai riferimento alla documentazione online di Consul per saperne di più.

“Passi successivi

• Leggi Production Hardening per imparare le migliori pratiche per una distribuzione di Vault con hardening in produzione.
• Leggi Deployment Guide per imparare i passi richiesti per installare e configurare un singolo cluster HashiCorp Vault.