”Arkitektur

Vault är ett komplext system som består av många olika delar. För att hjälpa både användare och utvecklare av Vault att bygga upp en mental modell av hur det fungerar, dokumenterar den här sidan systemarkitekturen.

För att beskriva arkitekturen ger vi en ordlista med termer för att hjälpa till att förtydliga vad som diskuteras:

• Storage Backend – En storage backend är ansvarig för varaktig lagring avkrypterade data. Vault litar inte på baksidorna och förväntar sig endast att de ska tillhandahålla hållbarhet. Lagringsbackend konfigureras när Vaultservern startas.

• Barriär – Barriären består av kryptografiskt stål och betong runt Vault. Alla data som flödar mellan Vault och lagringsbackend passerar genom barriären. Barriären säkerställer att endast krypterade data skrivs ut och att data verifieras och dekrypteras på vägen in. Precis som i en bankvault måste barriären ”öppnas” innan något inuti kan nås.

• Secrets Engine – En secrets engine är ansvarig för hanteringen av secrets.Enkla secrets engines som ”kv” secrets engine returnerar helt enkelt samma secret vid förfrågan. Vissa hemlighetsmotorer har stöd för att använda principer för att dynamiskt generera en hemlighet varje gång de frågas ut. Detta gör det möjligt att använda unika hemligheter, vilket gör det möjligt för Vault att göra finkorniga återkallelser och uppdateringar av policyer. Som exempel kan en MySQL-hemlighetsmotor konfigureras med en ”web”-policy. När ”web”-hemligheten läses genereras ett nytt MySQL-användare/lösenordspar med en begränsad uppsättning privilegier för webbservern.

• Audit-enhet – En audit-enhet ansvarar för hanteringen av audit-loggar.Varje begäran till Vault och svar från Vault går genom configuredaudit-enheterna. Detta ger ett enkelt sätt att integrera Vault med flera auditloggningsdestinationer av olika typer.

• Auth Method – En auth-metod används för att autentisera användare eller program som ansluter till Vault. När auth-metoden har autentiserats returnerar den listan över tillämpliga principer som ska tillämpas. Vault tar emot en autentiserad användare och returnerar en klienttoken som kan användas för framtida förfrågningar. Exempelvis använder auth-metoden userpass ett användarnamn och ett lösenord för att autentisera användaren. Alternativt tillåter github auth-metoden användare att autentisera sig via GitHub.

• Klienttoken – En klienttoken (även kallad ”Vault Token”) liknar konceptuellt en sessionscookie på en webbplats. När en användare har autentiserat sig returnerar Vaul en klienttoken som används för framtida förfrågningar. Token används av Vault för att verifiera klientens identitet och för att tillämpa de tillämpliga ACL-policyerna. Denna token skickas via HTTP-rubriker.

• Secret – En hemlighet är termen för allt som returneras av Vault och som innehåller konfidentiellt eller kryptografiskt material. Allt som returneras av Vault är inte en hemlighet, till exempel systemkonfiguration, statusinformation eller policyer betraktas inte som hemligheter. Hemligheter har alltid ett tillhörande hyresavtal, vilket innebär att klienterna inte kan anta att det hemliga innehållet kan användas i all oändlighet. Vault återkallar en hemlighet i slutet av hyresperioden, och en operatör kan ingripa för att återkalla hemligheten innan hyresperioden är slut. Detta avtal mellan Vault och dess klienter är kritiskt, eftersom det gör det möjligt att ändra nycklar och policyer utan manuellt ingripande.

• Server – Vault är beroende av en långvarig instans som fungerar som server. Vault-servern tillhandahåller ett API som klienterna interagerar med och hanterar interaktionen mellan alla hemlighetsmotorer, ACL-tillämpning och återkallande av hemlighetsavtal. Att ha en serverbaserad arkitektur frikopplar klienterna från säkerhetsnycklar och policyer, möjliggör centraliserad granskningsloggning och förenklar administrationen för operatörerna.

”Översikt på hög nivå

En översikt på hög nivå över Vault ser ut så här:

Låt oss börja bryta ner denna bild. Det finns en tydlig uppdelning av komponenter som befinner sig innanför eller utanför säkerhetsbarriären. Endast lagringsbackend och HTTP API är utanför, alla andra komponenter är innanför barriären.

Lagringsbackend är opålitlig och används för att lagra krypterade data på ett varaktigt sätt.När Vault-servern startas måste den förses med en lagringsbackend för att data ska vara tillgängliga vid omstarter. HTTP API:et måste också startas av Vault-servern vid start så att klienter kan interagera med det.

