How to Integrate Your Application with Vault: Static Secrets

The Vault Developer Experience team has introduced three versions of a sample application in C#, Go, and Java to demonstrate using Vault in a real-world environment. These are cloneable, out-of-the-box examples that require no previous knowledge of Vault. You can explore the codebase to learn about Vault concepts, tinker with the app, or copy and paste the code into your own application.

In the following video we demonstrate the app running in C#, Go, and Java, describe the microservice architecture, and show how to work with the code:

You can find the cloneable sample applications in your chosen language below:

• Go
• C#
• Java (Spring)

Note that this is the first in a series of posts that will cover multiple core Vault features in depth using this sample application. These features will include:

• Static secrets
• Dynamic secrets
• Authentication
• Token renewal

Let’s start by looking at static secrets.

»A Web App Without Vault

Suppose you're developing a web application that needs to fetch information from another service via an API, as pictured here:

The web app must provide an API key to authenticate with the target service (secure server). This introduces the challenge of securely storing the API key. The API key is inherently sensitive, so you want to refrain from checking it into your source control. Ideally, the web app retrieves the API key when it needs to make a call to the service to avoid storing it in the application for longer than necessary. This also lets an operator manage and update your API key without developer involvement.

»Adding Vault Static Secrets

This is where Vault static secrets can come into play. Vault can encrypt and store your API key in its persistent storage. This will allow our web application to retrieve the API key only when it needs to make a call to the API, eliminating the need to store it in an environment variable or config file. It’s also assumed the retrieval will happen over a secure channel (e.g. TLS); protecting the API key from being stolen in transit.

The architecture diagram above shows the addition of our Vault server where we can store our API key. Vault requires users and machines to authenticate with an auth method before interacting with Vault. (We’ll address authentication in a future blog post.)

Vault provides many secrets engines to store secrets. We will be using the Key/Value secrets engine. When we add the API key to our Key/Value secrets engine, it gets stored in Vault at a specific path (e.g. “kv-v2/data/api-key”). We can write multiple key-value pairs at the given path. Then, when we read the secret in our application, we can retrieve it via that same path.

The sample application demonstrates the Vault client (web app) code to read secrets stored in Vault.

»Running the Sample Application

Once you’ve cloned the sample application in your chosen language, you can easily get started by running the run.sh file in the “sample app” directory. This run file will spin up our docker-compose that contains all of the components necessary for our application. Our setup files run all of the operator-style commands and configuration of Vault. This includes creating policies, enabling our key-value store, and adding our API key as a secret. You may notice several setup scripts in the repo, including setting up a “trusted orchestrator.” These components will be covered in future blog posts.

To play around with the static secrets workflow you can curl our payments endpoint, which will make a request to the secure server using the API key that was stored in Vault. You can also edit the code to write and retrieve a new secret from the application.

»More Learning Resources

For additional resources, the Developer Quick Start guide is a great step-by-step approach to interacting with Vault from an application. The HashiCorp Learn Vault section is another great resource, with tutorials demonstrating secrets management.