streamalism.org

1. Oversikt

I denne opplæringen vil vi utforske Hashicorps Vault - et populært verktøy som brukes til å håndtere sensitiv informasjon på en sikker måte i moderne applikasjonsarkitekturer.

Hovedtemaene vi skal dekke, inkluderer:

• Hvilket problem prøver Vault å løse
• Vault's arkitektur og hovedkonsepter
• Oppsett av et enkelt testmiljø
• Samhandler med Vault ved hjelp av kommandolinjeverktøyet

2. Problemet med sensitiv informasjon

Før vi graver i Vault, la oss prøve å forstå problemet det prøver å løse: sensitiv informasjonsadministrasjon.

De fleste applikasjoner trenger tilgang til sensitive data for å kunne fungere skikkelig. For eksempel kan et e-handelsprogram ha et brukernavn / passord konfigurert et sted for å koble til databasen. Det kan også trenge API-nøkler for å integreres med andre tjenesteleverandører, for eksempel betalingsportaler, logistikk og andre forretningspartnere.

Databaseopplysninger og API-nøkler er noen eksempler på sensitiv informasjon som vi trenger å lagre og gjøre tilgjengelig for våre applikasjoner på en sikker måte.

En enkel løsning er å lagre legitimasjonen i en konfigurasjonsfil og lese dem ved oppstartstidspunktet. Problemet med denne tilnærmingen er imidlertid åpenbar. Den som har tilgang til denne filen, har de samme databaseprivilegiene som applikasjonen vår har - vanligvis gir hun full tilgang til alle lagrede data.

Vi kan prøve å gjøre ting litt vanskeligere ved å kryptere disse filene. Denne tilnærmingen vil imidlertid ikke legge til mye når det gjelder generell sikkerhet. Hovedsakelig fordi applikasjonen vår må ha tilgang til hovednøkkelen. Kryptering, når den brukes på denne måten, vil bare oppnå en "falsk" følelse av sikkerhet.

Moderne applikasjoner og skymiljøer har en tendens til å legge til litt ekstra kompleksitet: distribuerte tjenester, flere databaser, meldingssystemer og så videre, alle har sensitiv informasjon spredt litt overalt, og øker risikoen for sikkerhetsbrudd.

Så hva kan vi gjøre? La oss hvelve det!

3. Hva er hvelv?

Hashicorp Vault adresserer problemet med å håndtere sensitiv informasjon - a hemmelig på Vault sitt språk. “Administrering” i denne sammenhengen betyr at Vault kontrollerer alle aspekter av en sensitiv del av informasjonen: generering, lagring, bruk og sist, men ikke minst, tilbakekalling.

Hashicorp tilbyr to versjoner av Vault. Open source-versjonen, brukt i denne artikkelen, er gratis å bruke, selv i kommersielle miljøer. En betalt versjon er også tilgjengelig, som inkluderer teknisk støtte på forskjellige SLAer og tilleggsfunksjoner, for eksempel HSM (Hardware Security Module) -støtte.

3.1. Arkitektur og viktige funksjoner

Vault-arkitekturen er bedragerisk enkel. Hovedkomponentene er:

• En vedvarende backend - lagring for alle hemmeligheter
• En API-server som håndterer klientforespørsler og utfører operasjoner på hemmeligheter
• Et antall hemmelige motorer, en for hver type støttet hemmelig type

Ved å delegere all hemmelig håndtering til Vault, kan vi redusere noen sikkerhetsproblemer:

• Applikasjonene våre trenger ikke å lagre dem lenger - bare spør Vault når det er nødvendig, og kast det
• Vi kan bruke kortvarige hemmeligheter, og dermed begrense “mulighetsvinduet” der en angriper kan bruke en stjålet hemmelighet

Vault krypterer alle data med en krypteringsnøkkel før du skriver dem til butikken. Denne krypteringsnøkkelen er kryptert av enda en nøkkel - hovednøkkelen, som bare brukes ved oppstart.

