“Architectuur

Vault is een complex systeem dat uit veel verschillende onderdelen bestaat. Om zowel gebruikers als ontwikkelaars van Vault te helpen een mentaal model op te bouwen van hoe het werkt, wordt op deze pagina de systeemarchitectuur gedocumenteerd.

Voordat we de architectuur beschrijven, geven we een verklarende woordenlijst van termen om te helpen verduidelijken wat er wordt besproken:

• Storage Backend – Een storage backend is verantwoordelijk voor de duurzame opslag van gecodeerde gegevens. Backends worden door Vault niet vertrouwd en worden alleen geacht duurzaamheid te bieden. De opslagbackend wordt geconfigureerd wanneer de Vaultserver wordt gestart.

• Barrière – De barrière bestaat uit cryptografisch staal en beton rond de Vault. Alle gegevens die tussen de Vault en het backend van de opslagruimte stromen, gaan door de barrière. De barrière zorgt ervoor dat alleen gecodeerde gegevens worden weggeschreven, en dat de gegevens worden geverifieerd en gedecodeerd op weg naar binnen. Net als bij een bankkluis moet de barrière worden geopend voordat toegang tot de gegevens kan worden verkregen.

• Secrets Engine – Een secrets engine is verantwoordelijk voor het beheer van secrets. Eenvoudige secrets engines, zoals de “kv”-secrets engine, retourneren eenvoudigweg hetzelfde geheim wanneer het wordt opgevraagd. Sommige secrets engines kunnen beleidsregels gebruiken om dynamisch een geheim te genereren telkens als ze worden opgevraagd. Hierdoor kunnen unieke secrets gebruikt worden, wat Vault in staat stelt om fijnkorrelige revocatie en beleidsupdates uit te voeren. Als voorbeeld kan een MySQL geheimenmachine met een “web” beleid worden geconfigureerd. Wanneer het “web”-geheim wordt gelezen, wordt een nieuw MySQL-gebruikerswachtwoordpaar gegenereerd met een beperkte set rechten voor de webserver.

• Audit-apparaat – Een audit-apparaat is verantwoordelijk voor het beheer van auditlogboeken. Elk verzoek aan Vault en elke reactie van Vault gaat via het configureer-auditapparaat. Dit biedt een eenvoudige manier om Vault te integreren met meerdere auditlogboekbestemmingen van verschillende typen.

• Authenticatiemethode – Een auth-methode wordt gebruikt om gebruikers of toepassingen te authenticeren die verbinding maken met Vault. Na verificatie geeft de auth-methode een lijst met beleidsregels die moeten worden toegepast. Vault neemt een geauthenticeerde gebruiker en geeft een client token terug dat voor toekomstige verzoeken kan worden gebruikt. Als voorbeeld, de userpass auth methode gebruikt een gebruikersnaam en wachtwoord om de gebruiker te authenticeren. Een andere mogelijkheid is de github auth-methode waarmee gebruikers zich kunnen authenticeren via GitHub.

• Clienttoken – Een clienttoken (ook wel “Vault Token” genoemd) is conceptueel vergelijkbaar met een sessiecookie op een website. Nadat een gebruiker zich heeft geverifieerd, stuurt Vault een client token terug dat wordt gebruikt voor toekomstige verzoeken. Het token wordt door Vault gebruikt om de identiteit van de cliënt te verifiëren en om het toepasselijke ACL-beleid af te dwingen. Dit token wordt via HTTP-headers doorgegeven.

• Secret – Een secret is de term voor alles wat door Vault wordt teruggezonden en vertrouwelijk of cryptografisch materiaal bevat. Niet alles wat door Vault wordt geretourneerd is een geheim, bijvoorbeeld systeemconfiguratie, statusinformatie of beleidsregels worden niet als geheim beschouwd. Geheimen hebben altijd een bijbehorende huurovereenkomst. Dit betekent dat cliënten er niet van uit kunnen gaan dat de inhoud van het geheim onbeperkt gebruikt kan worden. Vault trekt een geheim in aan het einde van de huurperiode, en een operator kan ingrijpen om het geheim in te trekken voordat de huurperiode voorbij is. Dit contract tussen Vault en zijn klanten is van cruciaal belang, omdat het wijzigingen in sleutels en beleidslijnen zonder handmatige tussenkomst mogelijk maakt.

• Server – Vault is afhankelijk van een langlopende instantie die als server fungeert. De Vault-server biedt een API waarmee klanten kunnen communiceren en beheert de interactie tussen alle secrets engines, de ACL-afdwinging en de intrekking van de geheimenlease. Een serverarchitectuur ontkoppelt clients van de beveiligingssleutels en het beleid, maakt gecentraliseerde auditlogging mogelijk en vereenvoudigt het beheer voor operators.

“Overzicht op hoog niveau

Een overzicht op zeer hoog niveau van Vault ziet er als volgt uit:

Laten we dit beeld eens uit elkaar halen. Er is een duidelijke scheiding tussen componenten die binnen of buiten de veiligheidsbarrière vallen. Alleen het opslagbackend en de HTTP API bevinden zich buiten de barrière, alle andere componenten bevinden zich binnen de barrière.

Het opslagbackend is niet vertrouwd en wordt gebruikt om gecodeerde gegevens duurzaam op te slaan. Wanneer de Vault-server wordt gestart, moet deze worden voorzien van een opslagbackend, zodat de gegevens ook na een herstart beschikbaar zijn. Ook de HTTP API moet bij het opstarten door de Vault server worden gestart, zodat cliënten ermee kunnen communiceren.

