Een inleiding tot Spring Cloud Vault

1. Overzicht

In deze tutorial laten we zien hoe we Hashicorp's Vault in Spring Boot-applicaties kunnen gebruiken om gevoelige configuratiegegevens te beveiligen.

We gaan ervan uit dat we hier enige Vault-kennis hebben en dat we al een testopstelling hebben. Als dit niet het geval is, laten we dan even de tijd nemen om onze Vault Intro-zelfstudie te lezen, zodat we kennis kunnen maken met de basisprincipes.

2. Spring Cloud Vault

Spring Cloud Vault is een relatief recente toevoeging aan de Spring Cloud-stack die stelt applicaties in staat op een transparante manier toegang te krijgen tot geheimen die zijn opgeslagen in een Vault-instantie.

Over het algemeen is migreren naar Vault een heel eenvoudig proces: voeg gewoon de vereiste bibliotheken toe en voeg een paar extra configuratie-eigenschappen toe aan ons project en we zouden goed moeten zijn om te gaan. Er zijn geen codewijzigingen vereist!

Dit is mogelijk omdat het een hoge prioriteit heeft PropertySource geregistreerd in de huidige Milieu.

Als zodanig zal Spring het gebruiken wanneer een eigenschap vereist is. Voorbeelden zijn onder meer Databron eigendommen, Configuratie-eigenschappen, enzovoorts.

3. Spring Cloud Vault toevoegen aan een Spring Boot-project

Om het spring-cloud-kluis -bibliotheek in een op Maven gebaseerd Spring Boot-project gebruiken we de bijbehorende beginner artefact, waarmee alle vereiste afhankelijkheden worden opgehaald.

Naast de belangrijkste beginner, we zullen ook de spring-vault-config-databases, die ondersteuning toevoegt voor dynamische databasereferenties:

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

De nieuwste versie van de Spring Cloud Vault-starter kan worden gedownload via Maven Central.

3.1. Basisconfiguratie

Om correct te werken, heeft Spring Cloud Vault een manier nodig om te bepalen waar contact moet worden opgenomen met de Vault-server en hoe zichzelf ertegen kan worden geverifieerd.

Dit doen we door de nodige informatie in het bootstrap.yml of bootstrap.properties:

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

De spring.cloud.vault.uri eigenschap verwijst naar het API-adres van Vault. Omdat onze testomgeving HTTPS gebruikt met een zelfondertekend certificaat, hebben we ook een keystore nodig met daarin de publieke sleutel.

Merk op dat deze configuratie geen verificatiegegevens heeft. Voor het eenvoudigste geval, waar we een vast token gebruiken, kunnen we het door de systeemeigenschap geven spring.cloud.vault.token of een omgevingsvariabele. Deze aanpak werkt goed in combinatie met standaard cloudconfiguratiemechanismen, zoals Kubernetes 'ConfigMaps of Docker-geheimen.

Spring Vault vereist ook extra configuratie voor elk type geheim dat we in onze applicatie willen gebruiken. In de volgende secties wordt beschreven hoe we ondersteuning kunnen toevoegen aan twee veelvoorkomende geheimtypes: sleutel / waarde en databasereferenties.

4. Gebruik van de Generic Secrets Backend

We gebruiken de Generic Secret-backend om toegang te krijgen onversioneerd geheimen die zijn opgeslagen als sleutel / waarde-paren in Vault.

Ervan uitgaande dat we de spring-cloud-starter-vault-config afhankelijkheid in onze klassenpad, alles wat we hoeven te doen is een paar eigenschappen aan de applicatie toe te voegen bootstrap.yml configuratiebestand:

spring: cloud: vault: # andere eigenschappen van de kluis zijn weggelaten ... generiek: ingeschakeld: echte toepassingsnaam: fakebank 

Het eigendom Naam van de toepassing is in dit geval optioneel. Indien niet gespecificeerd, neemt Spring de waarde van de norm over spring.application.name in plaats daarvan.

We kunnen nu alle sleutel / waarde-paren gebruiken die zijn opgeslagen op geheim / nepbank als elk ander Milieu eigendom. Het volgende fragment laat zien hoe we de waarde van de foo sleutel opgeslagen onder dit pad:

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

