En introduksjon til Spring Cloud Vault

1. Oversikt

I denne opplæringen viser vi hvordan vi kan bruke Hashicorps Vault i Spring Boot-applikasjoner for å sikre sensitive konfigurasjonsdata.

Vi antar her litt Vault-kunnskap og at vi allerede har et testoppsett. Hvis dette ikke er tilfelle, la oss ta oss tid til å lese vår Vault Intro-opplæring, slik at vi kan bli kjent med det grunnleggende.

2. Spring Cloud Vault

Spring Cloud Vault er et relativt nylig tillegg til Spring Cloud stack lar applikasjoner få tilgang til hemmeligheter lagret i en Vault-forekomst på en gjennomsiktig måte.

Generelt er migrering til Vault en veldig enkel prosess: bare legg til de nødvendige bibliotekene og legg til noen ekstra konfigurasjonsegenskaper til prosjektet vårt, så vi skal være gode å gå. Ingen kodeendringer kreves!

Dette er mulig fordi det fungerer høyt PropertySource registrert i gjeldende Miljø.

Som sådan vil Spring bruke den når en eiendom er påkrevd. Eksempler inkluderer Datakilde eiendommer, ConfigurationProperties, og så videre.

3. Legge til Spring Cloud Vault i et Spring Boot-prosjekt

For å inkludere vår-sky-hvelv bibliotek i et Maven-basert Spring Boot-prosjekt, bruker vi det tilknyttede forrett artefakt, som vil trekke alle nødvendige avhengigheter.

Foruten det viktigste forrett, vi inkluderer også vår-hvelv-konfigurasjonsdatabaser, som legger til støtte for dynamisk legitimasjon for databaser:

 org.springframework.cloud spring-cloud-starter-vault-config org.springframework.cloud spring-cloud-vault-config-databases 

Den siste versjonen av Spring Cloud Vault-starter kan lastes ned fra Maven Central.

3.1. Grunnleggende konfigurasjon

For å fungere skikkelig trenger Spring Cloud Vault en måte å finne ut hvor du skal kontakte Vault-serveren og hvordan du autentiserer seg mot den.

Vi gjør dette ved å oppgi nødvendig informasjon i bootstrap.yml eller bootstrap.properties:

# bootstrap.yml vår: sky: hvelv: uri: // localhost: 8200 ssl: trust-store: classpath: /vault.jks trust-store-password: changeit 

De spring.cloud.vault.uri egenskap peker til Vault API-adresse. Siden testmiljøet vårt bruker HTTPS med et selvsignert sertifikat, må vi også tilby en nøkkelbutikk som inneholder den offentlige nøkkelen.

Merk at denne konfigurasjonen ikke har autentiseringsdata. For det enkleste tilfellet, der vi bruker et fast token, kan vi føre det gjennom systemegenskapen spring.cloud.vault.token eller en miljøvariabel. Denne tilnærmingen fungerer bra sammen med standard sky-konfigurasjonsmekanismer, for eksempel Kubernetes 'ConfigMaps eller Docker-hemmeligheter.

Spring Vault krever også ekstra konfigurasjon for hver type hemmelighet som vi vil bruke i applikasjonen vår. Følgende seksjoner beskriver hvordan vi kan legge til støtte for to vanlige hemmelige typer: nøkkel / verdi og databaseopplysninger.

4. Bruke Generic Secrets Backend

Vi bruker Generic Secret-backend for å få tilgang uversjonert hemmeligheter lagret som nøkkelverdipar i Arkiv.

Forutsatt at vi allerede har spring-cloud-starter-vault-config avhengighet i vår klassesti, alt vi trenger å gjøre er å legge til noen egenskaper i applikasjonens bootstrap.yml konfigurasjonsfil:

vår: sky: hvelv: # andre hvelvegenskaper utelatt ... generisk: aktivert: ekte applikasjonsnavn: fakebank 

Eiendommen Programnavn er valgfritt i dette tilfellet. Hvis ikke spesifisert, vil Spring anta verdien av standarden våren.applikasjon.navn i stedet.

