AWS Secrets Manager vs. SSM Parameter Store

ACM.119 Choosing where to store secrets and configuration data

Part of my series on Automating Cybersecurity Metrics. The Code.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

In the last post I explained why you might want to use a customer-managed instead of AWS-managed encryption.

Now let’s review the differences between AWS Secrets Manager and AWS Systems Manager Parameter Store at the time of this writing. Note that this list could become out of date at any minute if AWS changes the way these services work so review the documentation for the most up to date information.

                                  | Parameter Store  |   Secrets Manager
Limit KMS Key to Service          |        No        |       Yes
Resource Policy Access Control    |        No        |       Yes
Cross-Account Role Access         |        No        |       Yes
Generate CloudFormation Secret    |        No        |       Yes
Automatically Rotate Secrets      |        No        |       Yes
CloudFormation Encrypted Type     |        No        |       Yes
Customer KMS Key Encryption       |        Yes       |       Yes
Expiration                        |        Yes       |       Yes
Versions                          |        Yes       |       Yes
Dynamic CloudFormation references |        Yes       |       Yes
Cheaper                           |        Yes       |       No

We can limit use of an AWS KMS Key to AWS Secrets Manager.

It is possible to use CloudFormation to create a value and store it in AWS Secrets Manager in an encrypted format using the SecretString property.

This post contains an example of using AWS Lambda with Parameter Store. One of the limitations at the time of this writing is the inability to use SecureString with CloudFormation. That means you cannot create an encrypted parameter with CloudFormation when using AWS Parameter store. See the link to the documentation in this post.

The next post adds a KMS Key Id to parameter store to encrypt data stored in a parameter. It explains and has a link to the documentation related to the fact that SSM Parameter store does not offer resource policies with access control. In this post I also explore the fact that you cannot use a policy condition limit a KMS key to only be used by AWS Parameter Store like we could with Secrets Manager.

This post considers the pros and cons of storing a user-specific SSH key in AWS Parameter Store. AWS Parameter Store doesn’t offer resource policies that allow us to limit access to a Parameter. I explained the benefits of using an IAM policy with a resource policy in the last post and why you might want to use both for access to sensitive data.

The next post demonstrates how to store an SSH key in Secrets Manager. You can create an resource policy with access controls for an AWS secret.

In this post we consider creating an AppSec group to manage secrets. You can allow Secrets Manager administrators to manage AWS Secrets Manager policies.

This post creates a role that the AppSec administrator group can assume. This post explains how you can use IAM, Secrets Manager, and KMS policies to create an architecture that requires a three-party collusion to obtain unauthorized access to a secret.

It is possible to create an auto-generated password with AWS Secrets Manager and CloudFormation. Parameter store doesn’t have that option. Passing secrets in parameters is not secure because parameter values are visible in various places.

You can use the AWS console to enforce MFA on a user-specific secret stored in Secrets Manager. We can’t enforce MFA with developer credentials (access key and secret key id) used with the AWS CLI. We can’t create a user-specific policy for an AWS IAM Role since the principal (identity) is not a single user in that case. This is a work-around for those limitations.

Those posts illustrate some things you can and cannot do with either AWS Secrets Manager or AWS Parameter Store.

Next up we are going to make some adjustments to our AWS Lambda and batch job deployments to work with the AppSec administrator role that manages secrets policies.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2022

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab