“Arkitektur

Vault er et komplekst system, der består af mange forskellige dele. For at hjælpe både brugere og udviklere af Vault med at opbygge en mental model af, hvordan det fungerer, dokumenterer denne side systemets arkitektur.

Hvor vi beskriver arkitekturen, giver vi en ordliste med begreber for at hjælpe med at præcisere, hvad der diskuteres:

• Storage Backend – En storage backend er ansvarlig for varig opbevaring af krypterede data. Vault har ikke tillid til backends, og det forventes kun, at de kan levere holdbarhed. Lagringsbackend’en konfigureres, når Vaultserveren startes.

• Barriere – Barrieren er kryptografisk stål og beton omkring Vaultserveren. Alle data, der flyder mellem Vault og storage backend’en, passerer gennem barrieren. Barrieren sikrer, at kun krypterede data skrives ud, og at dataene verificeres og dekrypteres på vejen ind. Ligesom i en bankboks skal barrieren “opløses”, før der er adgang til noget indeni.

• Secrets Engine – En secrets engine er ansvarlig for at administrere secrets.Simple secrets engines som “kv” secrets engine returnerer simpelthen den samme secret, når den bliver spurgt. Nogle hemmelige motorer understøtter brugen af politikker til dynamisk at generere en hemmelighed, hver gang der spørges efter den. Dette giver mulighed for at anvende unikke hemmeligheder, hvilket gør det muligt for Vault at foretage finkornede tilbagekaldelser og politikopdateringer. Som et eksempel kan en MySQL secrets engine konfigureres med en “web”-politik. Når “web”-hemmeligheden læses, genereres et nyt MySQL-bruger/adgangskodepar med et begrænset sæt rettigheder til webserveren.

• Audit-enhed – En audit-enhed er ansvarlig for at administrere audit-logfiler.Hver anmodning til Vault og svar fra Vault går gennem configuredaudit-enhederne. Dette giver en enkel måde at integrere Vault med flere auditlogningsdestinationer af forskellige typer.

• Auth-metode – En auth-metode bruges til at autentificere brugere eller programmer, der opretter forbindelse til Vault. Når den er autentificeret, returnerer auth-metoden listen over gældende politikker, som skal anvendes. Vault tager en autentificeret bruger og returnerer et klienttoken, som kan bruges til fremtidige forespørgsler. Eksempelvis bruger userpass auth-metoden et brugernavn og en adgangskode til at autentificere brugeren. Alternativt giver github auth-metoden brugerne mulighed for at autentificere via GitHub.

• Klienttoken – Et klienttoken (også kendt som “Vault-token”) ligner konceptuelt en session cookie på et websted. Når en bruger autentificerer sig, returnerer Vaul en klienttoken, som bruges til fremtidige anmodninger. Tokenet bruges af Vault til at verificere klientens identitet og til at håndhæve de gældende ACL-politikker. Tokenet sendes via HTTP-headers.

• Secret – En secret er betegnelsen for alt, der returneres af Vault, og som indeholder fortroligt eller kryptografisk materiale. Det er ikke alt, der returneres af Vault, der er en hemmelighed, f.eks. betragtes systemkonfiguration, statusoplysninger eller politikker ikke som hemmeligheder. Hemmeligheder har altid en tilknyttet lejekontrakt, hvilket betyder, at klienter ikke kan antage, at det hemmelige indhold kan bruges i det uendelige. Vault tilbagekalder en hemmelighed ved udløbet af lejekontrakten, og en operatør kan gribe ind for at tilbagekalde hemmeligheden, før lejekontrakten er udløbet. Denne kontrakt mellem Vault og dens klienter er kritisk, da den giver mulighed for ændringer i nøgler og politikker uden manuel indgriben.

• Server – Vault er afhængig af en langtidskørende instans, der fungerer som server. Vault-serveren leverer et API, som klienterne interagerer med, og den styrer interaktionen mellem alle hemmelighederne, ACL-håndhævelse og tilbagekaldelse af hemmelige lejemål. En serverbaseret arkitektur afkobler klienterne fra sikkerhedsnøgler og politikker, muliggør centraliseret revisionslogning og forenkler administrationen for operatørerne.

“Oversigt på højt niveau

En oversigt på meget højt niveau over Vault ser således ud:

Lad os begynde at opdele dette billede. Der er en klar adskillelse af komponenter, der befinder sig inden for eller uden for sikkerhedsbarrieren. Kun storage backend og HTTP API’et er udenfor, alle andre komponenter er inden for barrieren.

Storage backend’et er ikke betroet og bruges til at lagre krypterede data varigt.Når Vault-serveren startes, skal den forsynes med en storage backend, så data er tilgængelige på tværs af genstarter. HTTP API’et skal ligeledes startes af Vault-serveren ved start, så klienter kan interagere med det.

Når Vault er startet, er den i en forseglet tilstand. Før der kan udføres en operation på boksen, skal den være åbnet. Dette gøres ved at levere unsealkeys. Når boksen initialiseres, genererer den en krypteringsnøgle, som bruges til at beskytte alle data. Denne nøgle er beskyttet af en hovednøgle. Som standard anvender Vault en teknik, der er kendt som Shamirs hemmelighedsdelingsalgoritme, til at opdele hovednøglen i 5 andele, hvoraf 3 er nødvendige for at rekonstruere hovednøglen.

Antallet af andele og den krævede minimumstærskel kan begge specificeres.Shamirs teknik kan deaktiveres, og hovednøglen kan anvendes direkte til at aflukke forseglingen. Når Vault har hentet krypteringsnøglen, er den i stand til at dekryptere dataene i storage backend’en og går ind i den useglede tilstand. Når den er blevet åbnet, indlæser Vault alle de konfigurerede audit-enheder, auth-metoder og secretsengines.

Konfigurationen af disse audit-enheder, auth-metoder og secretsengines skal gemmes i Vault, da de er sikkerhedsfølsomme. Kun brugere med de korrekte tilladelser bør kunne ændre dem, hvilket betyder, at de ikke kan specificeres uden for barrieren. Ved at gemme dem i Vault er enhver ændring af dem beskyttet af ACL-systemet og kan spores af auditlogfiler.

Når Vault er åbnet, kan anmodninger behandles fra HTTP API’et til kernen. Kernen bruges til at styre strømmen af anmodninger gennem systemet,håndhæve ACL’er og sikre, at der foretages auditlogning.

Når en klient første gang opretter forbindelse til Vault, skal den autentificeres. Vault tilbyder konfigurerbare auth-metoder, der giver fleksibilitet i den anvendte autentifikationsmekanisme. Menneskevenlige mekanismer som brugernavn/password eller GitHub kan bruges til operatører, mens applikationer kan bruge offentlige/private nøgler eller tokens til at autentificere. En autentifikationsanmodning strømmer gennem core og ind i en authmetode, som afgør, om anmodningen er gyldig, og returnerer en liste over tilknyttede politikker.

Politikker er blot en navngiven ACL-regel. F.eks. er politikken “root” indbygget og tillader adgang til alle ressourcer. Du kan oprette et vilkårligt antal navngivne politikker med finkornet kontrol over stier. Vault opererer udelukkende i en whitelisttilstand, hvilket betyder, at medmindre der udtrykkeligt er givet adgang via en politik, er handlingen ikke tilladt. Da en bruger kan have flere politikker tilknyttet, er en handling tilladt, hvis nogen politik tillader den. Politikker lagres og administreres af et internt politiklager. Dette interne lager manipuleres via systemets backend, som altid er monteret på sys/.

Når autentificering finder sted, og en auth-metode giver et sæt gældende politikker, genereres et nyt klienttoken, som forvaltes af token-lageret. Dette klienttoken sendes tilbage til klienten og bruges til at foretage fremtidige anmodninger.Dette svarer til en cookie, der sendes af et websted, når en bruger logger ind. Klienttokenet kan have en lejekontrakt tilknyttet, afhængigt af konfigurationen af auth-metoden. Det betyder, at klienttokenet kan være nødvendigt at forny det med jævne mellemrum for at undgå ugyldighed.

Når det er autentificeret, foretages anmodninger med klienttokenet. Tokenet bruges til at verificere, at klienten er autoriseret, og til at indlæse de relevante politikker. Politikkerne bruges til at godkende klientens anmodning. Anmodningen videresendes derefter til secrets engine, som behandles afhængigt af dens type. Hvis secretsengine returnerer en hemmelighed, registrerer kernen den hos expiration manager og tilknytter et lease-id. Lease-ID’et bruges af klienterne til at forny eller tilbagekalde deres hemmelighed. Hvis en klient lader lejemålet udløbe, tilbagekalder udløbshåndteringen automatisk hemmeligheden.

Kernen håndterer logning af anmodninger og svar til revisionsmægleren, som sender anmodningen ud til alle de konfigurerede revisionsenheder. Uden for forespørgselsflowet udfører kernen visse baggrundsaktiviteter. Lease management er kritisk, da det gør det muligt at tilbagekalde udløbne klienttokens eller hemmeligheder automatisk. Desuden håndterer Vault visse tilfælde af delvise fejl ved at anvende write ahead logging med en rollback manager. Dette forvaltes gennemsigtigt inden for kernen og er ikke synligt for brugeren.

“Getting in Depth

Dette har været en kort oversigt på højt niveau over arkitekturen i Vault. Der findes flere detaljer for hvert af undersystemerne.

For andre detaljer skal du enten konsultere koden, spørge i IRC eller henvende dig til mailinglisten.