„Arhitectura

Vault este un sistem complex care are multe piese diferite. Pentru a ajuta atât utilizatorii, cât și dezvoltatorii de Vault să construiască un model mental al modului în care funcționează, această pagină documentează arhitectura sistemului.

Înainte de a descrie arhitectura, oferim un glosar de termeni pentru a ajuta la clarificarea a ceea ce se discută:

• Storage Backend – Un backend de stocare este responsabil pentru stocarea durabilă a datelor criptate. Backend-urile nu sunt de încredere pentru Vault și se așteaptă doar să asigure durabilitatea. Backend-ul de stocare este configurat la pornirea serverului Vaultserver.

• Barrier – Bariera este oțel și beton criptografic în jurul Vaultserverului. Toate datele care circulă între Vault și backend-ul de stocare trec prin barieră. Bariera se asigură că numai datele criptate sunt scrise la ieșire și că datele sunt verificate și decriptate la intrare. La fel ca un bankvault, bariera trebuie să fie „desigilată” înainte ca orice lucru din interior să poată fi accesat.

• Motor de secrete – Un motor de secrete este responsabil pentru gestionarea secretelor.Motoarele de secrete simple, cum ar fi motorul de secrete „kv”, returnează pur și simplu același secret atunci când sunt interogate. Unele motoare de secrete acceptă utilizarea politicilor pentru a genera dinamic un secret de fiecare dată când sunt interogate. Acest lucru permite utilizarea unor secrete unice, ceea ce permite lui Vault să efectueze o revocare fină și actualizări de politici. Ca exemplu, un motor de secrete MySQL poate fi configurat cu o politică „web”. Atunci când secretul „web” este citit, o nouă pereche de utilizator/parolă MySQL va fi generată cu un set limitat de privilegii pentru serverul web.

• Dispozitiv de audit – Un dispozitiv de audit este responsabil pentru gestionarea jurnalelor de audit.Fiecare solicitare către Vault și fiecare răspuns de la Vault trece prin dispozitivele de configurareaudit. Acest lucru oferă o modalitate simplă de a integra Vault cu mai multe destinații de jurnale de audit de diferite tipuri.

• Metoda de autentificare – O metodă de autentificare este utilizată pentru a autentifica utilizatorii sau aplicațiilecare se conectează la Vault. Odată autentificată, metoda auth returnează lista de politici aplicabile care trebuie aplicate. Vault ia un utilizator autentificat și returnează un jeton de client care poate fi utilizat pentru cereri viitoare. Ca exemplu, metoda userpass auth folosește un nume de utilizator și o parolă pentru a autentifica utilizatorul. Alternativ, metoda github authpermite utilizatorilor să se autentifice prin intermediul GitHub.

• Client Token – Un client token (alias „Vault Token”) este conceptualsimilar cu un cookie de sesiune pe un site web. Odată ce un utilizator se autentifică, Vaultrece un client token care este folosit pentru cererile viitoare. Tokenul este utilizat de Vault pentru a verifica identitatea clientului și pentru a aplica politicile ACL aplicabile. Acest token este transmis prin intermediul antetelor HTTP.

• Secret – Un secret este termenul pentru orice lucru returnat de Vault careconține material confidențial sau criptografic. Nu tot ceea ce este returnat deVault este un secret, de exemplu, configurația sistemului, informațiile de stare sau politicile nu sunt considerate secrete. Secretele au întotdeauna un contract de închiriere asociat.Acest lucru înseamnă că clienții nu pot presupune că conținutul secretului poate fi utilizat la nesfârșit. Vault va revoca un secret la sfârșitul contractului de închiriere, iar un operator poate interveni pentru a revoca secretul înainte ca acesta să se termine. Acestcontract dintre Vault și clienții săi este esențial, deoarece permite modificarea cheilor și a politicilor fără intervenție manuală.

• Server – Vault depinde de o instanță de lungă durată care funcționează ca server. Serverul Vault oferă un API cu care clienții interacționează șigestionează interacțiunea dintre toate motoarele de secrete, aplicarea ACL și revocarea contractelor de închiriere a secretelor. Faptul de a avea o arhitectură bazată pe server decuplează clienții de cheile și politicile de securitate, permite înregistrarea centralizată a auditului și simplifică administrarea pentru operatori.

„High-Level Overview

O vedere de ansamblu la nivel foarte înalt a Vault arată astfel:

Să începem să descompunem această imagine. Există o separare clară acomponentelor care se află în interiorul sau în afara barierei de securitate. Doar backend-ul de stocare și API-ul HTTP sunt în exterior, toate celelalte componente sunt în interiorul barierei.

Backend-ul de stocare nu este de încredere și este folosit pentru a stoca în mod durabil date criptate.Când serverul Vault este pornit, trebuie să i se furnizeze un backend de stocare pentru ca datele să fie disponibile la toate repornirile. În mod similar, API-ul HTTP trebuie să fie pornit de către serverul Vault la pornire, astfel încât clienții să poată interacționa cu acesta.