Eenmaal opgestart bevindt de Vault zich in een verzegelde toestand. Voordat een operatie op de Vault kan worden uitgevoerd, moet de verzegeling worden opgeheven. Dit wordt gedaan door de unsealkeys te verstrekken. Wanneer de kluis geïnitialiseerd wordt, wordt een encryptiesleutel gegenereerd die gebruikt wordt om alle gegevens te beschermen. Die sleutel wordt beschermd door een hoofdsleutel. Standaard gebruikt Vault een techniek die bekend staat als Shamir’s geheimdeelsleutel om de hoofdsleutel in 5 delen op te splitsen, waarvan er 3 nodig zijn om de hoofdsleutel te reconstrueren.

Het aantal delen en de minimumdrempel kunnen beide worden opgegeven. Shamir’s techniek kan worden uitgeschakeld, en de hoofdsleutel kan direct worden gebruikt voor het ontzegelen. Zodra Vault de versleutelingssleutel heeft verkregen, kan het de gegevens in het opslaggeheugen ontsleutelen en gaat het naar de onversleutelde toestand. Eenmaal ontsloten, laadt Vault alle geconfigureerde audit apparaten, auth methodes, en geheimen-engines.

De configuratie van deze audit apparaten, auth methodes, en geheimen-engines moeten in Vault worden opgeslagen omdat ze veiligheidsgevoelig zijn. Alleen gebruikers met de juiste permissies zouden in staat moeten zijn om ze te wijzigen, wat betekent dat ze niet buiten de barrière kunnen worden gespecificeerd. Door ze in Vault op te slaan, worden alle wijzigingen beschermd door het ACL systeem en bijgehouden door audit logs.

Nadat de Vault is ontsloten, kunnen verzoeken worden verwerkt van de HTTP API naar deCore. De core wordt gebruikt om de stroom van verzoeken door het systeem te beheren, ACL’s af te dwingen, en te zorgen voor audit logging.

Wanneer een client voor het eerst verbinding maakt met Vault, moet hij zich authentiseren. Vault biedt configureerbare authenticatiemethoden die flexibiliteit bieden in het gebruikte authenticatiemechanisme. Mensvriendelijke mechanismen zoals gebruikersnaam/wachtwoord of GitHub kunnen worden gebruikt voor operators, terwijl applicaties publieke/privésleutels of tokens kunnen gebruiken om te authenticeren. Een authenticatieverzoek stroomt door core en naar een authmethod, die bepaalt of het verzoek geldig is en een lijst met bijbehorende policies terugstuurt.

Policies zijn gewoon een benoemde ACL regel. Het “root” beleid is bijvoorbeeld ingebouwd en staat toegang tot alle bronnen toe. U kunt een willekeurig aantal benoemde beleidsregels maken met fijnkorrelige controle over paden. Vault werkt uitsluitend in een “whitelist” modus, wat betekent dat tenzij toegang expliciet wordt verleend via een policy, de actie niet is toegestaan. Aangezien aan een gebruiker meerdere beleidsregels kunnen zijn gekoppeld, wordt een actie toegestaan als een beleidsregel dit toestaat. De beleidsregels worden opgeslagen en beheerd in een interne beleidswinkel. Deze interne opslag wordt gemanipuleerd via het backend van het systeem, dat altijd is gemount op sys/.

Zodra authenticatie plaatsvindt en een auth-methode een set toepasbare beleidsregels levert, wordt een nieuw client token gegenereerd en beheerd door de token store. Dit clienttoken wordt teruggestuurd naar de client, en wordt gebruikt om toekomstige verzoeken te doen. Dit is vergelijkbaar met een cookie dat door een website wordt verzonden nadat een gebruiker zich heeft aangemeld. Aan het clienttoken kan een lease verbonden zijn, afhankelijk van de auth-methodeconfiguratie. Dit betekent dat het clienttoken periodiek moet worden vernieuwd om ongeldigmaking te voorkomen.

Eenmaal geauthenticeerd, worden verzoeken gedaan met het clienttoken. Het token wordt gebruikt om te verifiëren of de cliënt geautoriseerd is en om de relevante beleidsregels te laden. De beleidsregels worden gebruikt om het verzoek van de cliënt te autoriseren. Het verzoek wordt dan doorgestuurd naar de geheimen-engine, die afhankelijk van het type wordt verwerkt. Als de geheimen-engine een geheim terugstuurt, registreert de kern het bij de expiratiemanager en voegt er een lease-ID aan toe. De lease-ID wordt door cliënten gebruikt om hun geheim te vernieuwen of te herroepen. Als een cliënt de lease laat verlopen, trekt de expiratiemanager de secret automatisch in.

De core logt verzoeken en antwoorden naar de audit-broker, die het verzoek naar alle geconfigureerde audit-apparaten doorstuurt. Buiten de verzoekstroom, voert de kern bepaalde achtergrondactiviteiten uit. Lease management is kritisch, omdat hiermee verlopen client tokens of secrets automatisch kunnen worden ingetrokken. Bovendien behandelt Vault bepaalde gedeeltelijke mislukkingen door gebruik te maken van write ahead logging met een rollback manager. Dit wordt transparant beheerd binnen de core en is niet zichtbaar voor de gebruiker.

“Getting in Depth

Dit is een kort overzicht op hoog niveau van de architectuur van Vault. Er zijn meer details beschikbaar voor elk van de subsystemen.

Voor andere details, raadpleeg de code, vraag het in IRC of neem contact op met de mailing list.