Et viktig poeng i implementeringen av Vault er at den ikke lagrer hovednøkkelen på serveren. Dette betyr at ikke engang Vault har tilgang til lagrede data etter oppstart. På dette tidspunktet sies en Vault-forekomst å være i en "forseglet" tilstand.

Senere vil vi gå gjennom trinnene som er nødvendige for å generere hovednøkkelen og fjerne forseglingen av en Vault-forekomst.

Når den ikke er forseglet, vil Vault være klar til å godta API-forespørsler. Disse forespørslene trenger selvfølgelig autentisering, noe som bringer oss til hvordan Vault autentiserer klienter og bestemmer hva de kan eller ikke kan gjøre.

3.2. Godkjenning

For å få tilgang til hemmeligheter i Arkiv, må en klient godkjenne seg selv ved hjelp av en av de støttede metodene. Den enkleste metoden bruker tokens, som bare er strenger sendt på hver API-forespørsel ved hjelp av en spesiell HTTP-topptekst.

Når den ble installert opprinnelig, genererer Vault automatisk et “root token”. Dette tokenet tilsvarer root-superbruker i Linux-systemer, så bruken bør begrenses til et minimum. Som en best praksis bør vi bruke dette rot-token bare for å lage andre tokens med færre privilegier og deretter tilbakekalle det. Dette er ikke et problem, siden vi senere kan generere et annet rot-token ved hjelp av unseal-nøkler.

Vault støtter også andre autentiseringsmekanismer som blant annet LDAP, JWT, TLS-sertifikater. Alle disse mekanismene bygger på den grunnleggende token-mekanismen: Når Vault validerer klienten vår, vil den gi et token som vi deretter kan bruke for å få tilgang til andre API-er.

Tokens har noen få egenskaper knyttet til seg. Hovedegenskapene er:

• Et sett med tilhørende Retningslinjer (se neste avsnitt)
• Tid til å leve
• Om det kan fornyes
• Maksimalt antall brukere

Med mindre annet er fortalt, vil tokens opprettet av Vault danne et foreldre-barn-forhold. Et barnetoken kan maksimalt ha samme nivå av privilegier som foreldrene har.

Det motsatte er ikke sant: vi kan - og vanligvis gjør - lage et barnetoken med restriktive retningslinjer. Et annet viktig poeng om dette forholdet: Når vi ugyldiggjør et token, blir alle underordnede tokens og deres etterkommere også ugyldiggjort.

3.3. Retningslinjer

Politikk definerer nøyaktig hvilke hemmeligheter en klient kan få tilgang til og hvilke operasjoner den kan utføre med dem. La oss se hvordan en enkel policy ser ut:

sti "hemmelig / regnskap" {skills = ["read"]}

Her har vi brukt syntaksen HCL (Hashicorps Configuration Language) for å definere policyen vår. Vault støtter også JSON for dette formålet, men vi holder oss til HCL i eksemplene våre, siden det er lettere å lese.

Retningslinjer i Arkiv er "benekt som standard". Et token knyttet til denne eksempelpolicyen vil få tilgang til hemmeligheter lagret under hemmelig / regnskap og ingenting annet. Ved opprettelsestidspunktet kan et token knyttes til flere policyer. Dette er veldig nyttig fordi det lar oss lage og teste mindre policyer og deretter bruke dem etter behov.

Et annet viktig aspekt ved politikken er at de utnytter lat evaluering. Dette betyr at vi kan oppdatere en gitt policy, og alle tokens blir berørt umiddelbart.

Retningslinjene som er beskrevet hittil kalles også Access Control List Policies, eller ACL Policies. Vault støtter også to ytterligere policytyper: EGP- og RGP-policyer. De er bare tilgjengelige i betalte versjoner og utvider den grunnleggende policy-syntaksen med Sentinel-støtte.

