Managing Secrets Using AWS Systems Manager Parameter Store and IAM Roles

Introduction

Amazon Web Services (AWS) has an extremely wide variety of services which cover almost all our infrastructure requirements. Among the given services, there is AWS Systems Manager which is a collection of services to manage AWS instances, hybrid environment, resources, and virtual machines by providing a common UI interface for all of them. Services are divided into categories such as Resource Groups, Insights, Actions and Shared Resource. Among Shared Resources one is Parameter Store, which is our topic of discussion today. There are many services that may require SSM agents to be installed on the system but the Parameter store can be used as standalone as well.

What is Parameter Store?

Parameter Store is a service which helps you arrange your data in a systematic hierarchical format for better reference. Data can be of any type like Passwords, Keys, URLs or Strings. Data can be stored as encrypted or as plain text. Storage is done in Key-Value Format. Parameter store comes integrated with AWS KMS. It provides a key by default and gives you an option to change it, in this blog we will be using the default one.

Why Parameter Store?

Let’s compare its competitors, these include Hashicorp Vault and AWS Secrets Manager.

Vault stores secrets in Database/File-System but requires one to manage the root token and Unseal Keys. And it is not easy to use.

Next, is the AWS owned Secrets Manager, this service is not free and would require Lamda functions to be written for secret rotation. Which might become an overhead. Also, the hierarchy is taken as a String only, which can’t be iterated.

Some Key Features of Parameter Store include:

  • As KMS is integrated the encryption takes place automatically without providing extra parameters.

  • It arranges your data hierarchically and it is pretty simple, just apply “/” to form the hierarchy and by applying recursive search we can fetch required parameters.

  • This helps us in removing all those big Config files, which were previously holding our secrets and causing a severe security risk. Helping us in modularizing our applications.

  • Simple Data like Name can be stored as String.

  • Secured Data as SecureString.

  • Even Array data can be stored using StringList.

  • Access configuration is manageable with IAM.

  • Linked with other services like AWS ECS, Lambda, and CloudFormation

  • AWS backed

  • Easy to use

  • Free of cost

Note: Parameter Store is region specific service thus might not be available in all regions.

How to Use it?

Initial Setup:

Parameter Store can be used both via GUI and terminal.

AWS console:

  1. Login into your account and select your preferred region.

  2. In Services select Systems Manager and after that select Parameter Store.

  3. If there are already some credentials created than Keys of that credentials will be displayed.

  4. If Not, then you will be asked to “Create Parameter.”

image 8.png

On CLI:

  1. Download the AWS CLI, it comes along with inbuilt support for Systems Manager (SSM).

  2. Make sure to have your credentials file is configured.

Use: Both on Console and CLI

  1. Create:

    a. Enter the name of the key that you wish to store. If it is hierarchical then apply “/” without quotes and in place of value enter Value.

Eg: This

|- is

| - Key : Value

Then in name enter “ /This/is/Key” and in value write “Value”

b. Select the type of storage, if it can be stored as plain text then use String, if the value is in Array format then choose StringList and mention the complete array in value and if you want to secure it then use SecureString.

c. CLI:

$aws ssm put-paramater --name "/This/is/Key" --value "Value" --type String
{
"Version": 1
}

d. If you want to make it secure:

$aws ssm put-parameter --name "/This" --value "SecureValue" --type SecureString
{
 "Version": 1
}

2. Read:

a. Once Stored, parameters get listed on the console.

b. To check any of them, just click on the key. If not secured, the value will be directly visible and if it is secured, then the value would be hidden and you will have to explicitly press “Show”.

image10.png
image11.png

c. CLI:

$aws ssm get-parameter --name /This/is/Key
{
"Parameter": {
"Name": "/This/is/Key",
"LastModifiedDate": 1535362148.994,
"Value": "Value",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-1:275829625285:parameter/This/is/Key"
}
}

d. For Secured String:  

$aws ssm get-parameter --name /This --with-decrypt{
"Parameter": {
"Name": "/This",
"LastModifiedDate": 1535362296.062,
"Value": "SecureValue",
"Version": 1,
"Type": "SecureString",
"ARN": "arn:aws:ssm:us-east-1:275829625285:parameter/This”
}
}