När Vault väl har startats befinner sig Vault i ett förseglat tillstånd. Innan någon operation kan utföras på valvet måste det avförseglas. Detta görs genom att tillhandahålla unsealkeys. När valvet initieras genererar det en krypteringsnyckel som används för att skydda alla data. Denna nyckel skyddas av en huvudnyckel. Som standard använder Vault en teknik som kallas Shamir’s secret sharingalgoritm för att dela upp huvudnyckeln i 5 andelar, varav 3 av dessa krävs för att rekonstruera huvudnyckeln.

Antalet andelar och det minsta tröskelvärde som krävs kan båda specificeras.Shamir’s teknik kan inaktiveras och huvudnyckeln kan användas direkt för att avtäcka. När Vault har hämtat krypteringsnyckeln kan den avkryptera data i lagringsutrymmet och går in i det oseglade tillståndet. När det är öppnat laddar Vault alla konfigurerade granskningsenheter, auth-metoder och secretsengines.

Konfigurationen av dessa granskningsenheter, auth-metoder och secretsengines måste lagras i Vault eftersom de är säkerhetskänsliga. Endast användare med rätt behörigheter bör kunna ändra dem, vilket innebär att de inte kan specificeras utanför barriären. Genom att lagra dem i Vault skyddas alla ändringar av ACL-systemet och spåras med hjälp av granskningsloggar.

När Vault har öppnats kan förfrågningar behandlas från HTTP API:et till Core. Kärnan används för att hantera flödet av förfrågningar genom systemet, upprätthålla ACL:er och se till att granskningsloggning sker.

När en klient först ansluter till Vault måste den autentisera. Vault tillhandahåller konfigurerbara autentiseringsmetoder som ger flexibilitet när det gäller den autentiseringsmekanism som används. Människovänliga mekanismer som användarnamn/lösenord eller GitHub kan användas för operatörer, medan program kan använda offentliga/privata nycklar eller tokens för autentisering. En autentiseringsbegäran går genom core och in i en authmetod, som avgör om begäran är giltig och returnerar en lista över associerade policyer.

Policyer är bara en namngiven ACL-regel. Till exempel är principen ”root” inbyggd och tillåter åtkomst till alla resurser. Du kan skapa valfritt antal namngivna principer med finkornig kontroll över sökvägar. Vault arbetar uteslutande i ett whitelistläge, vilket innebär att om inte åtkomst uttryckligen beviljas via en policy är åtgärden inte tillåten. Eftersom en användare kan ha flera principer associerade är en åtgärd tillåten om någon princip tillåter den. Policyer lagras och hanteras av ett internt policyarkiv. Detta interna arkiv manipuleras genom systemets backend, som alltid är monterad på sys/.

När autentisering har ägt rum och en autentiseringsmetod tillhandahåller en uppsättning tillämpliga policyer genereras en ny klienttoken som hanteras av token-lagret. Denna klienttoken skickas tillbaka till klienten och används för att göra framtida förfrågningar.Detta liknar en cookie som skickas av en webbplats efter att en användare har loggat in. Klienttoken kan ha ett hyresavtal kopplat till sig beroende på konfigurationen av auth-metoden. Detta innebär att klienttoken kan behöva förnyas regelbundet för att undvika att den blir ogiltig.

När den är autentiserad görs förfrågningar med klienttoken. Tokenet används för att verifiera att klienten är auktoriserad och för att ladda relevanta policyer. Policierna används för att godkänna klientens begäran. Förfrågan skickas sedan till secrets-motorn, som behandlas beroende på typ. Om secretsengine returnerar en hemlighet registrerar kärnan den hos expirationshanteraren och bifogar ett leasing-ID. Klienterna använder leasing-ID:t för att förnya eller återkalla sin hemlighet. Om en klient låter hyresavtalet löpa ut, återkallar expirationshanteraren automatiskt hemligheten.

Kärnan hanterar loggning av förfrågningar och svar till audit broker, som skickar ut förfrågningen till alla konfigurerade audit-enheter. Utanför förfrågningsflödet utför kärnan viss bakgrundsaktivitet. Hanteringen av leasingavtal är kritisk, eftersom den gör det möjligt att automatiskt återkalla utgångna klienttokens eller hemligheter. Dessutom hanterar Vault vissa fall av partiella misslyckanden genom att använda loggning med skrivning framåt med en rollback-hanterare. Detta hanteras transparent inom kärnan och är inte synligt för användaren.

”Getting in Depth

Detta har varit en kort översikt på hög nivå över arkitekturen i Vault. Det finns mer detaljer för vart och ett av delsystemen.

För andra detaljer kan du antingen konsultera koden, fråga på IRC eller kontakta e-postlistan.