Når det er tilgjengelig, kan dette ta hensyn til ytterligere attributter i vår policy, som tid på dagen, flere autentiseringsfaktorer, opprinnelse til klientnettverket og så videre. For eksempel kan vi definere en policy som bare gir tilgang til en gitt hemmelighet på åpningstidene.

Vi finner mer detaljer om policy-syntaksen i Vault's dokumentasjon.

4. Hemmelige typer

Vault støtter en rekke forskjellige hemmelige typer som adresserer forskjellige brukssaker:

• Nøkkelverdi: enkle statiske nøkkelverdier par
• Dynamisk generert legitimasjon: generert av Vault på forespørsel fra en klient
• Kryptografiske nøkler: Brukes til å utføre kryptografiske funksjoner med klientdata

Hver hemmelige type er definert av følgende attributter:

• EN monterepunkt, som definerer REST API-prefikset
• Et sett med operasjoner eksponert gjennom tilsvarende API
• Et sett med konfigurasjonsparametere

En gitt hemmelig forekomst er tilgjengelig via en sti, omtrent som et katalogtreet i et filsystem. Den første komponenten i denne banen tilsvarer monteringspunkt der alle hemmeligheter av denne typen ligger.

For eksempel strengen hemmelig / min søknad tilsvarer banen vi kan finne nøkkelverdipar for min søknad.

4.1. Nøkkelverdier

Nøkkelverdihemmeligheter er, som navnet antyder, enkle par i det tilgjengelige under en gitt bane. For eksempel kan vi lagre paret foo = bar under stien / hemmelig / min søknad.

Senere bruker vi samme bane for å hente det samme paret eller parene - flere par kan lagres under samme bane.

Vault støtter tre typer nøkkelverdier:

• Ikke-versjonerte nøkkelpar, der oppdateringer erstatter eksisterende verdier
• Versjonerte nøkkelpar, som holder opp til et konfigurerbart antall gamle versjoner
• Cubbyhole, en spesiell type ikke-versjonerte nøkkelpar hvis verdier er avgrenset til en gitt tilgangstoken (mer om de senere).

Nøkkelverdihemmeligheter er statiske av natur, så det er ikke noe begrep om en tilknyttet utløp knyttet til dem. Hovedbrukssaken for denne typen hemmeligheter er å lagre legitimasjon for å få tilgang til eksterne systemer, for eksempel API-nøkler.

I slike scenarier er påloggingsoppdateringer en semi-manuell prosess, som vanligvis krever at noen skaffer seg ny legitimasjon og bruker Velts kommandolinje eller brukergrensesnittet for å angi de nye verdiene.

4.2. Dynamisk genererte hemmeligheter

Dynamiske hemmeligheter genereres i farta av Vault når det blir bedt om det av en applikasjon. Vault støtter flere typer dynamiske hemmeligheter, inkludert følgende:

• Databaseopplysninger
• SSH nøkkelpar
• X.509 sertifikater
• AWS legitimasjon
• Google Cloud-tjenestekontoer
• Active Directory-kontoer

Alle disse følger samme bruksmønster. Først konfigurerer vi den hemmelige motoren med detaljene som kreves for å koble til den tilknyttede tjenesten. Deretter definerer vi en eller flere roller, som beskriver den faktiske hemmelige skapelsen.

La oss ta databasens hemmelige motor som et eksempel. Først må vi konfigurere Vault med alle detaljer om brukerdatabaseforbindelser, inkludert legitimasjon fra en eksisterende bruker med administratorrettigheter for å opprette nye brukere.

Deretter oppretter vi en eller flere roller (Arkivroller, ikke databaseroller) som inneholder de faktiske SQL-setningene som ble brukt til å opprette en ny bruker. Disse inkluderer vanligvis ikke bare brukeropprettelseserklæringen, men også alt det nødvendige stipend uttalelser som kreves for å få tilgang til skjemaobjekter (tabeller, visninger og så videre).

