Java Application Demo
Once you have learned the fundamentals of Vault, the next step is to start integrating your system with Vault to secure your organization's secrets.
This tutorial is a companion to a webinar that includes a live demo of how to manage secrets, access, and encryption in the public cloud with Vault.
The Java application in this demo leverages the Spring Cloud Vault library which provides lightweight client-side support for connecting to Vault in a distributed environment.
Challenge
Incidents of data breaches which expose sensitive information make headlines more often than we like to hear. It becomes more and more important to protect data by encrypting it whether the data is in-transit or at-rest. However, creating a highly secure and sophisticated solution by yourself requires time and resources which are in demand when an organization is facing a constant threat.
Solution
Vault centralizes management of cryptographic services used to protect your data. Your system can communicate with Vault easily through the Vault API to encrypt and decrypt your data, and the encryption keys never have to leave the Vault.

Prerequisites
This lab was tested on macOS using an x86_64 based processor. If you are running macOS on an Apple silicon-based processor, use a x86_64 based Linux virtual machine in your preferred cloud provider.
To perform the tasks described in this tutorial:
- Install HashiCorp Vagrant
Step 1: Review the demo application implementation
Retrieve the configuration by cloning or downloading the [hashicorp/vault-guides] repository from GitHub.
Clone the repository.
Or download the repository.
This repository contains supporting content for all of the Vault learn tutorials. The content specific to this tutorial can be found within a sub-directory.
The source code can be found under the src/main
directory.
The demo Java application leverages the Spring Cloud Vault library to communicate with Vault.
In the TransitConverter
class, the convertToDatabaseColumn
method invokes a
Vault operation to encrypt the order
. Similarly, the
convertToEntityAttribute
method decrypts the order
data.
The VaultDemoOrderServiceApplication
class defines the main
method.
The OrderAPIController
class defines the API endpoint (api/orders
).
Step 2: Deploy and review the demo environment
For this tutorial, you are going to provision a Linux machine locally using Vagrant. However, the GitHub repository provides supporting files to provision the environment demonstrated in the webinar.

Now let's run the demo app and examine how it behaves.
To keep it simple and lightweight, you are going to run a Linux virtual machine locally using Vagrant.
In the vault-guides/secrets/spring-cloud-vault/vagrant-local
folder,
a Vagrantfile
is provided which spins up a Linux machine where the demo
components are installed and configured.
First, change the working directory to vagrant-local
.
Create and configure a Linux machine. This takes about 3 minutes.
Finally, connect to the demo machine.
There are 3 Docker containers running on the machine: spring
, vault
, and postgres
.
Task 2: Examine the Vault environment
During the demo machine provisioning, the /scripts/vault.sh
script was
executed to perform the following:
- Created a policy named
order
- Enabled the
transit
secrets engine and created an encryption key namedorder
- Enabled the
database
secrets engine and created a role namedorder
View the vault
log:
Notice that the log indicates that the Vault server is running in the dev
mode, and the root token is root
.
You can visit the Vault UI at http://localhost:8200/ui. Enter root
and
click Sign In.
Select the transit/
secrets engine, and you should find an encryption key
named order
.
Under the Policies, verify that the order
policy exists.
This order
policy is for the application. It permits read
on the
database/creds/order
path so that the demo app can get a dynamically generated
database credential from Vault. Therefore the PostgreSQL credentials are not
hard-coded anywhere.
An update
permission allows the app to request data encryption and decryption
using the order
encryption key in Vault.
Task 3: Examine the Spring container
Remember that the VaultDemoOrderServiceApplication
class logs messages during
the successful execution of initIt()
:
Verify that the log indicates that the demo app obtained a database credentials from Vault successfully:
Create a new shell session in the spring
container.
Review the bootstrap.yaml
file:
The client token was injected into the spring
container as an environment
variable (VAULT_TOKEN
) by Vagrant.
Enter exit
to close the shell session in the spring
container.
Task 4: Examine the PostgreSQL database
Connect to the PostgreSQL database running in the postgres
container:
Let's list the existing database roles.
Notice that there is a role name starting with v-token-order-
which was
dynamically created by the database secrets engine.
Note
To learn more about the database secrets engine, read the Secrets as a Service: Dynamic Secrets tutorial.
Enter \q
to exit out of the psql
session, or you can open another terminal
and SSH into the demo virtual machine.
Step 3: Run the demo application
If everything looked fine in Step 2, you are ready to write some data.

You have verified in the spring
log that the demo app successfully retrieved a
database credential from the Vault server during its initialization.
The next step is to send a new order request via the demo app's orders API (http://localhost:8080/api/orders).
Create a file payload.json
with the following contents.
Send the file in a request using cURL.
You should see this output:
Note
Alternately, you can use tool such as Postman instead of cURL to invoke the API.
The order data you sent gets encrypted by Vault. The database only sees the ciphertext. Let's verify that the order information stored in the database is encrypted.
In this demo, Vault encrypts the customer names; therefore the values in the
customer_name
column do not display the names in a human readable manner
("John").
Now, retrieve the order data via the orders API:
The output should look like this:
The customer names should be readable. Remember that the order
policy
permits the demo app to encrypt and decrypt data using the order
encryption
key in Vault.
Web UI
Vault UI makes it easy to decrypt the data.
In the Secrets tab, select transit > orders, and select Key actions.
Select Decrypt from the transit actions. Now, copy the ciphertext from the
orders
table and paste it in.Click Decrypt.
Click Decode from base64 to reveal the customer name.
Step 4: Reloading the Static Secrets
Now, let's test another API endpoint, api/secret
provided by the demo app.
A plain old Java object, Secret
defines a get method for key
and value
.
The SecretController.java
defines an API endpoint, api/secret
.
Remember from Step 2 that the
order
policy granted permissions on the secret/spring-vault-demo
path.
The demo app retrieved the secret from secret/spring-vault-demo
and has a
local copy. If someone (or perhaps another app) updates the secret, it makes the
secret held by the demo app to be obsolete.

Spring offers Spring Boot Actuator which can be used to facilitate the reloading of the static secret.
Task 1: Read the secret
The initial key-value was set by Vagrant during the provisioning. (See the
Vagrantfile
at line 48.)
Let's invoke the demo app's secret API (api/secret
).
The output should look like this:
This is the secret that the demo app knows about.
Task 2: Update the Secrets
Now, update the secret stored in Vault using the API.
Verify that the secret value was updated.
The output will include a large data structure which starts with the following:
Task 3: Refresh the secret on the demo app
Run the demo app's secret API again:
You'll see this output:
The current value stored in Vault is now my-api-key
; however, the demo app
still holds hello-vault
.
Spring provides an
actuator
which can be leveraged to refresh the secret value. At line 54 of the
vault-guides/secrets/spring-cloud-vault/pom.xml
, you see that the actuator was
added to the project.
Let's refresh the secret using the actuator:
Read back the secret from the demo app again:
It should display the correct value.
When you are done exploring the demo implementation, you can destroy the virtual machine:
In the webinar, the demo environment was running in a public cloud, and Nomad
and Consul were also installed and configured. If you wish to build a similar
environment using Kubernetes, the assets in the vault-guides/secrets/spring-cloud-vault/kubernetes
folder provides you with some guidance.