Vi kan nå bruke alle nøkkel / verdipar lagret på hemmelighet / fakebank som alle andre Miljø eiendom. Følgende utdrag viser hvordan vi kan lese verdien av foo nøkkel lagret under denne banen:

@Autowired Environment env; public String getFoo () {return env.getProperty ("foo"); } 

Som vi kan se, vet ikke selve koden noe om Vault, som er bra! Vi kan fremdeles bruke faste egenskaper i lokale tester og bytte til Vault som vi bare vil ved å aktivere en enkelt eiendom i bootstrap.yml.

4.1. En merknad om vårprofiler

Hvis tilgjengelig i gjeldende Miljø, Spring Cloud Vault vil bruke de tilgjengelige profilnavnene som et suffiks vedlagt den angitte basisstien der nøkkel / verdipar vil bli søkt.

Det vil også se etter egenskaper under en konfigurerbar standard applikasjonsbane (med og uten profilsuffiks), slik at vi kan ha delte hemmeligheter på ett sted. Bruk denne funksjonen med forsiktighet!

For å oppsummere, hvis produksjon profil av ut fakebank applikasjonen er aktiv, vil Spring Vault se etter egenskaper som er lagret under følgende baner:

  1. hemmelig/fakebank/produksjon (høyere prioritet)
  2. hemmelig/fakebank
  3. hemmelighet / applikasjon / produksjon
  4. hemmelighet / applikasjon (lavere prioritet)

I den forrige listen, applikasjon er navnet som Spring bruker som standard tilleggssted for hemmeligheter. Vi kan endre det ved hjelp av spring.cloud.vault.generic.default-context eiendom.

Egenskaper som er lagret under den mest spesifikke banen, vil ha forrang fremfor de andre. For eksempel hvis den samme eiendommen foo er tilgjengelig under stier over, så vil forrangsrekkefølgen være:

5. Bruke databasens hemmelige backend

Database-backend-modulen lar Spring-applikasjoner bruke dynamisk genererte databaseregistreringer opprettet av Vault. Spring Vault injiserer legitimasjonen under standarden spring.datasource.username og spring.datasource.password eiendommer slik at de kan plukkes med vanlig Datakildes.

Vær oppmerksom på at før vi bruker denne backend, må vi opprette en databasekonfigurasjon og roller i Vault som beskrevet i vår forrige opplæring.

For å kunne bruke Vault-genererte databaseregistreringer i vår-applikasjonen, er vår-sky-hvelv-konfigurasjonsdatabaser må være til stede i prosjektets klassesti, sammen med den tilsvarende JDBC-driveren.

Vi må også aktivere bruken i applikasjonen vår ved å legge til noen egenskaper i vår bootstrap.yml:

vår: sky: hvelv: # ... andre egenskaper utelatt database: aktivert: sann rolle: fakebank-accounts-rw

Den viktigste egenskapen her er rolle eiendom, som har et databaserollens navn lagret i Arkiv. Under bootstrap vil Spring kontakte Vault og be om at det oppretter nye referanser med tilhørende rettigheter.

Hvelvet vil som standard tilbakekalle rettighetene knyttet til disse legitimasjonene etter den konfigurerte time-to-live.

Heldigvis, Spring Vault fornyer automatisk leiekontrakten som er knyttet til den ervervede legitimasjonen. Ved å gjøre dette vil legitimasjonen forbli gyldig så lenge applikasjonen kjører.

La oss nå se integrasjonen i aksjon. Følgende kodebit får en ny databaseforbindelse fra en Spring-administrert Datakilde:

Tilkobling c = datasource.getConnection (); 

Nok en gang kan vi se at det ikke er tegn på bruk av Arkiv i koden vår. All integrasjon skjer på stedet Miljø nivå, slik at koden vår enkelt kan testes som vanlig.

6. Konklusjon

I denne opplæringen har vi vist hvordan du kan integrere Vault med Spring Boot ved hjelp av Spring Vault-biblioteket. Vi har dekket to vanlige bruksområder: generiske nøkkel / verdipar og dynamiske databaseregistreringer.

Et eksempel på prosjekt som inneholder alle nødvendige avhengigheter, integrasjonstester og skript for hvelvoppsett, er tilgjengelig på GitHub.


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