streamalism.org

1. Oversigt

I denne vejledning udforsker vi Hashicorps Vault - et populært værktøj, der bruges til sikker håndtering af følsomme oplysninger i moderne applikationsarkitekturer.

De vigtigste emner, vi dækker, inkluderer:

• Hvilket problem forsøger Vault at løse
• Vault's arkitektur og hovedkoncepter
• Opsætning af et simpelt testmiljø
• Interaktion med Vault ved hjælp af kommandolinjeværktøjet

2. Problemet med følsom information

Inden vi graver i Vault, lad os prøve at forstå det problem, det forsøger at løse: følsom informationsstyring.

De fleste applikationer har brug for adgang til følsomme data for at kunne fungere korrekt. For eksempel kan en e-handelsapplikation have et brugernavn / adgangskode konfigureret et eller andet sted for at oprette forbindelse til sin database. Det kan også have brug for API-nøgler for at integrere med andre tjenesteudbydere, såsom betalingsgateways, logistik og andre forretningspartnere.

Databaseoplysninger og API-nøgler er nogle eksempler på følsomme oplysninger, som vi har brug for at gemme og gøre tilgængelige for vores applikationer på en sikker måde.

En simpel løsning er at gemme disse legitimationsoplysninger i en konfigurationsfil og læse dem ved opstartstidspunktet. Problemet med denne tilgang er dog åbenlyst. Den, der har adgang til denne fil, har de samme databaseprivilegier, som vores ansøgning har - normalt giver hende fuld adgang til alle lagrede data.

Vi kan prøve at gøre tingene lidt sværere ved at kryptere disse filer. Denne tilgang vil dog ikke tilføje meget med hensyn til den samlede sikkerhed. Hovedsageligt fordi vores applikation skal have adgang til masternøglen. Når kryptering bruges på denne måde, opnås kun en "falsk" følelse af sikkerhed.

Moderne applikationer og skymiljøer har en tendens til at tilføje noget ekstra kompleksitet: distribuerede tjenester, flere databaser, messaging-systemer og så videre har alle følsomme oplysninger spredt lidt overalt, hvilket øger risikoen for et sikkerhedsbrud.

Så hvad kan vi gøre? Lad os hvælve det!

3. Hvad er hvælving?

Hashicorp Vault løser problemet med styring af følsomme oplysninger - a hemmelighed i Vault's sprog. "Styring" i denne sammenhæng betyder, at Vault kontrollerer alle aspekter af et følsomt stykke information: dets generation, opbevaring, brug og sidst men ikke mindst tilbagekaldelse.

Hashicorp tilbyder to versioner af Vault. Open source-versionen, der bruges i denne artikel, er gratis at bruge, selv i kommercielle miljøer. En betalt version er også tilgængelig, som inkluderer teknisk support på forskellige SLA'er og yderligere funktioner, såsom HSM (Hardware Security Module) support.

3.1. Arkitektur og nøglefunktioner

Vault's arkitektur er bedragerisk enkel. Dets hovedkomponenter er:

• En vedholdende backend - opbevaring af alle hemmeligheder
• En API-server, der håndterer klientanmodninger og udfører operationer på hemmeligheder
• Et nummer af hemmelige motorer, en for hver type understøttet hemmelig type

Ved at delegere al hemmelig håndtering til Vault kan vi afbøde nogle sikkerhedsproblemer:

• Vores applikationer behøver ikke at gemme dem mere - bare spørg Vault, når det er nødvendigt, og kassér det
• Vi kan bruge kortvarige hemmeligheder og dermed begrænse ”mulighedsvinduet”, hvor en angriber kan bruge en stjålet hemmelighed

Vault krypterer alle data med en krypteringsnøgle, før de skrives til butikken. Denne krypteringsnøgle krypteres af endnu en nøgle - hovednøglen, der kun bruges ved opstart.

