When you're working with any secret inside of the cloud or even on-prem, there are a few things you think about:
The first two questions are easily achievable with any secret store.
The second two aren't.
In this blog post, you'll see the idea behind using a platform like CloudTruth to make storing secrets, retrieving secrets, and rotating secrets easier.
SSM is used by a lot of organizations to make managing and utilizing secrets a bit cheaper. You can utilize parameters and store them as secure strings to ensure that the values are encrypted.
As you can see in the code below, it's a simple command to get a value stored properly.
aws ssm put-parameter \
--name "testparameter" \
--value "SuperSecretPassword" \
--type SecureString
However, there are a few problems with the above.
First, you have to store your original value in plain text. Although it'll be stored securely in AWS, you still have to pass it in via the CLI in an unsecured fashion.
Second, you have to do this for each environment. You're forced to use the CLI for each environment (Dev, Staging, Prod, etc.) or the UI. In any case, it can become incredibly cumbersome.
Third, if you want to rotate secrets (as you should), you must do it for each environment.
Although the command is straightforward, getting the environment with the secrets up and running can be cumbersome, manual, and repetitive.
Thinking about the next option is AWS Secrets Manager.
Secrets Manager allows you to create, rotate, and store secrets in AWS. However, the same problems as with SSM rises with Secrets Manager.
When you're creating a new secret, it'll look something like this.
You'll first log into AWS and go to the Secrets Manager Service.
Next, you'll create a new secret.
When you create the new secret, you'll choose the service you're creating the secret for, along with the values.
With this workflow, you have no central location to manage, update, or utilize secrets.
This is where CloudTruth comes into play.
With CloudTruth, you don't have to worry about using multiple CLI tools or clicking around throughout the AWS UI to get to the service pages for Secrets Manager and SSM. Instead, you have one location, CLI, and API to work with. All your secrets, even outside of AWS, are in one location.
If you're in an environment with on-prem and/or multiple clouds, you don't have to worry about using multiple UIs and CLIs to manage your secrets across environments. Instead, CloudTruth is used as the central hub for every secret.
Let's see how it's done.
First, you'd log into the CloudTruth UI and, under Integrations, click on Explorer.
Next, choose the integration path. In this case, it can be AWS.
You'd then choose your region.
You can see and use secrets in SSM and Secrets Manager under one location.
You can then click on a secret to see its value and ensure it's the correct secret to use.
After that, you can create a new parameter utilized as a secret.
You can then use an external source to fetch the secrets in SSM or Secrets Manager for any configuration you need via CloudTruth.
AWS SSM and Secrets Manager are great solutions. They provide "out of the box" value and are used by thousands of organizations. The primary concern is the management aspect of the secrets within SSM and Secrets Manager. You have to click around multiple UIs and use multiple commands to work with them. If you have different cloud or on-prem environments, you have to use multiple tools to manage them.
With CloudTruth, all environments are under one roof. Managed with one UI, one CLI, and one API.