e. If you observe the above command you will realize that despite providing “/This” we did not receive the complete tree. In order to get that provide modify the command as follows

$aws ssm get-parameters-by-path --path /This --recursive
{
"Parameters": [
{
"Name": "/This/is/Key",
"LastModifiedDate": 1535362148.994,
"Value": "Value",
"Version": 1,
"Type": "String",
"ARN": "arn:aws:ssm:us-east-1:275829625285:parameter/This/is/Key"
}
]
}

 

3. Rotate/Modify:

a. Once a value is saved it automatically gets versioned as 1, if you click on the parameter and EDIT it, then version gets incremented and the new value is stored as version 2. In this way, we achieve rotation of credentials as well.

Rotate Modify 1.png
Rotate Modify 2.png

b. Type of parameters cannot be changed, you will have to create a new one.

c. CLI:
The command itself is clear, just observe the version:

$aws ssm put-parameter --name "/This/is/Key" --value "NewValue" --type String --overwrite
{
"Version": 2
}
 

4. Delete:

a. Select the parameter or select all the required parameters and click delete

Delete Parameters.png

b. CLI:

$aws ssm delete-parameter --name "/This/is/Key"

As you can see commands are pretty simple and if you have observed, ARN information is also getting populated. Below we will discuss IAM role that we can configure, to help us with access control.

IAM (AWS Identity and Access Management)

Remember that we are storing some very critical data in Param Store, therefore access to that data should also be well maintained. If by mistake a new developer comes in the team and is given full access over the parameters, chances are he might end up modifying or deleting production parameters. This is something we really don't want.

Generally, it is a good practice to have roles and policies predefined such that only the person responsible has access to required data. Control over the parameters can be done to a granular level. But for this blog, we will take a simple use case. That being said we can take reference from the policies mentioned below.

By using the resource we can specify the path for parameters, that can be accessed by a particular policy. For example, only System Admin should be able to fetch Production credentials, then in order to achieve this, we will be placing “parameter/production” on the policy, where production represents the top level hierarchy. Thus making anything stored under production become accessible, if we want to more fine tune it then we can do so by adding parameters after - parameter/production/<till>/<the>/<last>/<level>

Below are some of the policies that can be applied to a group or user on a server level. Depending on the requirement, explicit deny can also be applied to Developers for Production.

For Production Servers:

SSMProdReadOnly:

"ssm:GetParameterHistory",
"ssm:ListTagsForResource",
"ssm:GetParametersByPath",
"ssm:GetParameters",
"ssm:GetParameter"
"Resource": "arn:aws:ssm:<Region>:<Role-ID>:parameter/production"

SSMProdWriteOnly:

"ssm:GetParameterHistory",
"ssm:ListTagsForResource",
 "ssm:GetParametersByPath",
 "ssm:GetParameters",
 "ssm:GetParameter",
 "ssm:PutParameter",
 "ssm:DeleteParameter",
 "ssm:AddTagsToResource",
 "ssm:DeleteParameters"
 "Resource": "arn:aws:ssm:<Region>:<Role-ID>:parameter/production"

For Dev Servers:

SSMDevelopmentReadWrite

"ssm:PutParameter",
"ssm:DeleteParameter",
"ssm:RemoveTagsFromResource",
"ssm:AddTagsToResource",
"ssm:GetParameterHistory",
"ssm:ListTagsForResource",
"ssm:GetParametersByPath",
"ssm:GetParameters",
"ssm:GetParameter"
"Resource": "arn:aws:ssm:<Region>:<Role-ID>:parameter/development"

Conclusion

This was all about the AWS systems manager parameter store and the IAM roles. Now that you know what the parameter store is, why should you use it, and how to use it, I hope this helps you in kick-starting your credential management using AWS Parameter Store. Start using it already and share your experiences or suggestions in the comments section below.


About the Author

linkedin.jpeg

Ismail is a DevOps Engineer/Consultant and freelancer by profession. He is passionate about DevOps and infrastructure automation. In his free time he enjoys console gaming, watching anime, hanging out with friends, and exploring new places.