Et nøglepunkt i Vault's implementering er, at det ikke gemmer masternøglen på serveren. Dette betyder, at ikke engang Vault kan få adgang til sine gemte data efter opstart. På dette tidspunkt siges en Vault-forekomst at være i en "forseglet" tilstand.

Senere gennemgår vi de nødvendige trin for at generere masternøglen og fjerne forsegling af en Vault-forekomst.

Når den ikke er forseglet, er Vault klar til at acceptere API-anmodninger. Disse anmodninger har selvfølgelig brug for godkendelse, hvilket bringer os til, hvordan Vault godkender klienter og beslutter, hvad de kan eller ikke kan gøre.

3.2. Godkendelse

For at få adgang til hemmeligheder i Vault skal en klient godkende sig selv ved hjælp af en af ​​de understøttede metoder. Den enkleste metode bruger tokens, som bare er strenge, der sendes på hver API-anmodning ved hjælp af en speciel HTTP-header.

Når den oprindeligt blev installeret, genererer Vault automatisk et "rodtoken". Dette token svarer til root-superbruger i Linux-systemer, så dets anvendelse bør begrænses til et minimum. Som en bedste praksis skal vi bruge dette rodtoken bare for at oprette andre tokens med færre privilegier og derefter tilbagekalde det. Dette er dog ikke et problem, da vi senere kan generere et andet rodtoken ved hjælp af unseal-nøgler.

Vault understøtter også andre godkendelsesmekanismer, såsom LDAP, JWT, TLS-certifikater, blandt andre. Alle disse mekanismer bygger oven på den grundlæggende token-mekanisme: når Vault validerer vores klient, vil det give et token, som vi derefter kan bruge til at få adgang til andre API'er.

Tokens har et par egenskaber forbundet med dem. De vigtigste egenskaber er:

• Et sæt tilknyttet Politikker (se næste afsnit)
• Time-to-live
• Om det kan fornyes
• Maksimalt antal forbrug

Medmindre andet er fortalt, udgør tokens oprettet af Vault et forhold mellem forældre og børn. Et barn-token kan højst have det samme niveau af privilegier, som det forælder har.

Det modsatte er ikke sandt: vi kan - og normalt gør - oprette et barnetoken med restriktive politikker. Et andet centralt punkt om dette forhold: Når vi annullerer et token, ugyldiggøres også alle underordnede tokens og deres efterkommere.

3.3. Politikker

Politikker definerer nøjagtigt, hvilke hemmeligheder en klient kan få adgang til, og hvilke operationer den kan udføre med dem. Lad os se, hvordan en simpel politik ser ud:

sti "hemmelig / regnskabsmæssig" {skills = ["read"]}

Her har vi brugt syntaksen HCL (Hashicorps Configuration Language) til at definere vores politik. Vault understøtter også JSON til dette formål, men vi holder os til HCL i vores eksempler, da det er lettere at læse.

Politikker i Arkiv er "benægt som standard". Et token, der er knyttet til denne eksempelpolitik, får adgang til hemmeligheder, der er gemt under hemmelighed / regnskab og intet andet. På oprettelsestidspunktet kan et token knyttes til flere politikker. Dette er meget nyttigt, fordi det giver os mulighed for at oprette og teste mindre politikker og derefter anvende dem efter behov.

Et andet vigtigt aspekt af politikker er, at de udnytter doven evaluering. Dette betyder, at vi kan opdatere en given politik, og alle tokens vil blive påvirket med det samme.

De hidtil beskrevne politikker kaldes også adgangskontrollistepolitikker eller ACL-politikker. Vault understøtter også to yderligere politiktyper: EGP og RGP-politikker. Disse er kun tilgængelige i de betalte versioner og udvider den grundlæggende politiske syntaks med Sentinel-support.

Når det er tilgængeligt, giver dette os mulighed for i vores politikker at tage højde for yderligere attributter såsom tidspunkt på dagen, flere godkendelsesfaktorer, klientens netværksoprindelse osv. For eksempel kan vi definere en politik, der kun giver adgang til en given hemmelighed i åbningstiden.

