“Architettura

Vault è un sistema complesso che ha molti pezzi diversi. Per aiutare sia gli utenti che gli sviluppatori di Vault a costruire un modello mentale di come funziona, questa pagina documenta l’architettura del sistema.

Prima di descrivere l’architettura, forniamo un glossario di termini per aiutare a chiarire ciò che viene discusso:

• Storage Backend – Uno storage backend è responsabile della conservazione durevole dei dati cifrati. I backend non sono fidati da Vault e ci si aspetta solo che forniscano durabilità. Lo storage backend è configurato quando si avvia il Vaultserver.

• Barriera – La barriera è acciaio crittografico e cemento attorno al Vault. Tutti i dati che fluiscono tra il Vault e lo storage backend passano attraverso la barriera. La barriera assicura che solo i dati criptati siano scritti all’esterno, e che i dati siano verificati e decriptati all’ingresso. Proprio come un caveau, la barriera deve essere “aperta” prima che si possa accedere a qualsiasi cosa al suo interno.

• Motore dei segreti – Un motore dei segreti è responsabile della gestione dei segreti.I semplici motori dei segreti come il motore dei segreti “kv” restituiscono semplicemente lo stesso segreto quando vengono interrogati. Alcuni motori di segreti supportano l’uso di politiche per generare dinamicamente un segreto ogni volta che vengono interrogati. Questo permette l’uso di segreti unici che permettono a Vault di fare revoche e aggiornamenti delle politiche a grana fine. Come esempio, un motore di segreti MySQL potrebbe essere configurato con una politica “web”. Quando il segreto “web” viene letto, viene generata una nuova coppia utente/password MySQL con un insieme limitato di privilegi per il server web.

• Audit Device – Un audit device è responsabile della gestione dei log di audit.Ogni richiesta a Vault e risposta da Vault passa attraverso il configuredaudit device. Questo fornisce un modo semplice per integrare Vault con più destinazioni di registrazione di audit di tipo diverso.

• Metodo di autenticazione – Un metodo di autenticazione è usato per autenticare gli utenti o le applicazioni che si connettono a Vault. Una volta autenticato, il metodo auth restituisce l’elenco delle policy applicabili che dovrebbero essere applicate. Vault prende un utente autenticato e restituisce un client token che può essere utilizzato per future richieste. Come esempio, il metodo userpass auth usa un nome utente e una password per autenticare l’utente. In alternativa, il metodo github auth permette agli utenti di autenticarsi tramite GitHub.

• Token cliente – Un token cliente (detto anche “Vault Token”) è concettualmente simile a un cookie di sessione su un sito web. Una volta che un utente si autentica, Vault restituisce un token cliente che viene utilizzato per le richieste future. Il token è usato da Vault per verificare l’identità del cliente e per applicare le politiche ACL applicabili. Questo token è passato attraverso le intestazioni HTTP.

• Secret – Un secret è il termine per qualsiasi cosa restituita da Vault che contiene materiale riservato o crittografico. Non tutto ciò che viene restituito da Vault è un segreto, per esempio la configurazione del sistema, le informazioni di stato o le politiche non sono considerate segreti. I segreti hanno sempre un lease associato, il che significa che i clienti non possono assumere che il contenuto del segreto possa essere usato all’infinito. Vault revocherà un segreto alla fine del lease, e un operatore può intervenire per revocare il segreto prima che il lease sia finito. Questo contratto tra Vault e i suoi clienti è fondamentale, in quanto permette di cambiare le chiavi e le politiche senza intervento manuale.

• Server – Vault dipende da un’istanza a lungo termine che opera come server. Il server Vault fornisce un’API con cui i clienti interagiscono e gestisce l’interazione tra tutti i motori dei segreti, l’applicazione delle ACL e la revoca del leasing dei segreti. Avere un’architettura basata su server disaccoppia i client dalle chiavi di sicurezza e dalle politiche, permette la registrazione centralizzata dei controlli e semplifica l’amministrazione per gli operatori.

“Panoramica ad alto livello

Una panoramica ad alto livello di Vault si presenta così:

Cominciamo a scomporre questo quadro. C’è una chiara separazione dei componenti che sono dentro o fuori la barriera di sicurezza. Solo lo storagebackend e l’API HTTP sono fuori, tutti gli altri componenti sono dentro la barriera.

Lo storage backend è untrusted e viene utilizzato per memorizzare in modo duraturo i dati criptati.Quando il server Vault viene avviato, deve essere fornito con uno storage backend in modo che i dati siano disponibili attraverso i riavvii. Anche l’API HTTP deve essere avviata dal server del Vault all’avvio, in modo che i client possano interagire con essa.

