TIL: Storing (non-RDS) Database Credentials in AWS Secrets Manager
Today I learned that AWS Secrets Manager enables you to store the login credentials and connection information for a database in a single secret. I'm not sure how I missed this earler!
Now, just to note up front, it doesn't seem like this is a new development; in fact, there's a good chance this feature has been available since Secrets Manager was released - somehow I didn't see it earlier.
Background
AWS Secrets Manager is one of a growing number of services[1] for handling your org/app's sensitive information. Unsurprisingly, it plays nicely with other AWS services - I first encountered Secrets Manager when I needed to securely provide database credentials to AWS Lambda, along with a few external apps.
Lately I've become interested in utilizing Secrets Manager more extensively, even though we're not "all-in" on AWS for our infrastructure. I appreciate how Secrets Manager reduces the number of environment variables and secrets I need to load up into Docker Swarm. Instead, I can use a properly permissioned[2] AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to retrieve all the necessary secrets (API keys, database credentials, etc) while bootstrapping an application. Additional benefits include auditing and managing access to secrets.
Previous Approach: Multiple Secrets
When I first used Secrets Manager, I set up separate secrets for the database username and password. Each secret was created using the "Other type of secret" option:
I then stored the additional connection information (host, database name, port) as secure strings in AWS Systems Manager Parameter Store.
With this approach, I had five values I needed to retrieve to set up a database connection. In hindsight this seems like a pain, but if I'm being honest, the approach worked, and I didn't have any real complaints about it - until I learned that it could be done much more easily.
Storing All Database Information in a Single Secret
Today, I learned that when creating a secret, if you select the option "Credentials for other database", you get a different interface:
Here, within one secret, you're able to store the database:
- Username
- Password
- Engine
- Host (Server address)
- Port
- Name
Which is to say, everything that you need to initiate a database connection.
This is super convenient! Fewer secrets to manage; fewer HTTP requests to access secrets; centralized management of connection information.
Footnotes
Other examples include Hashicorp Vault, Doppler, and 1Password Secrets Automation. While I'm interested in all of them, I haven't had the chance to try them out. ↩︎
Not a word, but should be. ↩︎