Vi kan finde flere detaljer om politiksyntaksen i Vault's dokumentation.

4. Hemmelige typer

Vault understøtter en række forskellige hemmelige typer, som adresserer forskellige brugssager:

• Nøgleværdi: enkle statiske nøgleværdipar
• Dynamisk genererede legitimationsoplysninger: genereret af Vault efter anmodning fra en klient
• Kryptografiske nøgler: Bruges til at udføre kryptografiske funktioner med klientdata

Hver hemmelig type er defineret af følgende attributter:

• EN monterespunkt, som definerer sit REST API-præfiks
• Et sæt operationer eksponeret gennem den tilsvarende API
• Et sæt konfigurationsparametre

En given hemmelig instans er tilgængelig via en sti, ligesom et katalogtræ i et filsystem. Den første komponent i denne sti svarer til monteringspunkt hvor alle hemmeligheder af denne type er placeret.

For eksempel strengen hemmelighed / min ansøgning svarer til den sti, hvorunder vi kan finde nøgleværdipar til min ansøgning.

4.1. Nøgleværdihemmeligheder

Nøgleværdihemmeligheder er, som navnet antyder, enkle par, der er tilgængelige under en given sti. For eksempel kan vi gemme parret foo = bar under stien / hemmelighed / min ansøgning.

Senere bruger vi den samme sti til at hente det samme par eller par - flere par kan gemmes under samme sti.

Vault understøtter tre slags nøgleværdihemmeligheder:

• Ikke-versionerede nøglepar, hvor opdateringer erstatter eksisterende værdier
• Versionerede nøglepar, som holder op til et konfigurerbart antal gamle versioner
• Cubbyhole, en særlig type ikke-versionerede nøglepar, hvis værdier er afgrænset til en given adgangstoken (mere om dem senere).

Nøgleværdihemmeligheder er statiske af natur, så der er intet begreb om en tilknyttet udløb forbundet med dem. Den vigtigste brugssag for denne form for hemmelighed er at gemme legitimationsoplysninger for at få adgang til eksterne systemer, såsom API-nøgler.

I sådanne scenarier er legitimationsopdateringer en semi-manuel proces, der normalt kræver, at nogen erhverver nye legitimationsoplysninger og bruger Vault's kommandolinje eller dets brugergrænseflade til at indtaste de nye værdier.

4.2. Dynamisk genererede hemmeligheder

Dynamiske hemmeligheder genereres på flugt af Vault, når en applikation anmoder om det. Vault understøtter flere typer dynamiske hemmeligheder, herunder følgende:

• Databaseoplysninger
• SSH-nøglepar
• X.509 certifikater
• AWS legitimationsoplysninger
• Google Cloud-servicekonti
• Active Directory-konti

Alle disse følger det samme brugsmønster. Først konfigurerer vi den hemmelige motor med de nødvendige detaljer for at oprette forbindelse til den tilknyttede tjeneste. Derefter definerer vi en eller flere roller, som beskriver den egentlige hemmelige oprettelse.

Lad os tage databasens hemmelige motor som et eksempel. Først skal vi konfigurere Vault med alle detaljer om brugerdatabaseforbindelser, inklusive legitimationsoplysninger fra en allerede eksisterende bruger med administratorrettigheder for at oprette nye brugere.

Derefter opretter vi en eller flere roller (Vault-roller, ikke databaseroller), der indeholder de faktiske SQL-sætninger, der bruges til at oprette en ny bruger. Disse inkluderer normalt ikke kun erklæringen om oprettelse af brugere, men også alt det nødvendige give erklæringer, der kræves for at få adgang til skemaobjekter (tabeller, visninger osv.).

