Hot questions for Spring Cloud Vault Config

Top 10 Java Open Source / Spring / Spring Cloud Vault Config

Question:

I wanted to test Spring Cloud Vault configuration.

I installed a Vault server locally and when i try to write some key-values its failing and asking me to use vault kv put command.

While the example of Spring Cloud Config in this link shows the usage of vault write command

This is the error i get is

$ vault write secret/my-app foo=bar
Error writing data to secret/my-app: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/secret/my-app
Code: 404. Errors:


WARNING! The following warnings were returned from Vault:

  * Invalid path for a versioned K/V secrets engine. See the API docs for the
  appropriate API endpoints to use. If using the Vault CLI, use 'vault kv put'
  for this operation.

Answer:

Try the following ..

./vault kv put secret/my-app password=123

I'll add that this is something new in 0.10.0.

Seems like 0.10.0 has some breaking API changes ... so solution #2 is to use an earlier version of Vault (v0.9.6). This includes defaulting to the v2 of the KV secret engine , which is versioned.

Solution #3 is to re-create the /secret engine with v1 of KV. Running the following:

./vault secrets disable secret 
./vault secrets enable -version=1 -path=secret kv

Question:

I am currently integrating Spring Cloud Vault Config into a Spring Boot application. From the home page:

Spring Cloud Vault Config reads config properties from Vaults using the application name and active profiles:

/secret/{application}/{profile}
/secret/{application}
/secret/{default-context}/{profile}
/secret/{default-context}

I would like to instead provide my own location from which to pull properties from Vault which does not start with /secret (e.g. /deployments/prod). I've been looking through the reference documentation but I haven't found anyway to specify this -- is it possible?


Answer:

I was able to use the Generic Backend properties to massage the paths into what I was looking for. Something like:

spring.cloud.vault:
    generic:
        enabled: true
        backend: deployments
        profile-separator: '/'
        default-context: prod
        application-name: my-app

This will also unfortunately pickup Vault locations like deployments/my-app and deployments/prod/activeProfile so be careful not to have any properties in these locations that you don't want to be picked up.

It looks like there is a desire (and an implementation) to allow for these paths to be specified more programmatically.

Question:

I am using Spring Cloud Vault Library to access my Secrets from the Vault server.

Currently I am storing all the parameters, such as role-id, secret-id, host, port, etc..., as Environment Variables and then injecting that in to my bootstrap.yml of my Spring-boot App. Below is my YAML file

spring:
 cloud:
    vault:
      authentication: APPROLE
      app-role:
        role-id: ${role-id}
        secret-id: ${secret-id}
      host: ${host}
      port: ${port}
      scheme: ${scheme}

Where I am stuck is with Managing the Vault's Role-Id & Secret-Id. Obviously, Vault is no good at protecting our secrets if people can easily get their hands on these 2 pieces of information – they are indeed secrets themselves.

What is the Industry best practice to have Role-Id and Secret-Id protected ? We already brainstormed ideas like storing-in-config-server, storing-in-environment-variable, storing-in-cloudfoundry-UPS ..

Nevertheless we would like to understand the best practice on this ..


Answer:

I faced to the same problem and here's what you can do. First of all, application should have defined own system user and it should be launched as that user. Then in the same directory as your jar/war file you can make bootstrap.properties file containing:

spring.cloud.vault.app-role.secret-id=*your-secret-for-role-id*

Here's ls output example:

-rw-------. 1 app app bootstrap.properties
-rwxr--r--. 1 app app app.jar

Application user has to be an owner of this properties file and only him should be permited to read bootstrap.properties. This protects your secret from unauthorized access unless you have root or application user permissions.