How would you store and use variables containing sensitive information in e.g. your CodeBuild process? I’ll quickly show you how you can use AWS Systems Manager (formerly known as SSM) to deal with this.

Use Case

Assume you have a CodeBuild config and you want to invoke some operation on e.g. different AWS account. For this you’d need to have AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY available.

For sure you do not want to use them directly in environment properties. That’s because environment properties can be printed out in logs or in standard output.

Configure Entry in AWS Systems Manager

It’s pretty simple - just enter the “Parameter Store” section of AWS Systems Manager, define the name and in case you select that it’s a SecureString type you can use your default KMS (Key Management Service) key for this variable (easiest way). Here you can see 2 keys I’ve created:

Use The Key From CodeBuild

In your CodeBuild buildspec.yml file you reference such parameters using following configuration:

version: 0.2

env:
  parameter-store:
    ACCESS_KEY_ID: "hq-serverless-access-key-id"
    SECRET_ACCESS_KEY: "hq-serverless-secret-access-key"

phases:
    (...)

Quick explanation: “the key – e.g. ACCESS_KEY_ID – is the name of the parameter you’ll be using in the rest of your buildspec.yml file,” “the value – e.g. hq-serverless-access-key-id – is the parameter name you’ve created in previous step in AWS Systems Manager.”

What About Echo in CodeBuild?

You don’t need to worry about echoing the values you’re using in your build. You can safely do something like:

printf "My Secret value is: $SECRET_ACCESS_KEY" > ~/secret_file 

and you can be sure that the value of parameter will not be resolved and printed out. In logs you’ll see $SECRET_ACCESS_KEY for all the time but in the mentioned secret_file you’ll see the already resolved value.

Summary

Hope that was easy enough that from now on no one will be tempted to use secrets as environment variables and use service that is dedicated to such cases :-)