Når en klient får adgang til den tilsvarende API, opretter Vault en ny midlertidig bruger i databasen ved hjælp af de angivne udsagn og returnerer dens legitimationsoplysninger. Klienten kan derefter bruge disse legitimationsoplysninger til at få adgang til databasen i den periode, der er defineret af attributten time-to-live for den anmodede rolle.

Når en legitimationsoplysninger når sin udløbstid, vil Vault automatisk tilbagekalde ethvert privilegium, der er knyttet til denne bruger. En klient kan også anmode Vault om at forny disse legitimationsoplysninger. Fornyelsesprocessen sker kun, hvis den understøttes af den specifikke databasedriver og tillades af den tilknyttede politik.

4.3. Kryptografiske nøgler

Hemmelige motorer af typen håndterer kryptografiske funktioner som kryptering, dekryptering, signering og så videre. Alle disse operationer bruger kryptografiske nøgler genereret og gemt internt af Vault. Medmindre det udtrykkeligt er bedt om det, vil Vault aldrig udsætte en given kryptografisk nøgle.

Den tilknyttede API giver klienter mulighed for at sende Vault almindelig tekstdata og modtage en krypteret version af det. Det modsatte er også muligt: ​​Vi kan sende krypterede data og få den originale tekst tilbage.

I øjeblikket er der kun én motor af denne type: Transit motor. Denne motor understøtter populære nøgletyper, såsom RSA og ECDSA, og understøtter også Konvergent kryptering. Når du bruger denne tilstand, resulterer en given almindelig tekstværdi altid i det samme cyphertext-resultat, en egenskab, der er meget nyttig i nogle applikationer.

For eksempel kan vi bruge denne tilstand til at kryptere kreditkortnumre i en transaktionslogtabel. Med konvergent kryptering ville den krypterede kreditkortværdi være den samme, hver gang vi indsætter en ny transaktion, hvilket muliggør brugen af ​​regelmæssige SQL-forespørgsler til rapportering, søgning og så videre.

5. Vault Setup

I dette afsnit opretter vi et lokalt testmiljø, så vi tester Vault's muligheder.

Vault's implementering er enkel: download bare den pakke, der svarer til vores operativsystem, og udpak den eksekverbare (hvælving eller vault.exe på Windows) til et eller andet bibliotek på vores PATH. Denne eksekverbare version indeholder serveren og er også standardklienten. Der er også et officielt Docker-billede tilgængeligt, men vi dækker det ikke her.

Vault support a udvikling tilstand, hvilket er fint til nogle hurtige test og vænne sig til kommandolinjeværktøjet, men det er alt for forenklet til sande anvendelser: alle data går tabt ved genstart, og API-adgang bruger almindelig HTTP.

I stedet bruger vi filbaseret vedvarende opbevaring og opsætning af HTTPS, så vi kan udforske nogle af de virkelige konfigurationsdetaljer, der kan være en kilde til problemer.

5.1. Starter Vault Server

Vault bruger en konfigurationsfil, der bruger HCL- eller JSON-format. Følgende fil definerer al den konfiguration, der er nødvendig for at starte vores server ved hjælp af en filopbevaring og et selvsigneret certifikat:

lager "fil" {sti = "./vault-data"} lytter "tcp" {adresse = "127.0.0.1:8200" tls_cert_file = "./src/test/vault-config/localhost.cert" tls_key_file = ". /src/test/vault-config/localhost.key "}

Lad os nu køre Vault. Åbn en kommandoskal, gå til mappen, der indeholder vores konfigurationsfil, og kør denne kommando:

$ vault server -config. / vault-test.hcl

Vault starter og viser et par initialiseringsmeddelelser. De inkluderer dens version, nogle konfigurationsoplysninger og adressen, hvor API'en er tilgængelig. Det er det - vores Vault-server er i gang.

5.2. Initialisering af hvælving

Vores Vault-server kører nu, men da dette er dens første kørsel, skal vi initialisere den.

Lad os åbne en ny skal og udføre følgende kommandoer for at opnå dette:

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