După ce este pornit, Vault se află într-o stare sigilată. Înainte ca orice operațiune să poată fi efectuată pe Vault, acesta trebuie desigilat. Acest lucru se face prin furnizarea cheilor de desigilare. Atunci când Seiful este inițializat, acesta generează o cheie de criptare care este utilizatăpentru a proteja toate datele. Această cheie este protejată de o cheie principală. În mod implicit, Vault utilizează o tehnică cunoscută sub numele de algoritmul de partajare a secretului lui Shamir pentru a împărți cheia principală în 5 părți, dintre care 3 sunt necesare pentru a reconstrui cheia principală.

Se pot specifica atât numărul de părți, cât și pragul minim necesar.Tehnica lui Shamir poate fi dezactivată, iar cheia principală poate fi utilizată direct pentru desigilare. Odată ce Vault recuperează cheia de criptare, este capabil să decripteze datele din backend-ul de stocare și intră în starea de desigilare. Odată desigilat, Vault încarcă toate dispozitivele de audit, metodele de autentificare și motoarele de secretizare configurate.

Configurarea acestor dispozitive de audit, metode de autentificare și motoare de secretizare trebuie să fie stocată în Vault, deoarece acestea sunt sensibile din punct de vedere al securității. Numai utilizatorii cu permisiunilecorecte trebuie să le poată modifica, ceea ce înseamnă că nu pot fi specificate în afara barierei. Prin stocarea lor în Vault, orice modificări ale acestorasunt protejate de sistemul ACL și urmărite de jurnalele de audit.

După ce Vault este desigilată, pot fi procesate cereri de la HTTP API laCore. Core este folosit pentru a gestiona fluxul de cereri prin sistem,pentru a aplica ACL-urile și pentru a se asigura că se face logarea de audit.

Când un client se conectează pentru prima dată la Vault, acesta trebuie să se autentifice. Vault oferă metode de autentificare configurabile care oferă flexibilitate în ceea ce privește mecanismul de autentificare utilizat. Mecanisme prietenoase pentru oameni, cum ar fi numele de utilizator/parola sau GitHub, pot fi utilizate pentru operatori, în timp ce aplicațiile pot utiliza chei publice/private sau token-uri pentruautentificare. O cerere de autentificare trece prin core și intră într-o metodă de autentificare, care determină dacă cererea este validă și returnează o listă de politici asociate.

Politicile sunt doar o regulă ACL numită. De exemplu, politica „root” este încorporatăși permite accesul la toate resursele. Puteți crea orice număr de politici numitecu control fin asupra căilor de acces. Vault funcționează exclusiv în modul listă albă, ceea ce înseamnă că, dacă accesul nu este acordat în mod explicit prin intermediul unei politici, acțiunea nu este permisă. Deoarece un utilizator poate avea asociate mai multe politici, o acțiune este permisă dacă orice politică o permite. Politicile sunt stocate și gestionate de un depozit intern de politici. Acest depozit intern este manipulat prin intermediul backend-ului sistemului, care este întotdeauna montat la sys/.

După ce are loc autentificarea ș i o metodă de autentificare furnizează un set de politici aplicabile, un nou token de client este generat ș i gestionat de depozitul de token-uri. Acest token de client este trimis înapoi la client și este folosit pentru a face cereri viitoare.Acest lucru este similar cu un cookie trimis de un site web după ce un utilizator se conectează. Tokenul de client poate avea un contract de închiriere asociat, în funcție de configurația metodei de autentificare. Acest lucru înseamnă că este posibil ca token-ul clientului să trebuiască să fie reînnoit periodic pentru a evita invalidarea.

După ce este autentificat, cererile sunt făcute furnizând token-ul clientului. Tokenul este utilizat pentru a verifica dacă clientul este autorizat și pentru a încărca politicile relevante. Politicile sunt folosite pentru a autoriza cererea clientului. Cererea este apoi direcționată către motorul de secrete, care este procesat în funcție de tipul său. În cazul în care motorul de secrete returnează un secret, nucleul îl înregistrează cu managerul de expirare și îi atașează un ID de închiriere. ID-ul de închiriere este utilizat de clienți pentru a-și reînnoi sau revoca secretul. Dacă un client permite expirarea contractului de închiriere, managerul de expirare revocă automat secretul.

Nucleul se ocupă de înregistrarea cererilor și răspunsurilor către brokerul de audit, care transmite cererea către toate dispozitivele de audit configurate. În afara fluxului de cereri, nucleul efectuează anumite activități de fond. Gestionarea contractelor de închiriere este esențială, deoarece permite revocarea automată a jetoanelor de client sau a secretelor expirate. În plus, Vault gestionează anumite cazuri de eșecuri parțiale prin utilizarea jurnalizării în avans cu un manager de revenire. Acest lucru este gestionat în mod transparent în cadrul nucleului și nu este vizibil pentru utilizator.

„Getting in Depth

Aceasta a fost o scurtă prezentare la nivel înalt a arhitecturii Vault. Sunt disponibile mai multe detalii pentru fiecare dintre subsisteme.

Pentru alte detalii, fie consultați codul, fie întrebați pe IRC sau contactați lista de corespondență.