Securely storing secrets of a Spring Boot application in HashiCorp Vault?

Could you please explain why it is safe?

The answer is that it is NOT safe ... if you do it that way. For example, the Spring Vault reference manual says:

"Consider carefully your security requirements. Static token authentication is fine if you want quickly get started with Vault, but a static token is not protected any further. Any disclosure to unintended parties allows Vault use with the associated token roles."

You should either protect your static tokens, or only grant them access to "secrets" in the vault which you are happy to be widely known.

Alternatively, have your application use an authenticated method to generate short-term dynamic tokens.

As I understand initial problem it is bad to store passwords in an application.properties file on Github.

And storing a static Vault token in an application.properties file on Github is equally as bad.

What is the difference ?

There is almost no difference¹. This is simply the wrong way to use Vault.

^{1 - There is a small advantage in that you could invalidate the token if you discover it leaked by accident. But this doesn't mean that it is sensible to publish it deliberately.}

So how do you do things securely?

First, you MUST secure the machines where the secrets are going to be used. Even if you are not going to store the actual secrets on disk, you will need to store a different secret (securely) on each of your machines so that they can authenticate themselves to the place where the real secrets are kept.

Here is an example using Chef.

1. Set up a secure Chef server that holds the configs for your machines; i.e. recipes for all of the things that need to be installed, node descriptions to say what recipes to apply, etc.

2. When you bootstrap a machine as a node, a keypair is generated for the machine and registered with the Chef server. The keypair is also held on the machine, and has to be held securely.

3. Then you use the Chef client to run the recipes that install and configure your server.

Note that this relies on having a properly secured system to run the Chef server. It also relies on each of the nodes being sufficiently secure to protect their own keys.

There are other ways to do this, but nothing will work if you cannot secure your host sufficiently.

Storing spring.cloud.vault.token in the application.properties that is checked into VCS (e.g. Git) might compromise all secrets stored in Vault.

The solution is not to store Vault token in application.properties as a plain text. There are several options.

Remove Vault token from application.properties

Simply remove spring.cloud.vault.token from application.properties and instead provide it via system property -Dspring.cloud.vault.token=00000000-0000-0000-0000-000000000000 (when starting the application) or environment variable SPRING_CLOUD_VAULT_TOKEN. Environment variable is especially convenient if you use containers (Docker or Kubernetes).

Store encrypted Vault token in application.properties

You can keep spring.cloud.vault.token property in application.properties if it is encrypted.

Spring Cloud Config supports decrypting properties with values starting with {cipher}:

spring.cloud.vault.token={cipher}encrypted_vault_token

To use properties encryption and decryption you will need the following dependencies (example for Gradle):

implementation 'org.springframework.cloud:spring-cloud-context:2.2.2.RELEASE'
implementation 'org.bouncycastle:bcprov-jdk15on:1.64'

Symmetric encryption

The simplest way to encrypt the properties is to use symmetric encryption.

Come up with a symmetric key (for example s3cr3t).

To encrypt Vault token you can use Spring Boot CLI with Spring Boot Cloud CLI:

curl "https://repo.spring.io/release/org/springframework/boot/spring-boot-cli/2.2.2.RELEASE/spring-boot-cli-2.2.2.RELEASE-bin.tar.gz" -o spring-boot-cli-bin.tar.gz
tar -xf spring-boot-cli-bin.tar.gz
cd spring-2.2.2.RELEASE
bin/spring install org.springframework.cloud:spring-cloud-cli:2.2.1.RELEASE

bin/spring encrypt 00000000-0000-0000-0000-000000000000 --key s3cr3t
# 507cd1614682535ab8237b448ca73dc74058d3ae9145d63a7381ee67f3046eb1598da6960abdbf2dbf22c47206db5222e45fc74fd6122bc707b61c62f5051e0f

bin/spring decrypt 507cd1614682535ab8237b448ca73dc74058d3ae9145d63a7381ee67f3046eb1598da6960abdbf2dbf22c47206db5222e45fc74fd6122bc707b61c62f5051e0f --key s3cr3t
# 00000000-0000-0000-0000-000000000000

Pass the symmetric key to the application in ENCRYPT_KEY environment variable.

Symmetric encryption key must be never checked into a VCS.

Asymmetric encryption

Consider asymmetric encryption using public and private key pair as a more secure alternative to symmetric encryption.

Instead of a symmetric encryption key you need to generate a keystore (using the keytool utility that comes with the JDK or openssl).

In the bootstrap.properties specify the following properties:

• encrypt.keyStore.location
• encrypt.keyStore.password
• encrypt.keyStore.alias
• encrypt.keyStore.type

The keystore has to be mounted at the location specified in encrypt.keyStore.location and never checked into a VCS.

Also, password that unlocks the keystore better to pass in ENCRYPT_KEYSTORE_PASSWORD environment variable.

Read about key management in Spring Cloud Config.

Answering your questions

Could you please explain why it is safe?

It is not safe! Never put a plain secret in source control.

As we found out it is insecure. How to make it secure?

Some ways to increase security:

• Use environment variables instead of properties file;
• Restrict the access at the network level to the Vault server only to workload servers. This guarantees that nobody outside that network can exchange the token;
• Vault works generating real but temporary credentials each time the token is used. Reduce the scope of the real credentials to read-only whenever be possible;
• Rotate the token regularly.

Regarding the Spring specifics

The bootstrap properties should contain only non-critical properties. For critical properties, you can pass them to the application using environment variables.

spring.cloud.vault.token = ${SPRING_CLOUD_VAULT_TOKEN}

Summary

The question remains "Who guards the keys?". But the Vault Token serves actually to protect the real sensitive data. In case the vault token is leaked, you can invalidate just the token.

Improve the constraints from where applications can access the vault server and reduce the scope of the real credentials are additional ways to ensure that only the servers that run the application can exchange the tokens by the real credentials and the real credentials have the minimum privilege as possible.