Her har vi defineret et par miljøvariabler, så vi behøver ikke at videregive dem til Vault hver gang som parametre:

• VAULT_ADDR: base URI, hvor vores API-server vil betjene anmodninger
• VAULT_CACERT: Sti til vores servers certifikat offentlige nøgle

I vores tilfælde bruger vi VAULT_CACERT så vi kan bruge HTTPS til at få adgang til Vault's API. Vi har brug for dette, fordi vi bruger selvsignerede certifikater. Dette ville ikke være nødvendigt for produktionsmiljøer, hvor vi normalt har adgang til CA-signerede certifikater.

Efter udstedelse af ovenstående kommando skal vi se en besked som denne:

Unseal Key 1: Unseal Key 2: Unseal Key 3: Unseal Key 4: Unseal Key 5: Initial Root Token: ... flere meddelelser udeladt

De fem første linjer er de vigtigste nøgleandele, som vi senere vil bruge til at frasortere Vault's lager. Vær opmærksom på, at Vault kun viser masternøgle-aktierne under initialiseringen - og aldrig mere.Vær opmærksom og opbevar dem sikkert, ellers mister vi adgang til vores hemmeligheder ved serverstart igen!

Vær også opmærksom på rodtoken, som vi har brug for det senere. I modsætning til unseal nøgler, root-tokens kan let genereres på et senere tidspunkt, så det er sikkert at ødelægge det, når alle konfigurationsopgaver er afsluttet. Da vi senere udsteder kommandoer, der kræver et godkendelsestoken, skal vi gemme rodtokenet indtil videre i en miljøvariabel:

$ eksport VAULT_TOKEN = (Unix / Linux)

Lad os se vores serverstatus nu, da vi har initialiseret den med følgende kommando:

$ hvælvingstatus Nøgle Værdi --- ----- Forseglingstype shamir Forseglet sand I alt Aktier 5 Tærskel 3 Uforseglet fremskridt 0/3 Uforseglet Ikke relevant n / a Version 0.10.4 HA Aktiveret falsk

Vi kan se, at Vault stadig er forseglet. Vi kan også følge den usælge fremgang: "0/3" betyder, at Vault har brug for tre aktier, men indtil videre ikke fik nogen. Lad os gå videre og give det vores aktier.

5.3. Vault Unseal

Vi fratager nu Vault, så vi kan begynde at bruge dets hemmelige tjenester. Vi er nødt til at levere tre af de fem vigtige aktier for at afslutte unseal-processen:

$ vault operator unseal $ vault operator unseal $ vault operator unseal 

Efter udstedelse af hver kommandovælv udskriver den useglede fremgang, inklusive hvor mange aktier den har brug for. Når vi sender den sidste nøgledeling, ser vi en besked som denne:

Nøgleværdi --- ----- Forseglingstype shamir Forseglet falsk ... andre egenskaber udeladt

Den "forseglede" ejendom er "falsk" i dette tilfælde, hvilket betyder, at Vault er klar til at acceptere kommandoer.

6. Test af hvælving

I dette afsnit vil vi teste vores Vault-opsætning ved hjælp af to af dens understøttede hemmelige typer: Nøgle / værdi og database. Vi viser også, hvordan du opretter nye tokens med specifikke politikker knyttet til dem.

6.1. Brug af nøgle- / værdihemmeligheder

Lad os først gemme hemmelige nøgleværdipar og læse dem tilbage. Forudsat at kommandoskallen, der bruges til at initialisere Vault, stadig er åben, bruger vi følgende kommando til at gemme disse par under hemmelighed / fakebank sti:

$ vault kv put secret / fakebank api_key = abc1234 api_secret = 1a2b3c4d

Vi kan nu gendanne disse par til enhver tid med følgende kommando:

$ vault kv get secret / fakebank ======= Data ======= Nøgleværdi --- ----- api_key abc1234 api_secret 1a2b3c4d 