Una volta avviato, il Vault è in uno stato sigillato. Prima che qualsiasi operazione possa essere eseguita sul Vault, esso deve essere sbloccato. Questo viene fatto fornendo le unsealkeys. Quando il Vault viene inizializzato, genera una chiave di crittografia che viene utilizzata per proteggere tutti i dati. Questa chiave è protetta da una chiave principale. Per impostazione predefinita, Vault utilizza una tecnica nota come algoritmo di condivisione del segreto di Shamir per dividere la chiave master in 5 parti, 3 delle quali sono necessarie per ricostruire la masterkey.

Il numero di parti e la soglia minima richiesta possono essere entrambi specificati.La tecnica di Shamir può essere disabilitata, e la chiave master utilizzata direttamente per l’unsealing. Una volta che Vault recupera la chiave di crittografia, è in grado di decifrare i dati nel backend di archiviazione, ed entra nello stato unsealed. Una volta sbloccato, Vault carica tutti i dispositivi di controllo configurati, i metodi di autenticazione e i motori segreti.

La configurazione di tali dispositivi di controllo, metodi di autenticazione e motori segreti deve essere memorizzata in Vault poiché sono sensibili alla sicurezza. Solo gli utenti con i permessi corretti dovrebbero essere in grado di modificarli, il che significa che non possono essere specificati al di fuori della barriera. Memorizzandoli nel Vault, qualsiasi modifica ad essi è protetta dal sistema ACL e tracciata dai log di audit.

Dopo che il Vault è stato aperto, le richieste possono essere processate dall’API HTTP al Core. Il core è usato per gestire il flusso di richieste attraverso il sistema, far rispettare le ACL e assicurare la registrazione di audit.

Quando un client si connette per la prima volta al Vault, deve autenticarsi. Vault fornisce metodi di autenticazione configurabili che forniscono flessibilità nel meccanismo di autenticazione utilizzato. Meccanismi di facile utilizzo come username/password o GitHub possono essere utilizzati per gli operatori, mentre le applicazioni possono utilizzare chiavi pubbliche/private o token per autenticarsi. Una richiesta di autenticazione passa attraverso il core e in un metodo di autenticazione, che determina se la richiesta è valida e restituisce una lista di policy associate.

Le policy sono solo una regola ACL denominata. Per esempio, la policy “root” è integrata e permette l’accesso a tutte le risorse. È possibile creare un numero qualsiasi di policy nominate con un controllo a grana fine sui percorsi. Vault opera esclusivamente in modalità whitelist, il che significa che a meno che l’accesso non sia esplicitamente concesso tramite una policy, l’azione non è consentita. Poiché un utente può avere più politiche associate, un’azione è consentita se una qualsiasi politica la permette. Le politiche sono memorizzate e gestite da un negozio interno di politiche. Questo negozio interno è manipolato attraverso il backend di sistema, che è sempre montato a sys/.

Una volta che l’autenticazione ha luogo e un metodo di autenticazione fornisce un insieme di politiche applicabili, un nuovo token client è generato e gestito dal negozio di token. Questo token client viene inviato di nuovo al client e viene utilizzato per effettuare richieste future. Questo è simile a un cookie inviato da un sito web dopo che un utente ha effettuato l’accesso. Il client token può avere un lease associato ad esso a seconda della configurazione del metodo di autenticazione. Questo significa che il token del cliente può aver bisogno di essere rinnovato periodicamente per evitare l’invalidazione.

Una volta autenticati, le richieste sono fatte fornendo il token del cliente. Il token viene utilizzato per verificare che il client sia autorizzato e per caricare le relative politiche. Le politiche sono usate per autorizzare la richiesta del client. La richiesta viene quindi indirizzata al motore dei segreti, che viene elaborato a seconda del suo tipo. Se il secretsengine restituisce un segreto, il nucleo lo registra con il gestore delle scadenze e gli attribuisce un lease ID. L’ID del lease è usato dai clienti per rinnovare o revocare il loro segreto. Se un client lascia scadere il lease, l’expiration manager revoca automaticamente il segreto.

Il core gestisce la registrazione delle richieste e delle risposte al broker di audit, che inoltra la richiesta a tutti i dispositivi di audit configurati. Al di fuori del flusso di richieste, il nucleo esegue alcune attività in background. La gestione delle locazioni è fondamentale, in quanto permette ai token o ai segreti dei clienti scaduti di essere revocati automaticamente. Inoltre, Vault gestisce alcuni casi di fallimento parziale utilizzando la registrazione in scrittura anticipata con un gestore di rollback. Questo è gestito in modo trasparente all’interno del core e non è visibile all’utente.

“Getting in Depth

Questa è stata una breve panoramica di alto livello dell’architettura di Vault. Ci sono più dettagli disponibili per ciascuno dei sottosistemi.

Per altri dettagli, consultare il codice, chiedere su IRC o contattare la mailing list.