AWS Cloud Operations Blog
Organize Parameters by Hierarchy, Tags, or Amazon CloudWatch Events with Amazon EC2 Systems Manager Parameter Store
This post was written by Lusha Zhang, Software Development Engineer with Amazon Web Services.
Parameter Store, part of Amazon EC2 Systems Manager, provides a centralized, encrypted store to manage your configuration data, whether plaintext data (database strings) or secrets (passwords, API keys for example). Because Parameter Store is available through the AWS CLI, APIs, and SDKs, you can easily reference parameters across AWS services such as AWS Lambda and Amazon ECS.
For additional posts on Parameter Store, please see:
- Managing Secrets for Amazon ECS Applications Using Parameter Store and IAM Roles for Tasks
- Use Parameter Store to Securely Access Secrets and Config Data in AWS CodeDeploy
Parameter Store recently launched hierarchy support, parameter tagging, and CloudWatch Events support, which makes it easy to organize and manage parameters at scale. In this post, I demonstrate how you can use these new features to scale and improve your security posture.
Hierarchical parameters
Parameter Store support for hierarchies lets you organize parameters based on your deployment. It provides powerful tools for parameter organization, querying, and permission control.
A common DevOps scenario is to automate software deployment across different environments such as Dev, Beta, and Prod. For example, when you create a deployment configuration, you can use Parameter Store to save your settings. Maybe you have to set the minimum healthy host number or percentage for each deployment environment, and want to store it in Parameter Store, with different values for each environment.
Step 1. Create the path for deployment configuration
Use the following commands to create the path and parameters to store:
You can also organize your secrets under a dedicated path. For example,
For more information about how to use the SecureString type parameter, see About Systems Manager Parameters.
Your parameter hierarchy now looks like the following:
Step 2. Use parameters to manage your deployment configuration
When you create a deployment configuration using an AWS CloudFormation template, you can set the FleetHealth for a Prod stage as in the following example.
Step 2. Use parameters to manage your deployment configuration
When you create a deployment configuration using an AWS CloudFormation template, you can set the FleetHealth for a Prod stage as in the following example.
You can retrieve all the configuration parameters of your Prod or Beta environments using the recursive flag and parse the configuration hierarchy returned to get the parameter of your choice.
You can also filter parameters by path from the AWS Management Console or AWS CLI.
Control access to hierarchies
Now that you have created a parameter hierarchy for your deployment configuration in the Prod and Beta environments, you may want to restrict access to parameters. Maybe the Dev team should have access only to the Beta environment parameters, and not to the Prod environment parameters.
Use IAM to control access to the Beta parameter hierarchy. For example, the following IAM policy restricts user access to Prod parameters.
Now when a user runs the following command, they get AccessDeniedException.
Tagging parameters
Tags let you manage your AWS resources easily. You can now also tag parameters, allowing you to group and query them. Using the same deployment configuration example, you can add a tag with a Tag Key value of “Password”, and Tag Value equal to “Beta” or “Prod”.
You can also apply multiple filters to get a combined filter result. For example, if you apply Tag Key Password and a path /DeploymentConfig/Beta with the recursive flag, you get those parameters in your Beta environment that are password-related.
You can manage the security access with IAM policies. For more information, see Controlling Access to Systems Manager Parameters.
Get change notifications with CloudWatch Events rules
Parameter Store is now a CloudWatch Events source. You can set up CloudWatch rules to trigger a CloudWatch Event target such as a Lambda function or SNS topic whenever a parameter gets created, updated, or deleted.
The following example shows you how to set up a CloudWatch rule to trigger an SNS topic for your parameter update. For more information, see Step 2: Create an SNS Topic. After you set up your SNS topic to trigger an email notification about your parameter update, create a CloudWatch rule to associate with the SNS topic as a target. You can edit the Event Pattern value to specify the parameters for which to get notified:
When you change the value of the /DeploymentConfig/Beta/FleetHealth parameter, the CloudWatch event should show up in the metrics.
In the meantime, the SNS topic that you created is triggered and you should receive an email as well.
Conclusion
This post demonstrated several new Parameter Store features to manage parameters: hierarchy, tagging, and CloudWatch notifications. Hierarchical parameters make it easier to organize and control access to configuration data, whether plaintext or secrets. Tagging support provides you with another way to group and query parameters easily. With CloudWatch Events, you can get timely notifications about parameter updates.
About the Author
Lusha Zhang is a Software Development Engineer in the Amazon EC2 System Manager Team. She has worked on various products at Amazon from Amazon Textbook Rentals to AWS Parameter Store. Outside work, she enjoys playing the violin and the piano as well as surfing in the Pacific Northwest.