Een inleiding tot Vault

1. Overzicht

In deze tutorial verkennen we Hashicorp's Vault - een populaire tool die wordt gebruikt om veilig gevoelige informatie in moderne applicatie-architecturen te beheren.

De belangrijkste onderwerpen die we zullen behandelen, zijn onder meer:

  • Welk probleem probeert Vault op te lossen?
  • Vault's architectuur en belangrijkste concepten
  • Opzetten van een eenvoudige testomgeving
  • Interactie met Vault met behulp van het opdrachtregelprogramma

2. Het probleem met gevoelige informatie

Laten we, voordat we ons verdiepen in Vault, proberen het probleem te begrijpen dat het probeert op te lossen: beheer van gevoelige informatie.

De meeste applicaties hebben toegang tot gevoelige gegevens nodig om correct te kunnen werken. Een e-commercetoepassing kan bijvoorbeeld ergens een gebruikersnaam / wachtwoord hebben geconfigureerd om verbinding te maken met zijn database. Het kan ook API-sleutels nodig hebben om te integreren met andere serviceproviders, zoals betalingsgateways, logistiek en andere zakelijke partners.

Databasereferenties en API-sleutels zijn enkele voorbeelden van gevoelige informatie die we nodig hebben om op een veilige manier op te slaan en beschikbaar te maken voor onze applicaties.

Een eenvoudige oplossing is om die inloggegevens op te slaan in een configuratiebestand en ze bij het opstarten te lezen. Het probleem met deze aanpak is echter duidelijk. Degene die toegang heeft tot dit bestand, deelt dezelfde databaserechten als onze applicatie - haar meestal volledige toegang geven tot alle opgeslagen gegevens.

We kunnen proberen het een beetje moeilijker te maken door die bestanden te versleutelen. Deze aanpak zal echter niet veel toevoegen in termen van algehele beveiliging. Vooral omdat onze applicatie toegang moet hebben tot de hoofdsleutel. Wanneer versleuteling op deze manier wordt gebruikt, zal alleen een "vals" gevoel van veiligheid worden bereikt.

Moderne applicaties en cloudomgevingen voegen vaak wat extra complexiteit toe: gedistribueerde services, meerdere databases, berichtensystemen enzovoort hebben allemaal gevoelige informatie overal een beetje verspreid, waardoor het risico op een inbreuk op de beveiliging toeneemt.

Dus, wat kunnen we doen? Laten we erop springen!

3. Wat is kluis?

Hashicorp Vault lost het probleem op van het beheren van gevoelige informatie - een geheim in Vault's taalgebruik. "Beheren" in deze context betekent dat Vault alle aspecten van gevoelige informatie beheert: het genereren, opslaan, gebruiken en niet in de laatste plaats de herroeping.

Hashicorp biedt twee versies van Vault. De open-source-versie die in dit artikel wordt gebruikt, is gratis te gebruiken, zelfs in commerciële omgevingen. Er is ook een betaalde versie beschikbaar, die technische ondersteuning bij verschillende SLA's en extra functies omvat, zoals ondersteuning voor HSM (Hardware Security Module).

3.1. Architectuur en belangrijkste kenmerken

De architectuur van Vault is bedrieglijk eenvoudig. De belangrijkste componenten zijn:

  • Een persistentie-backend - opslag voor alle geheimen
  • Een API-server die clientverzoeken afhandelt en bewerkingen uitvoert op geheimen
  • Een aantal geheime motoren, één voor elk type ondersteund geheim type

Door alle geheime afhandeling aan Vault te delegeren, kunnen we enkele beveiligingsproblemen oplossen:

  • Onze applicaties hoeven ze niet meer op te slaan - vraag het gewoon aan Vault wanneer dat nodig is en gooi het weg
  • We kunnen kortstondige geheimen gebruiken, waardoor de "window of opportunity" wordt beperkt waar een aanvaller een gestolen geheim kan gebruiken

Vault versleutelt alle gegevens met een coderingssleutel voordat ze naar de winkel worden geschreven. Deze coderingssleutel is gecodeerd met nog een andere sleutel - de hoofdsleutel, die alleen bij het opstarten wordt gebruikt.

Een belangrijk punt bij de implementatie van Vault is dat de hoofdsleutel niet op de server wordt opgeslagen. Dit betekent dat zelfs Vault na het opstarten geen toegang heeft tot de opgeslagen gegevens. Op dit punt wordt gezegd dat een Vault-instantie zich in een "verzegelde" staat bevindt.

