En introduktion til Spring Cloud Vault

1. Oversigt

I denne vejledning viser vi, hvordan vi kan bruge Hashicorps Vault i Spring Boot-applikationer til at sikre følsomme konfigurationsdata.

Vi antager her noget Vault-viden, og at vi allerede har en testopsætning. Hvis dette ikke er tilfældet, lad os tage et øjeblik til at læse vores Vault Intro-tutorial, så vi kan stifte bekendtskab med dens grundlæggende.

2. Spring Cloud Vault

Spring Cloud Vault er en relativt nylig tilføjelse til Spring Cloud stack giver applikationer adgang til hemmeligheder, der er gemt i en Vault-instans på en gennemsigtig måde.

Generelt er migrering til Vault en meget enkel proces: bare tilføj de krævede biblioteker og tilføj et par ekstra konfigurationsegenskaber til vores projekt, så vi skal være gode at gå. Ingen kodeændringer er påkrævet!

Dette er muligt, fordi det fungerer højt PropertySource registreret i strømmen Miljø.

Som sådan vil Spring bruge det, når en ejendom er påkrævet. Eksempler inkluderer Datakilde ejendomme, ConfigurationProperties, og så videre.

3. Tilføjelse af Spring Cloud Vault til et Spring Boot-projekt

For at inkludere forår-sky-hvælving bibliotek i et Maven-baseret Spring Boot-projekt, bruger vi det tilknyttede forret artefakt, som trækker alle krævede afhængigheder.

Udover det vigtigste forret, Vi inkluderer også spring-vault-config-databaser, der tilføjer understøttelse af dynamiske databaseoplysninger:

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

Den seneste version af Spring Cloud Vault-starter kan downloades fra Maven Central.

3.1. Grundlæggende konfiguration

For at fungere korrekt har Spring Cloud Vault brug for en måde at bestemme, hvor Vault-serveren skal kontaktes, og hvordan man godkender sig selv mod den.

Vi gør dette ved at give de nødvendige oplysninger i bootstrap.yml eller bootstrap.properties:

# bootstrap.yml spring: cloud: vault: uri: // localhost: 8200 ssl: trust-store: classpath: /vault.jks trust-store-password: changeit 

Det spring.cloud.vault.uri ejendom peger på Vault's API-adresse. Da vores testmiljø bruger HTTPS med et selvsigneret certifikat, er vi også nødt til at levere en nøglelager, der indeholder dens offentlige nøgle.

Bemærk, at denne konfiguration ikke har nogen godkendelsesdata. I det enkleste tilfælde, hvor vi bruger et fast token, kan vi føre det gennem systemegenskaben spring.cloud.vault.token eller en miljøvariabel. Denne tilgang fungerer godt sammen med standard cloud-konfigurationsmekanismer, såsom Kubernetes 'ConfigMaps eller Docker-hemmeligheder.

Spring Vault kræver også ekstra konfiguration for hver type hemmelighed, som vi vil bruge i vores applikation. De følgende afsnit beskriver, hvordan vi kan tilføje support til to almindelige hemmelige typer: nøgle / værdi og databaseoplysninger.

4. Brug af Generic Secrets Backend

Vi bruger Generic Secret-backend til at få adgang uversioneret hemmeligheder gemt som nøgleværdipar i Vault.

Forudsat at vi allerede har spring-cloud-starter-vault-config afhængighed i vores klassestialt hvad vi skal gøre er at tilføje et par egenskaber til applikationerne bootstrap.yml konfigurationsfil:

forår: sky: hvælving: # andre hvælvingsegenskaber udeladt ... generisk: aktiveret: sandt programnavn: fakebank 

Ejendommen applikationsnavn er valgfrit i dette tilfælde. Hvis ikke angivet, antager Spring værdien af ​​standarden spring.application.name i stedet.

Vi kan nu bruge alle nøgle / værdipar gemt på hemmelighed / fakebank som enhver anden Miljø ejendom. Følgende uddrag viser, hvordan vi kan læse værdien af foo nøgle gemt under denne sti:

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

