Spring Cloud Services Supports Vault & Multiple Backends: Use the Right Config Repo for the Job!

June 6, 2017 Chris Sterling

Enterprises continue to mature and advance their microservices architectures. Developers want high availability across many sites. And they want to connect services with a flexible, secure service fabric.

Customers also need to bifurcate access to application configuration. Operators want a secure repo for sensitive information like credentials and API keys. Hashicorp Vault is one popular tool for protecting this sensitive information.

Meanwhile, developers want frictionless control over configuration data (like feature toggles and environment information). Git repositories are ideal for this purpose.

What if there was a way for product teams to co-mingle Vault and Git as a config store? This would give each engineer the right level of access for their role.

Spring Cloud Services 1.4, now generally available, does just that! Config Server now supports HashiCorp Vault and Multiple Backends. Let's dig into the details.

HashiCorp Vault Support

HashiCorp Vault is a secrets management tool for distributed systems. It encrypts and stores credentials, API keys, and other sensitive information. Vault supports access control lists, secret revocation, auditing, leases, and renewals. Operators trust this tool with precious secrets. And for good reason!

Spring Cloud Services Config Server now serves configuration properties stored in Vault.

config-server-vault-support.pngHow do you go about getting Vault and Config Server to work together? Easy - provide the Vault server information when you create a new Config Server instance.

Here's an example using the Cloud Foundry CLI.

$ cf create-service p-config-server standard my-config-server -c ‘{ "vault": { "scheme": "https", "host": "vault.example.com", "port": "8200" } }’

The new Config Server instance will then serve properties from a Vault server. And it will do so via SSL at vault.example.com on port 8200. But it will only serve up this data when given a valid client token that is provided by the client application. This token is usually generated by a Vault server administrator and subsequently provided to developers.

NOTE: Spring Cloud Services does not deploy a HashiCorp Vault server. You will need to deploy your own Vault server independently to use this feature.

Spring Cloud Services Connector 1.5.0 supports this integration too. Now you can set the SPRING_CLOUD_CONFIG_TOKEN environment variable.

Let's say your application includes the appropriate client dependencies. When you push the app to Pivotal Cloud Foundry, use the following command to set the client token environment variable:

$ cf set-env config-vault-app SPRING_CLOUD_CONFIG_TOKEN [TOKEN VALUE]

Ready to learn more? Check out the Config Server documentation on using a Vault token.

Multiple Backends

The Spring Cloud Dalston.RELEASE includes support for multiple backends within a single Config Server instance. We’ve taken this open-source capability and added a declarative approach to ease the configuration of multiple backends. The diagram below shows how it works.

config-server-composite-backends.png

This setup solves our scenario from above. Teams can use their preferred config store: ops can use Vault, and devs can use Git repos. Best of all, each repo is managed with Config Server!

Here's an example of how to setup a Config Server instance with multiple backends:

$ cf create-service p-config-server standard my-config-server -c ' { "composite": [ { "vault": { "scheme": "https", "host": "vault.example.com", "port": "8200" } }, { "git": { "uri": "https://github.com/spring-cloud-samples/config-repo" } } ] }'

Spring Cloud Services 1.4 introduces a new JSON configuration key “composite” that takes an array of backends. The above Config Server instance pulls property values from the Vault backend first. Then, it pulls data from the Git repository backend, if the property was not found in Vault.

Keep Up With The 12 Factors at Scale

The 12 factors of modern application development remain as relevant as ever. Some factors are a little harder to adhere to as the volume of microservices grows. Thanks to Spring Cloud Services 1.4, sticking to the 3rd factor - store config in the environment - is a little easier.

Ready to learn more? Check out the detailed documentation at the links below.

Download Spring Cloud Services 1.4 from Pivotal Network.

 

About the Author

Chris Sterling

Chris Sterling is Principal Product Manager for Spring Cloud Services at Pivotal (https://www.pivotal.io). Chris published the book Managing Software Debt: Building for Inevitable Change with Addison-Wesley in 2010 to provide a framework for teams and organizations to assess and manage debt in their software systems. Chris has successfully supported organizational transformation across multiple verticals with organizations of 10 up to 800 people. Chris co-founded a company in 2009 called Agile Advantage focused on solving portfolio management problems to leverage the value that Agile teams can deliver, which lead to a successful acquisition by Rally Software. Chris brings his diverse experience and deep passion for technology when presenting on topics such as Continuous Delivery, Cloud Native architecture, DevOps, Lean and Agile.

Follow on Twitter More Content by Chris Sterling
Previous
Better Threat Detection and Response with Analytics for Lateral Movement
Better Threat Detection and Response with Analytics for Lateral Movement

To better understand anomalous user behaviors, enterprises increasingly complement their security portfolio...

Next
Democratizing the Logical Data Warehouse: The End of Analytics Lock-In
Democratizing the Logical Data Warehouse: The End of Analytics Lock-In