Later zullen we de stappen doorlopen die nodig zijn om de hoofdsleutel te genereren en een Vault-instantie te ontzeggen.

Eenmaal ontzegeld, is Vault klaar om API-verzoeken te accepteren. Die verzoeken hebben natuurlijk authenticatie nodig, wat ons brengt bij hoe Vault clients authenticeert en beslist wat ze wel of niet kunnen doen.

3.2. Authenticatie

Om toegang te krijgen tot geheimen in Vault, moet een client zichzelf verifiëren met een van de ondersteunde methoden. De eenvoudigste methode maakt gebruik van tokens, die slechts tekenreeksen zijn die op elk API-verzoek worden verzonden met behulp van een speciale HTTP-header.

Bij de eerste installatie genereert Vault automatisch een "root-token". Dit token is het equivalent van root-superuser in Linux-systemen, dus het gebruik ervan moet tot een minimum worden beperkt. Als best practice zouden we deze root-token moeten gebruiken om andere tokens met minder privileges te maken en deze vervolgens in te trekken. Dit is echter geen probleem, aangezien we later een ander root-token kunnen genereren met behulp van unseal-sleutels.

Vault ondersteunt ook andere authenticatiemechanismen zoals onder andere LDAP, JWT, TLS-certificaten. Al deze mechanismen bouwen bovenop het basistokenmechanisme: zodra Vault onze client valideert, levert het een token dat we vervolgens kunnen gebruiken om toegang te krijgen tot andere API's.

Aan tokens zijn een aantal eigenschappen verbonden. De belangrijkste eigenschappen zijn:

  • Een set van bijbehorende Beleid (zie volgende sectie)
  • Tijd om te leven
  • Of het kan worden verlengd
  • Maximaal gebruik

Tenzij anders aangegeven, vormen tokens die door Vault zijn gemaakt een ouder-kindrelatie. Een child-token kan maximaal hetzelfde niveau van privileges hebben als de parent.

Het tegenovergestelde is niet waar: we kunnen - en meestal doen - een child-token maken met restrictief beleid. Een ander belangrijk punt over deze relatie: Wanneer we een token ongeldig maken, worden alle kindfiches en hun nakomelingen ook ongeldig.

3.3. Beleid

Beleidsregels bepalen precies tot welke geheimen een client toegang heeft en tot welke bewerkingen hij ermee kan werken. Laten we eens kijken hoe een eenvoudig beleid eruit ziet:

pad "geheim / boekhouding" {mogelijkheden = ["lezen"]}