Zoals we kunnen zien, weet de code zelf niets over Vault, wat een goede zaak is! We kunnen nog steeds vaste eigenschappen gebruiken in lokale tests en overschakelen naar Vault als we willen door slechts één eigenschap in te schakelen bootstrap.yml.

4.1. Een opmerking over veerprofielen

Indien beschikbaar in de huidige Milieu, Spring Cloud Vault zal de beschikbare profielnamen gebruiken als een achtervoegsel toegevoegd aan het opgegeven basispad waar sleutel / waarde-paren zullen worden doorzocht.

Het zal ook zoeken naar eigenschappen onder een configureerbaar standaard applicatiepad (met en zonder een profiel-achtervoegsel) zodat we gedeelde geheimen op een enkele locatie kunnen hebben. Wees voorzichtig bij het gebruik van deze functie!

Om samen te vatten, als het productie profiel van uit nepbank applicatie actief is, zoekt Spring Vault naar eigenschappen die zijn opgeslagen onder de volgende paden:

  1. geheim/nepbank/productie (hogere prioriteit)
  2. geheim/nepbank
  3. geheim / applicatie / productie
  4. geheim / applicatie (lagere prioriteit)

In de voorgaande lijst, toepassing is de naam die Spring gebruikt als een standaard extra locatie voor geheimen. We kunnen het wijzigen met de spring.cloud.vault.generic.default-context eigendom.

Eigenschappen die onder het meest specifieke pad zijn opgeslagen, hebben voorrang op de andere. Bijvoorbeeld als dezelfde eigenschap foo is beschikbaar onder de paden hierboven, dan zou de prioriteitsvolgorde zijn:

5. Gebruik van de Database Secret Backend

Met de Database-backend-module kunnen Spring-applicaties dynamisch gegenereerde databasereferenties gebruiken die door Vault zijn gemaakt. Spring Vault injecteert die inloggegevens onder de standaard spring.datasource.username en spring.datasource.password eigendommen zodat ze kunnen worden geplukt door regelmatig Databrons.

Houd er rekening mee dat, voordat we deze backend gebruiken, we een databaseconfiguratie en rollen in Vault moeten maken, zoals beschreven in onze vorige tutorial.

Om door Vault gegenereerde databasereferenties te gebruiken in onze Spring-applicatie, moet de spring-cloud-vault-config-databases moet aanwezig zijn in het klassenpad van het project, samen met het bijbehorende JDBC-stuurprogramma.

We moeten het gebruik ervan in onze applicatie ook mogelijk maken door een paar eigenschappen toe te voegen aan ons bootstrap.yml:

spring: cloud: vault: # ... andere eigenschappen weggelaten database: enabled: true rol: fakebank-accounts-rw

De belangrijkste eigenschap hier is de rol eigenschap, die een databaserolnaam bevat die is opgeslagen in Vault. Tijdens het opstarten neemt Spring contact op met Vault en vraagt ​​het om nieuwe inloggegevens met de bijbehorende rechten te maken.

De kluis trekt standaard de rechten in die aan die referenties zijn gekoppeld na de geconfigureerde time-to-live.

Gelukkig, Spring Vault verlengt automatisch de lease die is gekoppeld aan de verkregen inloggegevens. Door dit te doen, blijven de inloggegevens geldig zolang onze applicatie actief is.

Laten we deze integratie nu in actie zien. Het volgende fragment krijgt een nieuwe databaseverbinding van een door Spring beheerd Databron:

Verbinding c = datasource.getConnection (); 

Nogmaals, we kunnen zien dat er geen teken is van Vault-gebruik in onze code. Alle integratie vindt plaats op het Milieu niveau, zodat onze code zoals gewoonlijk eenvoudig kan worden getest.

6. Conclusie

In deze zelfstudie hebben we laten zien hoe u Vault integreert met Spring Boot met behulp van de Spring Vault-bibliotheek. We hebben twee veelvoorkomende gebruiksscenario's behandeld: generieke sleutel / waarde-paren en dynamische databasereferenties.

Een voorbeeldproject met alle vereiste afhankelijkheden, integratietests en kluisinstallatiescripts is beschikbaar op GitHub.


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