Security is an important aspect of any infrastructure especially for infrastructures in the Cloud. However, best security practices regarding parameters and secrets often are overlooked during fast and iterative application deployment cycles. Wouldn’t it be nice if AWS had managed services to help with store parameters and secrets while keeping security best practices intact? You’re in luck!
One such service is SSM Parameter Store which is a secured and managed key/value store perfect for storing parameters, secrets, and configuration information. However, in April of 2018, AWS also introduced another service called AWS Secrets Manager that offers similar functionality. Given that both services kind of do the same thing, which to choose isn’t clear. With that in mind, let us take a look at the similarities and differences of these two services to better understand which service will best fit your architectural needs.
Similarities
Managed Key/Value Store Services
As mentioned earlier there are many similarities between these two services. Both of these services offer a solution to store values under a name or key. Both services can store values up to 4096 characters and allow the keys to have prefixes. Similar to S3, both SSM Parameter Store and AWS Secrets Manager allow you to prefix parameter names. For example, parameters or secrets can be put in the following prefix schema application/environment/parameter name or any other combination of prefixes that meets the need of the application. This is useful since the deployment of the application can reference different parameters/secrets based on the environment it is deploying to.
Similar Encryption Options
Both services can leverage AWS KMS to encrypt values. By using KMS, IAM policies can be configured to control permissions on which IAM users and roles have permission to decrypt the value. Though access to the values can be restricted through IAM, encryption provides an additional layer of security and is sometimes required for compliance.
SSM Parameter provides an option to store values in plaintext or encrypt it with a KMS key. AWS Secrets Manager only stores encrypted data (otherwise it would not be a secret if the value was stored in plaintext; it would be an unsecured parameter). The article found HERE describes in greater detail on how AWS Secrets Manager encrypts its secrets. Similarly, SSM Parameter store encryption documentation can be found HERE.
Both Referenceable in Cloud Formation
Writing on how SSM Parameter Store and AWS Secrets Manager interact with CloudFormation can be a whole separate article. However, the summary is that values from both services are referenceable in CloudFormation templates allowing you to not hard code secrets or other dynamic values. For example, when creating an RDS instance through CloudFormation it is poor practice to hard code the master password in the CloudFormation script. What can be done instead is that the master’s username and password can be stored in secret and CloudFormation can reference that secret during the provisioning of the RDS resource. This way the CloudFormation script has only a pointer to where the password is located instead of containing the password in plaintext.
Similarly, other parameters (not just password) can be referenced the same way to provide more dynamic CloudFormation scripts. The article found HERE provides more information on how to use parameters or secrets in AWS CloudFormation.
Versioning
Both services support the versioning of secret values. This allows you to view previous versions of your parameters of secret in case you needed them. You can choose to restore the older version of the parameter.
Parameter Store only allows one version of the parameter to be active at any given time.
Secrets Manager allows multiple versions to exist at the same time when you are performing a secret rotation using the staging labels.
Differences
Password Generation
Though the services are similar, there are also a number of differences between them. The first difference is that AWS Secrets Manager is able to generate random secrets through the AWS CLI or SDK. For example, when creating a new RDS instance through a CloudFormation template, you can also create a randomly generated password and reference it in the RDS configuration since it requires a master username and password. The CloudFormation can store the username and password in an AWS Secrets Manager secret that can be only accessed by Database Admins.
Password generation is not only useful in CloudFormation templates, but applications (through the SDK) can also leverage this feature. The functionality to generate random strings is only available to AWS Secrets Manager and not available in SSM Parameter Store.
Secrets Rotation
Another feature unique to AWS Secrets Manager is the ability to rotate the secret value. Out of the box, AWS Secrets Manager provides full key rotation integration with RDS. This means that AWS Secrets Manager can rotate keys and actually apply the new key/password in RDS for you. For services other than RDS, AWS allows you to write custom key rotation logic using an AWS Lambda function. Further information regarding AWS Secrets Manager key rotation can be found HERE.
Cost
There are no additional charges for using SSM Parameter Store. However, there are limit of 10,000 parameters per account. On the other hand, AWS Secrets Manager does accrue additional costs. At the time of this writing, it costs $0.40 per secret stored and additional $0.05 for 10,000 API calls.
Cross Account Access
Another way AWS Secrets Manager is substantially different from SSM Parameter store, is that secrets can be shared across accounts. For example, IAM users and application resources in one development or production AWS account will be able access secrets stored in a different AWS account (e.g. Security AWS Account). Such functionality is also beneficial for use cases where a customer needs to share a particular secret with a partner. The article found HERE demonstrates how to setup a cross-account AWS Secrets Manager secret.
Use Cases
Though theoretically, both services can fulfill the key/value store requirements, I think that there is a difference in use cases for when to use one service over the other. AWS understood that managing secrets in Parameter Store was possible, but it was lacking in functionality. Therefore, it should be no surprise that AWS Secrets Manager was created to store secrets. With additional functionality such as key rotation, cross-account access, and tighter integration with AWS services, AWS Secrets Manager offers a great solution for storing secrets without having to integrate with other third-party solutions.
AWS Secrets Manager doesn’t replace SSM Parameter Store functionality. Parameter Store continues to provide functionality to easily optimize and streamline application deployments by storing environmental configuration data or other necessary parameters. And it is free!
Final Thoughts
As mentioned earlier, both services are very valuable to the AWS ecosystem for making streamline solutions and effective application deployment on AWS.
Parameter Store can be used to store the secrets encrypted or unencrypted fashion. It helps you optimize and streamline application deployments by storing environmental config data, other parameters and it is free. AWS Secrets Manager takes it up by few notches by providing additional functionality such as rotation of keys, cross-account access and tighter integration with AWS services.
Recommendation: Use Secrets Manager to store confidential secrets like database credentials, API keys, OAuth tokens. Use Parameter Store to store other application settings, environmental config data, License codes, etc.
Prefer storing secrets in Secrets Manager or Parameter Store instead of storing them in a config file or hard-coded in applications.
Join the conversation! Your thoughts help the community grow.