Når en klient får tilgang til tilsvarende API, vil Vault opprette en ny midlertidig bruker i databasen ved hjelp av de angitte setningene og returnere legitimasjonen sin. Klienten kan deretter bruke legitimasjonen til å få tilgang til databasen i løpet av perioden som er definert av time-to-live-attributtet til den forespurte rollen.

Når en legitimasjon når utløpstiden, vil Vault automatisk tilbakekalle ethvert privilegium tilknyttet denne brukeren. En klient kan også be Vault om å fornye legitimasjonen. Fornyelsesprosessen vil bare skje hvis den støttes av den spesifikke databasedriveren og tillates av den tilhørende policyen.

4.3. Kryptografiske nøkler

Hemmelige motorer av typen håndterer kryptografiske funksjoner som kryptering, dekryptering, signering og så videre. Alle disse operasjonene bruker kryptografiske nøkler generert og lagret internt av Vault. Med mindre eksplisitt blir bedt om å gjøre det, vil Vault aldri avsløre en gitt kryptografisk nøkkel.

Den tilknyttede API-en gjør det mulig for klienter å sende Vault-tekst i ren tekst og motta en kryptert versjon av den. Det motsatte er også mulig: Vi kan sende krypterte data og få tilbake originalteksten.

For øyeblikket er det bare én motor av denne typen: Gjennomreise motor. Denne motoren støtter populære nøkkeltyper, for eksempel RSA og ECDSA, og støtter også Konvergent kryptering. Når du bruker denne modusen, resulterer en gitt ren tekst alltid i det samme cyphertext-resultatet, en egenskap som er veldig nyttig i noen applikasjoner.

For eksempel kan vi bruke denne modusen til å kryptere kredittkortnumre i en transaksjonsloggtabell. Med konvergent kryptering vil den krypterte kredittkortverdien være den samme hver gang vi setter inn en ny transaksjon, og dermed tillate bruk av vanlige SQL-spørsmål for rapportering, søk og så videre.

5. Vault Setup

I denne delen vil vi lage et lokalt testmiljø slik at vi tester hvelvets evner.

Vault-distribusjonen er enkel: bare last ned pakken som tilsvarer operativsystemet vårt og trekk ut den kjørbare filen (hvelv eller vault.exe på Windows) til noen kataloger på PATH. Denne kjørbare filen inneholder serveren og er også standardklienten. Det er også et offisielt Docker-bilde tilgjengelig, men vi vil ikke dekke det her.

Hvelvstøtte a utvikling modus, som er greit for rask testing og vant til kommandolinjeverktøyet, men det er altfor forenklet for tilfeller med reell bruk: alle data går tapt ved omstart, og API-tilgang bruker vanlig HTTP.

I stedet bruker vi filbasert vedvarende lagring og konfigurerer HTTPS slik at vi kan utforske noen av de virkelige konfigurasjonsdetaljene som kan være en kilde til problemer.

5.1. Starter Vault Server

Vault bruker en konfigurasjonsfil i HCL- eller JSON-format. Følgende fil definerer all konfigurasjon som er nødvendig for å starte serveren vår ved hjelp av en fillagring og et selvsignert sertifikat:

lagring "fil" {path = "./vault-data"} lytter "tcp" {address = "127.0.0.1:8200" tls_cert_file = "./src/test/vault-config/localhost.cert" tls_key_file = ". /src/test/vault-config/localhost.key "}

La oss kjøre Vault. Åpne et kommandoskall, gå til katalogen som inneholder konfigurasjonsfilen vår og kjør denne kommandoen:

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

Vault starter og viser noen initialiseringsmeldinger. De inkluderer versjonen, noen konfigurasjonsdetaljer og adressen der API-en er tilgjengelig. Det er det - vår Vault-server er oppe og går.

5.2. Initialisering av hvelv

Vault-serveren vår kjører nå, men siden dette er den første kjøringen, må vi initialisere den.