Denne enkle test viser os, at Vault fungerer som det skal. Vi kan nu teste nogle yderligere funktioner.

6.2. Oprettelse af nye poletter

Indtil videre har vi brugt rodtokenet for at godkende vores anmodninger. Da et rodtoken er vej for kraftig, betragtes det som en bedste praksis at bruge tokens med færre privilegier og kortere levetid.

Lad os oprette et nyt token, som vi kan bruge ligesom rodtokenet, men udløber efter blot et minut:

$ vault token oprette -ttl 1m nøgleværdi --- ----- token token_accessor token_duration 1m token_renewable true token_policies ["root"] identity_policies [] policies ["root"]

Lad os teste dette token ved at bruge det til at læse de nøgle / værdipar, som vi har oprettet før:

$ eksport VAULT_TOKEN = $ vault kv get secret / fakebank ======= Data ======= Nøgleværdi --- ----- api_key abc1234 api_secret 1a2b3c4d

Hvis vi venter et øjeblik og prøver at genudstede denne kommando, får vi en fejlmeddelelse:

$ vault kv get secret / fakebank Fejl ved API-anmodning. URL: GET // localhost: 8200 / v1 / sys / internal / ui / mounts / secret / fakebank Kode: 403. Fejl: * tilladelse nægtet

Meddelelsen indikerer, at vores token ikke længere er gyldigt, hvilket er, hvad vi har forventet.

6.3. Test af politikker

Eksemplet token vi har oprettet i det forrige afsnit var kortvarig, men stadig meget kraftig. Lad os nu bruge politikker til at oprette mere begrænsede tokens.

Lad os for eksempel definere en politik, der kun tillader læseadgang til hemmelighed / fakebank sti, vi brugte før:

$ cat> sample-policy.hcl <

Nu opretter vi et token med denne politik med følgende kommando:

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

Som vi har gjort før, lad os læse vores hemmelige værdier ved hjælp af dette token:

$ eksport VAULT_TOKEN = $ vault kv get secret / fakebank ======= Data ======= Nøgleværdi --- ----- api_key abc1234 api_secret 1a2b3c4d

Så langt så godt. Vi kan læse data som forventet. Lad os se, hvad der sker, når vi prøver at opdatere denne hemmelighed:

$ vault kv put secret / fakebank api_key = foo api_secret = bar Fejl ved skrivning af data til hemmelighed / fakebank: Fejl ved API-anmodning. URL: PUT //127.0.0.1:8200/v1/secret/fakebank Kode: 403. Fejl: * tilladelse nægtet

Da vores politik ikke udtrykkeligt tillader skrivning, returnerer Vault en statuskode 403 - Access Denied.

6.4. Brug af Dynamic Database Credentials

Som vores sidste eksempel i denne artikel, lad os bruge Vault's hemmelige motor til at skabe dynamiske legitimationsoplysninger. Vi antager her, at vi har en MySQL-server tilgængelig lokalt, og at vi kan få adgang til den med "root" -rettigheder. Vi bruger også et meget simpelt skema bestående af et enkelt bord - konto .

SQL-scriptet, der bruges til at oprette dette skema, og den privilegerede bruger er tilgængelig her.

Lad os nu konfigurere Vault til at bruge denne database. Databasens hemmelige motor er ikke aktiveret som standard, så vi skal rette dette, før vi kan fortsætte:

$ vault hemmeligheder muliggør database Succes! Aktiveret databasens hemmeligheder motor på: database /

Vi opretter nu en databasekonfigurationsressource:

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

Sti-præfikset database / konfiguration er, hvor alle databasekonfigurationer skal gemmes. Vi vælger navnet mysql-fakebank så vi kan let finde ud af, hvilken database denne konfiguration refererer til. Med hensyn til konfigurationstasterne:

