Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

Hello world, it's the AWS parameter store

26 May 2021 🔖 linux devops aws
💬 EN

Table of Contents

I’d like to help some cloud-newbie sysadmins write automation scripts that reduce the overhead for common tasks and therefore make them more appealing to do frequently (the whole idea behind “infrastructure as code”):

  1. Making changes that prevent issues with the connection between a production transactional database and its production data warehouse, after spinning up a new nonproduction data warehouse by cloning it from a production server (involves running thousands of commands involving dozens of passwords).
  2. Changing a database superuser’s password in all the places it needs to be changed so that no integrations break

For a “hello world” project, I decided to write a couple of Linux shell scripts that demonstrate the principle of injecting a secret password into the script at runtime using AWS Systems Manager Parameter Store to store the passwords.


First, through the AWS web console, I created a SecureString in Parameter Store with a name of /pizza/flavors/first/ and a value of green pepper.

Next, I put two shell scripts on a Linux machine that was logged into the AWS CLI tool with permission to manipulate the Parameter Store:

var="I like $1 pizza";
echo "$var"

thetopping=`aws ssm get-parameters --names $thekey --with-decryption --query "Parameters[*].{Value:Value}" --output text --region us-west-2`
./ "$thetopping"



To run my code, I typed:

./ first

And we have a winner! The output was:

I like green pepper pizza


Not yet having a key named second, I tried this to make sure it would fail:

./ second

Sure enough, it did (note the double gap between like and pizza):

I like  pizza

If I ran ./ first without proper authentication, I would get one of the following two outputs:

An error occurred (ExpiredTokenException) when calling the GetParameters operation: The security token included in the request is expired
I like  pizza
An error occurred (AccessDeniedException) when calling the GetParameters operation: User: MY_AWS_USERNAME is not authorized to perform: ssm:GetParameters on resource: MY_AWS_RESOURCE:parameter/C
I like  pizza

Further thoughts

That was easy. Too easy. The “dozens of passwords” like green pepper would only be needed by code running on the server during occasional sysadmin maintenance tasks.

I feel like the running machine shouldn’t normally have ssm:GetParameters access, and that a sysadmin should have to go into AWS and flip it on before running these scripts, then flip it off as they finish. What do you think?

Future project

A future project might be to repeat this with AWS Secrets Manager.

--- ---