La oss åpne et nytt skall og utføre følgende kommandoer for å oppnå dette:

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

Her har vi definert noen miljøvariabler, så vi trenger ikke å overføre dem til Arkiv hver gang som parametere:

• VAULT_ADDR: base URI der API-serveren vår vil levere forespørsler
• VAULT_CACERT: Sti til serverens sertifikat offentlige nøkkel

I vårt tilfelle bruker vi VAULT_CACERT slik at vi kan bruke HTTPS for å få tilgang til Vault's API. Vi trenger dette fordi vi bruker selvsignerte sertifikater. Dette ville ikke være nødvendig for produksjonsmiljøer, der vi vanligvis har tilgang til CA-signerte sertifikater.

Etter å ha gitt kommandoen ovenfor, bør vi se en melding som denne:

Unseal Key 1: Unseal Key 2: Unseal Key 3: Unseal Key 4: Unseal Key 5: Initial Root Token: ... flere meldinger utelatt

De fem første linjene er hovednøkkelaksjene som vi senere vil bruke til å fjerne forseglingen til Vault. Vær oppmerksom på at Vault bare viser hovednøkkelandeler under initialisering - og aldri mer.Legg merke til dem og lagre dem trygt, ellers mister vi tilgangen til hemmelighetene våre ved serverstart!

Vær også oppmerksom på rottegn, som vi trenger det senere. I motsetning til uforseglede nøkler, root-tokens kan enkelt genereres på et senere tidspunkt, så det er trygt å ødelegge det når alle konfigurasjonsoppgaver er fullført. Siden vi vil utstede kommandoer senere som krever et godkjenningstoken, la oss lagre rot-token for øyeblikket i en miljøvariabel:

$ eksport VAULT_TOKEN = (Unix / Linux)

La oss se serverstatusen vår nå som vi har initialisert den, med følgende kommando:

$ hvelvstatus Nøkkel Verdi --- ----- Tetningstype shamir Forseglet sann Totalt antall aksjer 5 Terskel 3 Uforseglet fremdrift 0/3 Uforseglet ikke-relevant ikke tilgjengelig Versjon 0.10.4 HA Aktivert falsk

Vi kan se at Vault fortsatt er forseglet. Vi kan også følge den forseglede fremgangen: "0/3" betyr at Vault trenger tre aksjer, men har ingen så langt. La oss gå videre og gi det våre aksjer.

5.3. Vault Unseal

Vi fjerner nå Vault slik at vi kan begynne å bruke hemmelige tjenester. Vi må tilby tre av de fem nøkkelaksjene for å fullføre unseal-prosessen:

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

Etter å ha utstedt hvert kommandohvelv, skrives ut unseal-fremdriften, inkludert hvor mange aksjer den trenger. Når du sender den siste nøkkelandelen, ser vi en melding som denne:

Nøkkelverdi --- ----- Tetningstype shamir Forseglet falsk ... andre egenskaper utelatt

Den "forseglede" eiendommen er "falsk" i dette tilfellet, noe som betyr at Vault er klar til å godta kommandoer.

6. Testing av hvelv

I denne delen vil vi teste vårt hvelvoppsett ved hjelp av to av de støttede hemmelige typene: Nøkkel / verdi og database. Vi vil også vise hvordan du lager nye tokens med spesifikke retningslinjer knyttet til dem.

6.1. Bruke nøkkel- / verdihemmeligheter

La oss først lagre hemmelige nøkkelverdipar og lese dem tilbake. Forutsatt at kommandoskallet som ble brukt til å initialisere Vault fremdeles er åpent, bruker vi følgende kommando til å lagre disse parene under hemmelighet / fakebank sti:

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

Vi kan nå gjenopprette disse parene når som helst med følgende kommando:

$ hvelv kv bli hemmelig / fakebank ======= Data ======= Nøkkelverdi --- ----- api_key abc1234 api_secret 1a2b3c4d 