Hier hebben we de HCL-syntaxis (Hashicorp's Configuration Language) gebruikt om ons beleid te definiëren. Vault ondersteunt ook JSON voor dit doel, maar we houden ons in onze voorbeelden aan HCL omdat het gemakkelijker te lezen is.

Beleid in Vault is 'standaard weigeren'. Een token dat aan dit voorbeeldbeleid is gekoppeld, krijgt toegang tot geheimen die zijn opgeslagen onder geheim / boekhouding en niets anders. Bij het maken van een token kan een token aan meerdere beleidsregels worden gekoppeld. Dit is erg handig omdat het ons in staat stelt kleinere beleidsregels te maken en te testen en deze vervolgens naar behoefte toe te passen.

Een ander belangrijk aspect van beleid is dat ze gebruikmaken van luie evaluatie. Dit betekent dat we een bepaald beleid kunnen bijwerken en dat alle tokens onmiddellijk worden beïnvloed.

Het beleid dat tot nu toe is beschreven, wordt ook wel Access Control List-beleid of ACL-beleid genoemd. Vault ondersteunt ook twee aanvullende beleidstypen: EGP- en RGP-beleid. Die zijn alleen beschikbaar in de betaalde versies en breiden de basisbeleidssyntaxis uit met Sentinel-ondersteuning.

Dit stelt ons in staat om, indien beschikbaar, in ons beleid rekening te houden met aanvullende kenmerken, zoals het tijdstip van de dag, meerdere authenticatiefactoren, de oorsprong van het clientnetwerk, enzovoort. We kunnen bijvoorbeeld een beleid definiëren dat toegang tot een bepaald geheim alleen tijdens kantooruren toestaat.

We kunnen meer details over de beleidssyntaxis vinden in de documentatie van Vault.

4. Geheime typen

Vault ondersteunt een reeks verschillende soorten geheimen die betrekking hebben op verschillende gebruikssituaties:

  • Sleutel waarde: eenvoudige statische sleutel / waardenparen
  • Dynamisch gegenereerde inloggegevens: gegenereerd door Vault op verzoek van een klant
  • Cryptografische sleutels: Wordt gebruikt om cryptografische functies uit te voeren met klantgegevens

Elk geheimtype wordt gedefinieerd door de volgende attributen:

  • EEN monterenpunt, die het REST API-voorvoegsel definieert
  • Een reeks bewerkingen die worden weergegeven via de bijbehorende API
  • Een set configuratieparameters

Een bepaald geheim exemplaar is toegankelijk via een pad, net als een mappenboom in een bestandssysteem. Het eerste onderdeel van dit pad komt overeen met de koppelpunt waar alle geheimen van dit type zich bevinden.

Bijvoorbeeld de string secret / mijn-applicatie komt overeen met het pad waaronder we sleutel-waardeparen kunnen vinden mijn aanvraag.

4.1. Sleutelwaardegeheimen

Sleutelwaardegeheimen zijn, zoals de naam al aangeeft, eenvoudige paren in de beschikbare onder een bepaald pad. We kunnen het paar bijvoorbeeld opslaan foo = bar onder het pad / secret / mijn-applicatie.

Later gebruiken we hetzelfde pad om hetzelfde paar of paren op te halen - meerdere paren kunnen onder hetzelfde pad worden opgeslagen.

Vault ondersteunt drie soorten sleutelwaardegeheimen:

  • Sleutelparen zonder versiebeheer, waar updates bestaande waarden vervangen
  • Versie met sleutelparen, die een configureerbaar aantal oude versies behouden
  • Cubbyhole, een speciaal type sleutelparen zonder versiebeheer waarvan de waarden binnen een bepaald bereik vallen toegangstoken (daarover later meer).

Sleutelwaardegeheimen zijn van nature statisch, dus er is geen concept van een bijbehorende vervaldatum die eraan is gekoppeld. Het belangrijkste gebruiksscenario voor dit soort geheimen is het opslaan van inloggegevens voor toegang tot externe systemen, zoals API-sleutels.

In dergelijke scenario's zijn het bijwerken van inloggegevens een semi-handmatig proces, waarbij meestal iemand nieuwe inloggegevens moet aanschaffen en de opdrachtregel of de gebruikersinterface van Vault moet gebruiken om de nieuwe waarden in te voeren.

4.2. Dynamisch gegenereerde geheimen

Dynamische geheimen worden on-the-fly gegenereerd door Vault wanneer daarom wordt gevraagd door een applicatie. Vault ondersteunt verschillende soorten dynamische geheimen, waaronder de volgende:

  • Database-inloggegevens
  • SSH-sleutelparen
  • X.509-certificaten
  • AWS-inloggegevens
  • Google Cloud-serviceaccounts
  • Active Directory-accounts

Al deze volgen hetzelfde gebruikspatroon. Eerst configureren we de geheime engine met de details die nodig zijn om verbinding te maken met de bijbehorende service. Vervolgens definiëren we een of meer rollen, die de feitelijke geheime creatie beschrijven.

Laten we de geheime database-engine als voorbeeld nemen. Ten eerste moeten we Vault configureren met alle details van de gebruikersdatabaseverbindingen, inclusief inloggegevens van een bestaande gebruiker met beheerdersrechten om nieuwe gebruikers aan te maken.

Vervolgens maken we een of meer rollen (Vault-rollen, geen databaserollen) met de feitelijke SQL-instructies die worden gebruikt om een ​​nieuwe gebruiker te maken. Die bevatten meestal niet alleen de instructie voor het aanmaken van de gebruiker, maar ook al het vereiste verlenen instructies die nodig zijn om toegang te krijgen tot schema-objecten (tabellen, views enzovoort).

Wanneer een klant toegang krijgt tot de bijbehorende API, zal Vault een nieuwe tijdelijke gebruiker in de database maken met behulp van de verstrekte instructies en de inloggegevens retourneren. De klant kan die referenties vervolgens gebruiken om toegang te krijgen tot de database gedurende de periode die wordt bepaald door het kenmerk 'time-to-live' van de aangevraagde rol.

Zodra een inloggegevens de vervaldatum hebben bereikt, trekt Vault automatisch alle rechten in die aan deze gebruiker zijn gekoppeld. Een klant kan Vault ook verzoeken om die inloggegevens te vernieuwen. Het vernieuwingsproces vindt alleen plaats als het wordt ondersteund door het specifieke databasestuurprogramma en is toegestaan ​​door het bijbehorende beleid.

4.3. Cryptografische sleutels

Geheime engines van dit type verwerken cryptografische functies zoals codering, decodering, ondertekening enzovoort. Al deze bewerkingen gebruiken cryptografische sleutels die intern door Vault worden gegenereerd en opgeslagen. Tenzij dit expliciet wordt verteld, zal Vault nooit een bepaalde cryptografische sleutel vrijgeven.

Met de bijbehorende API kunnen klanten Vault-gegevens in platte tekst verzenden en er een gecodeerde versie van ontvangen. Het omgekeerde is ook mogelijk: we kunnen versleutelde gegevens verzenden en de originele tekst terugkrijgen.

Momenteel is er slechts één motor van dit type: de Doorvoer motor. Deze engine ondersteunt populaire typen sleutels, zoals RSA en ECDSA, en ondersteunt ook Convergente versleuteling. Bij gebruik van deze modus resulteert een gegeven platte-tekstwaarde altijd in hetzelfde cyphertext-resultaat, een eigenschap die in sommige toepassingen erg handig is.

We kunnen deze modus bijvoorbeeld gebruiken om creditcardnummers in een transactielogtabel te versleutelen. Met convergente versleuteling zou elke keer dat we een nieuwe transactie invoegen, de versleutelde creditcardwaarde hetzelfde zijn, waardoor het gebruik van reguliere SQL-query's voor rapportage, zoeken enzovoort mogelijk wordt gemaakt.

5. Kluis instellen

In deze sectie zullen we een lokale testomgeving maken, zodat we de mogelijkheden van de kluis testen.

De implementatie van Vault is eenvoudig: download gewoon het pakket dat overeenkomt met ons besturingssysteem en extraheer het uitvoerbare bestand (gewelf of vault.exe op Windows) naar een map op ons PATH. Dit uitvoerbare bestand bevat de server en is ook de standaardclient. Er is ook een officiële Docker-afbeelding beschikbaar, maar we zullen deze hier niet behandelen.

Kluisondersteuning a ontwikkeling modus, wat prima is voor wat snel testen en wennen aan het opdrachtregelprogramma, maar het is veel te simplistisch voor echte gebruiksscenario's: alle gegevens gaan verloren bij het opnieuw opstarten en API-toegang gebruikt gewone HTTP.

In plaats daarvan gebruiken we bestandsgebaseerde permanente opslag en stellen we HTTPS in, zodat we enkele van de real-life configuratiedetails kunnen onderzoeken die een bron van problemen kunnen zijn.

5.1. Vault Server starten

Vault gebruikt een configuratiebestand in HCL- of JSON-indeling. Het volgende bestand definieert alle configuratie die nodig is om onze server te starten met behulp van een bestandsopslag en een zelfondertekend certificaat:

opslag "bestand" {path = "./vault-data"} luisteraar "tcp" {adres = "127.0.0.1:8200" tls_cert_file = "./src/test/vault-config/localhost.cert" tls_key_file = ". /src/test/vault-config/localhost.key "}

Laten we nu Vault starten. Open een opdrachtshell, ga naar de map met ons configuratiebestand en voer deze opdracht uit:

$ kluisserver -config ./vault-test.hcl

Vault wordt gestart en geeft enkele initialisatieberichten weer. Ze bevatten de versie, enkele configuratiegegevens en het adres waar de API beschikbaar is. Dat is alles - onze Vault-server is actief.

5.2. Vault-initialisatie

Onze Vault-server draait nu, maar aangezien dit de eerste keer is, moeten we deze initialiseren.

Laten we een nieuwe shell openen en de volgende opdrachten uitvoeren om dit te bereiken:

$ export VAULT_ADDR = // localhost: 8200 $ export VAULT_CACERT =. / src / test / vault-config / localhost.cert $ kluis operator init

Hier hebben we een aantal omgevingsvariabelen gedefinieerd, zodat we ze niet elke keer als parameters aan Vault hoeven door te geven:

  • VAULT_ADDR: basis-URI waar onze API-server verzoeken zal behandelen
  • VAULT_CACERT: Pad naar de openbare sleutel van het certificaat van onze server

In ons geval gebruiken we de VAULT_CACERT zodat we HTTPS kunnen gebruiken om toegang te krijgen tot de API van Vault. We hebben dit nodig omdat we zelfondertekende certificaten gebruiken. Dit zou niet nodig zijn voor productieomgevingen, waar we meestal toegang hebben tot CA-ondertekende certificaten.

Nadat we het bovenstaande commando hebben gegeven, zouden we een bericht als dit moeten zien:

Unseal Key 1: Unseal Key 2: Unseal Key 3: Unseal Key 4: Unseal Key 5: Initial Root Token: ... meer berichten weggelaten

De eerste vijf regels zijn de hoofdsleutel-shares die we later zullen gebruiken om de opslag van Vault te ontsluiten. Houd er rekening mee dat Vault alleen de hoofdsleutelaandelen weergeeft tijdens de initialisatie - en nooit meer.Let op en bewaar ze veilig, anders verliezen we de toegang tot onze geheimen wanneer de server opnieuw wordt opgestart!

Let ook op het root-token, aangezien we het later nodig zullen hebben. In tegenstelling tot ontzegelsleutels, root-tokens kunnen gemakkelijk op een later tijdstip worden gegenereerd, dus het is veilig om het te vernietigen zodra alle configuratietaken zijn voltooid. Aangezien we later opdrachten zullen geven waarvoor een authenticatietoken vereist is, laten we het root-token voorlopig opslaan in een omgevingsvariabele:

$ export VAULT_TOKEN = (Unix / Linux)

Laten we onze serverstatus bekijken nu we deze hebben geïnitialiseerd, met het volgende commando:

$ kluisstatus Sleutelwaarde --- ----- Type zegel shamir Verzegeld true Totaal aantal aandelen 5 Drempel 3 Voortgang ontzegeling 0/3 Ontzegeling Nonce n.v.t. Versie 0.10.4 HA ingeschakeld false

We kunnen zien dat Vault nog steeds is verzegeld. We kunnen ook de voortgang van het ontzegelen volgen: "0/3" betekent dat Vault drie shares nodig heeft, maar tot nu toe nog geen heeft gekregen. Laten we verder gaan en het onze aandelen bezorgen.

5.3. Vault Unseal

We ontsluiten nu Vault zodat we zijn geheime diensten kunnen gaan gebruiken. We moeten drie van de vijf belangrijkste aandelen verstrekken om het ontzegelingsproces te voltooien:

$ kluisoperator ontzeggen $ kluisoperator ontzeggen $ kluisoperator ontzegelen 

Na het uitgeven van elke opdrachtkluis wordt de voortgang van het ontzegelen afgedrukt, inclusief het aantal gedeelde mappen dat nodig is. Na het verzenden van de laatste sleutelaanduiding, zien we een bericht als dit:

Sleutelwaarde --- ----- Type zegel shamir Sealed false ... andere eigenschappen zijn weggelaten

De eigenschap "Sealed" is in dit geval "false", wat betekent dat Vault klaar is om opdrachten te accepteren.

6. Kluis testen

In deze sectie zullen we onze Vault-setup testen met behulp van twee van de ondersteunde geheime types: Sleutel / Waarde en Database. We zullen ook laten zien hoe u nieuwe tokens kunt maken met specifiek beleid dat eraan is gekoppeld.

6.1. Sleutel- / waardegeheimen gebruiken

Laten we eerst geheime sleutel-waarde-paren opslaan en ze teruglezen. Ervan uitgaande dat de opdrachtshell die wordt gebruikt om Vault te initialiseren nog steeds open is, gebruiken we de volgende opdracht om die paren op te slaan onder de geheim / nepbank pad:

$ kluis kv zet geheim / fakebank api_key = abc1234 api_secret = 1a2b3c4d

We kunnen die paren nu op elk moment herstellen met de volgende opdracht:

$ kluis kv get secret / fakebank ======= Data ======= Sleutelwaarde --- ----- api_key abc1234 api_secret 1a2b3c4d 

Deze eenvoudige test laat ons zien dat Vault naar behoren werkt. We kunnen nu enkele extra functionaliteiten testen.

6.2. Nieuwe tokens maken

Tot dusver hebben we het root-token gebruikt om onze verzoeken te verifiëren. Omdat een root-token is manier te krachtig, wordt het als een best practice beschouwd om tokens te gebruiken met minder privileges en een kortere time-to-live.

Laten we een nieuw token maken dat we net als het root-token kunnen gebruiken, maar na slechts een minuut vervalt:

$ kluis token create -ttl 1m Sleutelwaarde --- ----- token token_accessor token_duration 1m token_renewable true token_policies ["root"] identity_policies [] policies ["root"]

Laten we dit token testen en het gebruiken om de sleutel / waarde-paren te lezen die we eerder hebben gemaakt:

$ export VAULT_TOKEN = $ kluis kv krijg geheim / fakebank ======= Gegevens ======= Sleutelwaarde --- ----- api_key abc1234 api_secret 1a2b3c4d

Als we een minuut wachten en proberen deze opdracht opnieuw op te geven, krijgen we een foutmelding:

$ vault kv get secret / fakebank Fout bij maken van API-verzoek. URL: GET // localhost: 8200 / v1 / sys / internal / ui / mounts / secret / fakebank Code: 403. Fouten: * toestemming geweigerd

Het bericht geeft aan dat ons token niet langer geldig is, wat we hadden verwacht.

6.3. Beleid testen

Het voorbeeldtoken dat we in de vorige sectie hebben gemaakt, was van korte duur, maar nog steeds erg krachtig. Laten we nu beleid gebruiken om meer beperkte tokens te maken.

Laten we bijvoorbeeld een beleid definiëren dat alleen leestoegang tot het geheim / nepbank pad dat we eerder gebruikten:

$ cat> sample-policy.hcl <

Nu maken we een token met dit beleid met het volgende commando:

$ export VAULT_TOKEN = $ kluis token create -policy = fakebank-ro Sleutelwaarde --- ----- token token_accessor token_duration 768h token_renewable true token_policies ["default" "fakebank-ro"] identity_policies [] policies ["default" " fakebank-ro "]

Laten we, zoals we eerder hebben gedaan, onze geheime waarden lezen met behulp van dit token:

$ export VAULT_TOKEN = $ kluis kv krijg geheim / fakebank ======= Gegevens ======= Sleutelwaarde --- ----- api_key abc1234 api_secret 1a2b3c4d

Tot nu toe zo goed. We kunnen gegevens lezen, zoals verwacht. Laten we eens kijken wat er gebeurt als we proberen dit geheim bij te werken:

$ vault kv put secret / fakebank api_key = foo api_secret = bar Fout bij schrijven van gegevens naar secret / fakebank: fout bij het maken van API-verzoek. URL: PUT //127.0.0.1:8200/v1/secret/fakebank Code: 403. Fouten: * toestemming geweigerd

Aangezien ons beleid schrijven niet expliciet toestaat, retourneert Vault de statuscode 403 - Toegang geweigerd.

6.4. Dynamische databasereferenties gebruiken

Laten we, als ons laatste voorbeeld in dit artikel, de geheime database-engine van Vault gebruiken om dynamische referenties te maken. We gaan er hier van uit dat we een MySQL-server lokaal beschikbaar hebben en dat we er toegang toe hebben met "root" -rechten. We zullen ook een heel eenvoudig schema gebruiken dat uit een enkele tabel bestaat - account .

Het SQL-script dat is gebruikt om dit schema en de bevoegde gebruiker te maken, is hier beschikbaar.

Laten we nu Vault configureren om deze database te gebruiken. De geheime database-engine is niet standaard ingeschakeld, dus we moeten dit oplossen voordat we verder kunnen gaan:

$ kluisgeheimen inschakelen database Succes! De database-geheimen-engine ingeschakeld op: database /

We maken nu een bron voor databaseconfiguratie:

$ vault write database / config / mysql-fakebank \ plugin_name = mysql-legacy-database-plugin \ connection_url = "{{gebruikersnaam}}: {{wachtwoord}} @ tcp (127.0.0.1:3306) / fakebank" \ allow_roles = "*" \ gebruikersnaam = "fakebank-admin" \ wachtwoord = "Sup & rSecre7!"

Het padvoorvoegsel database / config is waar alle databaseconfiguraties moeten worden opgeslagen. We kiezen de naam mysql-fakebank zodat we gemakkelijk kunnen achterhalen naar welke database deze configuratie verwijst. Wat betreft de configuratiesleutels:

  • plugin_name: Bepaalt welke database-plug-in wordt gebruikt. De beschikbare namen van plug-ins worden beschreven in de documentatie van Vault
  • connection_url: Dit is een sjabloon die door de plug-in wordt gebruikt bij het verbinden met de database. Let op de tijdelijke aanduidingen voor de sjabloon {{gebruikersnaam}} en {{wachtwoord}}. Wanneer u verbinding maakt met de database, vervangt Vault die tijdelijke aanduidingen door werkelijke waarden
  • toegestane_rollen: Bepaal welke Vault-rollen (hierna besproken) deze configuratie kunnen gebruiken. In ons geval gebruiken we "*", dus het is beschikbaar voor alle rollen
  • gebruikersnaam wachtwoord: Dit is het account dat Vault zal gebruiken om databasebewerkingen uit te voeren, zoals het aanmaken van een nieuwe gebruiker en het intrekken van zijn privileges

Vault Database-rol instellen

De laatste configuratietaak is het maken van een Vault-databaserolresource die de SQL-opdrachten bevat die nodig zijn om een ​​gebruiker te maken. We kunnen zoveel rollen creëren als nodig is, in overeenstemming met onze beveiligingsvereisten.

Hier maken we een rol die alleen-lezen toegang verleent tot alle tabellen van het nepbank schema:

$ vault write database / rolls / fakebank-accounts-ro \ db_name = mysql-fakebank \ creation_statements = "CREATE USER '{{name}}' @ '%' IDENTIFIED BY '{{password}}'; VERLENG SELECTEER OP fakebank. * Benoemen}}'@'%';" 

De database-engine definieert het padvoorvoegsel database / rollen als de locatie om rollen op te slaan. fakebank-accounts-ro is de rolnaam die we later zullen gebruiken bij het maken van dynamische referenties. We leveren ook de volgende sleutels:

  • db_name: Naam van een bestaande databaseconfiguratie. Komt overeen met het laatste deel van het pad dat we hebben gebruikt bij het maken van de configuratieresource
  • creation_statements: Een lijst met SQL-instructiesjablonen die Vault zal gebruiken om een ​​nieuwe gebruiker te maken

Dynamische referenties maken

Zodra we een databaserol en de bijbehorende configuratie gereed hebben, genereren we nieuwe dynamische referenties met de volgende opdracht:

$ kluis lees database / creds / fakebank-accounts-ro Sleutelwaarde --- ----- lease_id database / creds / fakebank-accounts-ro / 0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 lease_duration 1h lease_renewable echt wachtwoord gebruikersnaam 

De database / creds prefix wordt gebruikt om inloggegevens voor de beschikbare rollen te genereren. Omdat we de fakebank-accounts-ro rol, wordt de geretourneerde gebruikersnaam / wachtwoord beperkt tot selecteer operaties.

We kunnen dit verifiëren door verbinding te maken met de database met behulp van de opgegeven inloggegevens en vervolgens enkele SQL-opdrachten uit te voeren:

$ mysql -h 127.0.0.1 -u -p fakebank Voer wachtwoord in: MySQL [fakebank]> selecteer * uit account; ... kortheidshalve weggelaten 2 rijen in set (0.00 sec) MySQL [fakebank]> verwijderen uit account; ERROR 1142 (42000): DELETE-opdracht geweigerd aan gebruiker 'v-fake-9xoSKPkj1' @ 'localhost' voor tabel 'account' 

We kunnen zien dat de eerste selecteer succesvol voltooid, maar we konden het verwijderen uitspraak. Als we ten slotte een uur wachten en proberen verbinding te maken met dezelfde inloggegevens, kunnen we geen verbinding meer maken met de database. Vault heeft automatisch alle rechten van deze gebruiker ingetrokken

7. Conclusie

In dit artikel hebben we de basisprincipes van Hashicorp's Vault verkend, inclusief wat achtergrondinformatie over het probleem dat het probeert aan te pakken, de architectuur en het basisgebruik.

Gaandeweg hebben we een eenvoudige maar functionele testomgeving gecreëerd die we gaan gebruiken in vervolgartikelen.

Het volgende artikel behandelt een zeer specifieke use-case voor Vault: Gebruik het in de context van de Spring Boot-applicatie. Blijf kijken!


$config[zx-auto] not found$config[zx-overlay] not found