Som vi kan se, kender selve koden intet om Vault, hvilket er en god ting! Vi kan stadig bruge faste egenskaber i lokale tests og skifte til Vault, som vi vil ved blot at aktivere en enkelt ejendom i bootstrap.yml.

4.1. En note om forårsprofiler

Hvis tilgængelig i den aktuelle Miljø, Spring Cloud Vault bruger de tilgængelige profilnavne som et suffiks, der føjes til den angivne basissti, hvor der søges efter nøgle / værdipar.

Det vil også se efter egenskaber under en konfigurerbar standard applikationssti (med og uden profilsuffiks), så vi kan have delte hemmeligheder på et enkelt sted. Brug denne funktion med forsigtighed!

For at opsummere, hvis produktion profil af ud fakebank applikationen er aktiv, vil Spring Vault se efter egenskaber, der er gemt under følgende stier:

  1. hemmelighed/fakebank/produktion (højere prioritet)
  2. hemmelighed/fakebank
  3. hemmelighed / anvendelse / produktion
  4. hemmelighed / applikation (lavere prioritet)

På den foregående liste Ansøgning er det navn, som Spring bruger som standard yderligere placering for hemmeligheder. Vi kan ændre det ved hjælp af spring.cloud.vault.generic.default-context ejendom.

Egenskaber, der er gemt under den mest specifikke sti, har forrang for de andre. For eksempel hvis den samme ejendom foo er tilgængelig under stier ovenfor, så vil forrangsrækkefølgen være:

5. Brug af databasehemmelig backend

Database-backend-modulet giver Spring-applikationer mulighed for at bruge dynamisk genererede databaseoplysninger oprettet af Vault. Spring Vault injicerer disse legitimationsoplysninger i henhold til standarden spring.datasource.username og spring.datasource.password egenskaber, så de kan vælges regelmæssigt Datakildes.

Bemærk, at inden vi bruger denne backend, skal vi oprette en databasekonfiguration og roller i Vault som beskrevet i vores tidligere tutorial.

For at kunne bruge Vault-genererede databaseoplysninger i vores Spring-applikation, er spring-cloud-vault-config-databaser skal være til stede i projektets klassesti sammen med den tilsvarende JDBC-driver.

Vi er også nødt til at aktivere brugen i vores applikation ved at tilføje et par egenskaber til vores bootstrap.yml:

spring: cloud: vault: # ... andre egenskaber udeladt database: aktiveret: true role: fakebank-accounts-rw

Den vigtigste egenskab her er rolle egenskab, der har et databaserollenavn, der er gemt i Vault. Under bootstrap vil Spring kontakte Vault og anmode om, at det opretter nye legitimationsoplysninger med de tilsvarende privilegier.

Hvælvet tilbagekalder som standard de privilegier, der er knyttet til disse legitimationsoplysninger efter den konfigurerede time-to-live.

Heldigvis, Spring Vault fornyer automatisk lejekontrakten, der er knyttet til de erhvervede legitimationsoplysninger. Ved at gøre dette forbliver legitimationsoplysningerne gyldige, så længe vores ansøgning kører.

Lad os nu se denne integration i aktion. Følgende uddrag får en ny databaseforbindelse fra en Spring-administreret Datakilde:

Forbindelse c = datasource.getConnection (); 

Endnu en gang kan vi se, at der ikke er tegn på Vault-brug i vores kode. Al integration sker på Miljø niveau, så vores kode let kan testes som normalt.

6. Konklusion

I denne vejledning har vi vist, hvordan du integrerer Vault med Spring Boot ved hjælp af Spring Vault-biblioteket. Vi har dækket to almindelige anvendelsestilfælde: generiske nøgle / værdipar og dynamiske databaseoplysninger.

Et eksempel på et projekt, der indeholder alle krævede afhængigheder, integrationstest og opsætningsskripter til hvælving, er tilgængelige på GitHub.


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