Denne enkle testen viser oss at Vault fungerer som den skal. Vi kan nå teste noen ekstra funksjoner.

6.2. Opprette nye poletter

Så langt har vi brukt rot-token for å autentisere forespørslene våre. Siden et rot-token er vei for kraftig, regnes det som en beste praksis å bruke tokens med færre privilegier og kortere levetid.

La oss lage et nytt token som vi kan bruke akkurat som rotetokenet, men utløper etter bare et minutt:

$ vault token create -ttl 1m Key Value --- ----- token token_accessor token_duration 1m token_renewable true token_policies ["root"] identity_policies [] policies ["root"]

La oss teste dette tokenet, ved å bruke det til å lese nøkkel / verdiparene vi har opprettet før:

$ eksport VAULT_TOKEN = $ hvelv kv bli hemmelig / fakebank ======= Data ======= Nøkkelverdi --- ----- api_key abc1234 api_secret 1a2b3c4d

Hvis vi venter et øyeblikk og prøver å utstede denne kommandoen på nytt, får vi en feilmelding:

$ vault kv get secret / fakebank Feil ved å stille API-forespørsel. URL: GET // localhost: 8200 / v1 / sys / internal / ui / mounts / secret / fakebank Kode: 403. Feil: * tillatelse nektet

Meldingen indikerer at tokenet vårt ikke lenger er gyldig, og det er det vi har forventet.

6.3. Testing Policy

Eksemplet token vi har opprettet i forrige seksjon var kortvarig, men fortsatt veldig kraftig. La oss nå bruke retningslinjer for å lage mer begrensede tokens.

La oss for eksempel definere en policy som bare tillater lesetilgang til hemmelighet / fakebank sti vi brukte før:

$ cat> sample-policy.hcl <

Nå oppretter vi et token med denne policyen med følgende kommando:

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

Som vi har gjort før, la oss lese våre hemmelige verdier ved hjelp av dette tokenet:

$ eksport VAULT_TOKEN = $ hvelv kv bli hemmelig / fakebank ======= Data ======= Nøkkelverdi --- ----- api_key abc1234 api_secret 1a2b3c4d

Så langt så bra. Vi kan lese data, som forventet. La oss se hva som skjer når vi prøver å oppdatere denne hemmeligheten:

$ vault kv put secret / fakebank api_key = foo api_secret = bar Feil ved skriving av data til hemmelig / fakebank: Feil ved forespørsel om API. URL: PUT //127.0.0.1:8200/v1/secret/fakebank Kode: 403. Feil: * tillatelse nektet

Siden policyen ikke eksplisitt tillater skriving, returnerer Vault en 403 - Access Denied-statuskode.

6.4. Bruke Dynamic Database Credentials

Som det siste eksemplet i denne artikkelen, la oss bruke Vault's hemmelige motor for å skape dynamiske referanser. Vi antar her at vi har en MySQL-server tilgjengelig lokalt, og at vi kan få tilgang til den med "root" -rettigheter. Vi vil også bruke et veldig enkelt skjema som består av et enkelt bord - regnskap .

SQL-skriptet som ble brukt til å opprette dette skjemaet, og den privilegerte brukeren er tilgjengelig her.

La oss nå konfigurere Vault til å bruke denne databasen. Databasens hemmelige motor er ikke aktivert som standard, så vi må fikse dette før vi kan fortsette:

$ vault secrets muliggjør database Suksess! Aktivert databasens hemmelige motor på: database /

Vi oppretter nå en databasekonfigurasjonsressurs:

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

Stiprefikset database / config er der alle databasekonfigurasjoner må lagres. Vi velger navnet mysql-fakebank slik at vi enkelt kan finne ut hvilken database denne konfigurasjonen refererer til. Når det gjelder konfigurasjonstastene:

• plugin_name: Definerer hvilket databaseplugin som skal brukes. De tilgjengelige plugin-navnene er beskrevet i Arkivs dokumenter
• connection_url: Dette er en mal som brukes av pluginet når du kobler til databasen. Legg merke til plassholderne for {{brukernavn}} og {{passord}}. Når du kobler til databasen, vil Vault erstatte disse plassholderne med faktiske verdier
• allow_roles: Definer hvilke Vault-roller (diskutert neste) som kan bruke denne konfigurasjonen. I vårt tilfelle bruker vi “*”, så det er tilgjengelig for alle roller
• brukernavn passord: Dette er kontoen Vault vil bruke til å utføre databaseaksjoner, for eksempel å opprette en ny bruker og tilbakekalle rettighetene

Vault Database Role Setup

Den siste konfigurasjonsoppgaven er å opprette en Vault-database-rolleressurs som inneholder SQL-kommandoene som kreves for å opprette en bruker. Vi kan opprette så mange roller som nødvendig, i henhold til våre sikkerhetskrav.

Her oppretter vi en rolle som gir skrivebeskyttet tilgang til alle tabellene i fakebank skjema:

$ vault skriv database / roller / fakebank-accounts-ro \ db_name = mysql-fakebank \ creation_statements = "OPPRETT BRUKER '{{name}}' @ '%' IDENTIFISERT AV '{{password}}'; GRANT VALG PÅ fakebank. * Å navngi}}'@'%';" 

Databasemotoren definerer stiprefikset database / roller som stedet for å lagre roller. fakebank-accounts-ro er rollenavnet som vi senere bruker når vi oppretter dynamiske legitimasjonsbeskrivelser. Vi leverer også følgende nøkler:

• db_name: Navnet på en eksisterende databasekonfigurasjon. Tilsvarer den siste delen av banen vi brukte da vi opprettet konfigurasjonsressursen
• creation_statements: En liste over SQL-setningsmaler som Vault vil bruke til å opprette en ny bruker

Opprette dynamiske referanser

Når vi har en database-rolle og tilhørende konfigurasjon klar, genererer vi nye dynamiske referanser med følgende kommando:

$ vault read database / creds / fakebank-accounts-ro Key Value --- ----- lease_id database / creds / fakebank-accounts-ro / 0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 lease_duration 1h lease_renewable true password brukernavn 

De database / kreditter prefikset brukes til å generere legitimasjon for de tilgjengelige rollene. Siden vi har brukt fakebank-accounts-ro rolle, vil det returnerte brukernavnet / passordet være begrenset til å velge operasjoner.

Vi kan verifisere dette ved å koble til databasen ved hjelp av de medfølgende legitimasjonene og deretter utføre noen SQL-kommandoer:

$ mysql -h 127.0.0.1 -u -p fakebank Skriv inn passord: MySQL [fakebank]> velg * fra konto; ... utelatt for kortfattethet 2 rader i sett (0,00 sek) MySQL [fakebank]> slett fra konto; FEIL 1142 (42000): SLETT kommando nektet bruker 'v-fake-9xoSKPkj1' @ 'localhost' for tabellkonto ' 

Vi kan se at den første å velge fullført, men vi kunne ikke utføre slett uttalelse. Til slutt, hvis vi venter i en time og prøver å koble til ved hjelp av de samme legitimasjonene, vil vi ikke kunne koble lenger til databasen. Arkiv har automatisk tilbakekalt alle rettigheter fra denne brukeren

7. Konklusjon

I denne artikkelen har vi utforsket det grunnleggende i Hashicorps Vault, inkludert litt bakgrunn om problemet det prøver å løse, dets arkitektur og grunnleggende bruk.

Underveis har vi skapt et enkelt, men funksjonelt testmiljø som vi skal bruke i oppfølgingsartikler.

Neste artikkel vil dekke en veldig spesifikk brukssak for Vault: Bruker den i sammenheng med Spring Boot-applikasjonen. Følg med!