• plugin_name: Definerer hvilket databaseplugin der skal bruges. De tilgængelige plugin-navne er beskrevet i Vault's dokumenter
• forbindelse_url: Dette er en skabelon, der bruges af pluginet, når du opretter forbindelse til databasen. Bemærk pladsholderne {{brugernavn}} og {{adgangskode}}. Når du opretter forbindelse til databasen, erstatter Vault disse pladsholdere med faktiske værdier
• allow_roles: Definer hvilke Vault-roller (der diskuteres næste) kan bruge denne konfiguration. I vores tilfælde bruger vi “*”, så det er tilgængeligt for alle roller
• brugernavn Kodeord: Dette er den konto, som Vault bruger til at udføre databasehandlinger, såsom at oprette en ny bruger og tilbagekalde dens privilegier

Vault Database Rolleopsætning

Den sidste konfigurationsopgave er at oprette en Vault-database-rolleressource, der indeholder de SQL-kommandoer, der kræves for at oprette en bruger. Vi kan oprette så mange roller som nødvendigt i henhold til vores sikkerhedskrav.

Her opretter vi en rolle, der giver skrivebeskyttet adgang til alle tabeller i fakebank skema:

$ vault skriv database / roller / fakebank-accounts-ro \ db_name = mysql-fakebank \ creation_statements = "Opret BRUGER '{{name}}' @ '%' IDENTIFICERET AF '{{password}}'; GRANT VÆLG PÅ fakebank. * At navngive}}'@'%';" 

Databasemotoren definerer stiprefikset database / roller som placeringen til at gemme roller. fakebank-accounts-ro er det rollenavn, som vi senere bruger, når vi opretter dynamiske legitimationsoplysninger. Vi leverer også følgende nøgler:

• db_name: Navnet på en eksisterende databasekonfiguration. Svarer til den sidste del af den sti, vi brugte, da vi oprettede konfigurationsressourcen
• creation_statements: En liste over SQL-sætningsskabeloner, som Vault bruger til at oprette en ny bruger

Oprettelse af dynamiske legitimationsoplysninger

Når vi har en database-rolle og dens tilsvarende konfiguration klar, genererer vi nye dynamiske legitimationsoplysninger med følgende kommando:

$ vault læse database / creds / fakebank-accounts-ro Nøgleværdi --- ----- lease_id database / creds / fakebank-accounts-ro / 0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 lease_duration 1h lease_renewable sandt password 

Det database / krediteringer præfikset bruges til at generere legitimationsoplysninger for de tilgængelige roller. Da vi har brugt fakebank-accounts-ro rolle, er det returnerede brugernavn / adgangskode begrænset til Vælg operationer.

Vi kan verificere dette ved at oprette forbindelse til databasen ved hjælp af de medfølgende legitimationsoplysninger og derefter udføre nogle SQL-kommandoer:

$ mysql -h 127.0.0.1 -u -p fakebank Indtast adgangskode: MySQL [fakebank]> vælg * fra konto; ... udeladt for kortfattethed 2 rækker i sæt (0,00 sek) MySQL [fakebank]> slet fra konto; FEJL 1142 (42000): SLET kommando nægtet bruger 'v-falske-9xoSKPkj1' @ 'localhost' til tabel 'konto' 

Vi kan se, at den første Vælg afsluttet med succes, men vi kunne ikke udføre slet udmelding. Endelig, hvis vi venter i en time og prøver at oprette forbindelse ved hjælp af de samme legitimationsoplysninger, vil vi ikke være i stand til at oprette forbindelse mere til databasen. Vault har automatisk tilbagekaldt alle rettigheder fra denne bruger

7. Konklusion

I denne artikel har de udforsket det grundlæggende i Hashicorp's Vault, herunder en vis baggrund om det problem, det forsøger at løse, dets arkitektur og grundlæggende brug.

Undervejs har vi skabt et simpelt, men funktionelt testmiljø, som vi bruger i opfølgende artikler.

Den næste artikel dækker et meget specifikt brugssag til Vault: Brug af det i sammenhæng med Spring Boot-applikationen. Bliv hængende!