Generally speaking, when you deploy infrastructure through code, or run deployment scripts you’ll need to have a certain amount of configuration data. Much of your code will have install routines but what about the configuration information that is specific to your environment? Things such as license keys, service accounts, passwords, or connection strings are commonly needed when connecting multiple services together. So how do you code that exactly? Do you pass the strings in at runtime as a parameter and then hope to remember those each time you execute code? Do you bake those strings into the code and then realize that you’ve got sensitive information stored in your deployment scripts?

Amazon Web Service has a solution that can be used with several of the other EC2 Systems Manager services, called “Parameter Store”. If you’re an active reader you’ve probably already figured out what parameter store does, but if not, here goes. Parameter store lets you store these sensitive strings in a centralized location for your code to reference. This way, your sensitive data can be referenced and stored in a central location and your code references that location. Now you can ensure that the code itself doesn’t require hard coding these values in, and also gives you flexibility to update parameters in a single place for use throughout your environment. Think about what would happen if you needed to change a password when that password might be hard coded into dozens of scripts scattered through your code repo.

Getting Started with EC2 Systems Manager Parameter Store

Using Parameter store is very simple to get set up. How you use it could range from very simple to very complex but in this example we’ll show a quick way to use the store and your imagination will have to provide the best way to use it for your organization.

From within the Amazon EC2 console look for the Parameter Store hyperlink. If its the first time you’ve used parameter store, you’ll see a familiar screen from AWS that gives you some information about the service and a “Get Started Now” button. Click that button and let’s get started.

Now we can create our first parameter. In this case we’ll make believe that this is a service account password for use in my lab. We’ll first give it a name which I’ve called /hollowlab/Example. If you’re wondering about the slashes in that name, they’re used as hierarchies. If you have to manage a giant list of parameters all in a flat list it might be too cumbersome to sort through. A better way might be to organize these into hierarchies (think of a folder structure) so you can group parameters. Maybe you’d do this by department, division or application version or environment? Again, the complexities we’ll leave up to you. For now I’ve got a root hierarchy of hollowlab and a parameter named “Example”.

After creating the name give it a description. This probably doesn’t need much explanation but here’s some advice. GIVE IT A GOOD DESCRIPTION! You’ll undoubtedly need to go back and figure out what these parameters are used for. A good description might save your bacon.

After this, select the parameter type. I’ve selected a basic string here, but if you’ve got a sensitive password, it might be a better idea to use a “Secure String” to obfuscate the actual value from your users. After all the password should be secret right?

Lastly, enter in the value(s) of the parameter and click the “Create Parameter” button.

Now you’ve got a parameter stored in the service and are ready to either create additional parameters or to start using that parameter in your code.

How to Access Your Parameters

There are several ways in which to access the parameter that we’ve just created. You can use the other EC2 Systems Manager services such as Run Command, State Manager and Automation, or other services such as AWS Lambda or AWS EC2 Container service. In this example we’ll just use a familiar service such as Run Command to see if we can access that parameter successfully.

Open up the Run Command service from the EC2 console and create a new command to execute. I’m running my command on a Linux host deployed in EC2 with the EC2SystemsManager role as described in this post. Since it’s a Linux machine I’ll execute a shell script, but you could also do this from a PowerShell script if your partial to Windows for your Operating System.

The next step is to select which instances we’ll be executing our command on. I’ve selected my Linux instance with the SSM Agent and role installed. After that comes the critical piece, the command. In the commands box, we’ll enter “echo {{ssm:/hierarchy/ParameterName}}” which will simply print out what the parameter value is. In my example I’ve used “echo {{ssm:/hollowlab/Example}}. Now clearly this is a silly exercise because all it does is print it to a screen, but should give you the idea about how it can be leveraged for those really important scripts that you’re dreaming up as you read this post.

When you’re ready run the command.

You’ll see your command run in the “Run Command” console within EC2 and then you’ll see a link that shows “View Output”. If you click that link we should see what happened when the command ran in our Linux instance.

And as we’d hoped, the fictitious password was output to the screen.

Summary

EC2 Systems Manager Parameter Store may serve as a critical piece to your provisioning or operational process for managing your infrastructure as code. It can serve as a central repository with KMS encrypted values for you to store critical configuration information for your environment so that you don’t need to pass that information out to people who are trying to write deployment scripts. I hope to hear in the comments how you’ve decided to use Parameter Store and we’ll use it ourselves in future posts about EC2 Systems Manger. Thanks for reading and happy coding!