CODEWITHSUNDEEP
spring-boothashicorp-vaultspring-vaultspring-cloud-vault-config
Chris
Chris

Reputation: 4648

What's the safest way to get the Vault Token for local development with Spring Boot / Spring Cloud Vault

When running Spring Boot locally, I'm using the default TOKEN based authentication with the spring-cloud-starter-vault-config dependency.

Running vault login -method oidc saves a fresh vault token to ~/.vault-token with a certain TTL.

Spring Cloud Vault then automatically picks up the token from that file. No further Spring Boot configuration is needed.

What I like about this solution is it's simple and works automatically for everyone in my team, as long as they have Vault CLI installed on their machines.

Is there any other similarly elegant solution that wouldn't depend on saving the token in plain text in a text file on every developer machine? E.g. can spring cloud vault be combined with Vault CLI's token_helper scripts?

Upvotes: 0

Views: 382

Answers (1)

ixe013
ixe013

Reputation: 10171

Spring will pick up the Vault token wherever it can find it, much like the Vault command line. So after a developer runs vault login -method oidc and answers the prompts, the Vault token associated with the user they logged in with is stored in plain text in ~/.vault-token.

You might have your attack scenario wrong. A token-helper that encrypts the token already exists, but assuming it works with Spring, one could just run vault-token-helper get to retrieve the token in plain text. I think vault print token still works, but I could not find the documentation for it.

So it really boils down to having the developer authenticate to Vault on their own. Let's work on which Vault instance they authenticate to.

An elegant solution is for developers to run their own copy of Vault locally, with a script to provision it with secrets and other back ends. A bash script that runs everything on bare metal, docker compose up or some other private instance could provision a myapp user (not root) as an AppRole with a well known custom secret-id and enough secrets in Vault for them to do their development work.

Developers would only have to vault login --method approle --role-id myapp --secret-id not_a_secret_its_test_data once. Personally I prefer to add --no-store and use the VAULT_TOKEN environment variable in the Java process. YMMV.

Upvotes: 0

Related Questions