Spring Boot Externalized Database Configuration with AWS Secrets Manager

Achieve high availability, scalability, and simplicity

Photo by Pablo Arroyo on Unsplash

Introduction

In this tutorial, we’ll be going through the step-by-step integration of Spring Boot’s database configuration with AWS Secrets Manager.

Let’s discuss some context first before diving into the implementation details.

Context

As we are all familiar with, one of the most common ways to set Spring Boot’s database configuration is using the application properties. To some, changing the database passwords might be a few and far between; however, to be on the safe side, it’s always better to do it periodically.

Traditionally, changing database passwords means restarting the service after applying changes to the application properties (also possible with environment variables). The more frequently we do it, the more likely we introduce service disruptions to users.

Fortunately, by integrating AWS Secrets Manager, there’s no need to restart the service whenever we change the database password. It even provides an automatic periodical password rotation option.

Step 1: Creating Database Credentials in AWS Secrets Manager

Head over to AWS Console and search for “Secrets Manager.” Then, proceed with the succeeding steps until the secret is created.

Step 2: Add the Necessary Dependencies in pom.xml

Note: The spring-boot-starter-data-jpa dependency is interchangeable with spring-boot-starter-jdbc. Feel free to change it based on your setup.

Step 3: Configure the Application Properties File Accordingly

First, for the driver-class-name property, we used AWSSecretsManagerPostgreSQLDriver class. Notice that it is from aws-secretsmanager-jdbc dependency.

Next, for the spring.jpa.database-platform property, we used PostgreSQLDialect from postgresql dependency.

Next, it’s worth pointing out the change in prefix for the datasource url, which is now jdbc-secretsmanager.

Lastly, for the datasource username, we used the secret name from AWS Secret Manager.

Step 4: Check the Server’s Database and Secrets Manager Connectivity

For the Database Connectivity, try connecting using the psql command:

Here are a few errors we might encounter:

• psql not installed: Feel free to install it using your instance package manager.
• Connection timeout: Ensure that the EC2 instance and database are on the same VPC. Additionally, attach the database’s security group to the EC2 instance — This will give access to the server to connect to the database.

For the Secrets Manager Connectivity, again using the aws-cli, try to list the secrets:

Here are a few errors we might encounter:

• The region is not defined: Use the aws configure to set it up. Meanwhile, one might skip the part related to secret keys as it isn’t generally safe to store keys in the server’s instance.
• The EC2 instance does not have access to AWS Secrets Manager: For a more secured approach, rather than configuring the secret keys directly within the EC2, create a role with a read access policy to Secrets Manager; then, attach it to the EC2 instance.

Lastly, Run the Application and Test its Database Connectivity

Based on the logs, we can confirm successful connectivity with the database. Moreover, if we try to rotate the password, we’ll still be able to connect to the database without any downtime due to the caching mechanism in AWS Secrets Manager.

That’s it! As always, feel free to review the source code for this demo on Github.