ssmx
is a CLI tool for injecting parameters stored in AWS SSM into executables.
It also provides commands to retrieve and set parameters in AWS SSM.
pip install ssmx
Running:
ssmx --help
The Following authentication methods are supported:
- Environment variables
- Shared credential file (~/.aws/credentials)
- AWS config file (~/.aws/config)
- AWS profiles
For more details please see here.
List all parameters:
ssmx list
Output:
+------------------------------------+---------------+
| Name | Description |
+====================================+===============+
| /platform/infra/testing | Test param |
+------------------------------------+---------------+
| MY_KEY | MY TEST KEY |
+------------------------------------+---------------+
Filter parameters by name:
ssmx list --name my-app
Will list parameters starting with my-app
+---------------------+----------------------+
| Name | Description |
+=====================+======================+
| my-app.hostname | my app hostname |
| my-app.secret-key | hush puppy |
+---------------------+----------------------+
ssmx delete --name <MY_KEY>
Will delete the parameter MY_KEY
. Invalid parameters are ignored and printed on stdout.
Output:
+----------------------+
| Deleted Parameters |
+======================+
| MY_KEY |
+----------------------+
ssmx get --name <MY_KEY>
Will retrieve and decrypt the param MY_KEY Output:
+--------+---------+
| Name | Value |
+========+=========+
| MY_KEY | MY_VAL |
+--------+---------+
ssmx put
--name <name>
--value <value>
--description <description> # optional
--encrypt # optional
--key-id <kms_key_id> # required only when --encrypt is specified
Important Note: put
behaves like an upsert, meaning if no entry exists with the name provided, it will create a new entry, and if an entry already exists with the name provided, it will overwrite the current value with the value provided.
ssmx exec --env-file <file_path> -- <executable>
Using the exec
command, you can specify an env
file that contains plain and secret values. Secret values need to be provided in the following format:
PLAIN_ENV_VAR=hello world
SECRET_ENV_VAR=ssm:<MY_KEY>
Let's assume we are working with a node.js application that requires specific secret envrionment variables for specific environments. In other words, our application depends on .env
files to contain the environment variables it needs to function correctly for each environment it's deployed in.
Suppose our dev.env
file looks like the following
THIRD_PARTY_HOSTNAME=https://api.third-party.com
THIRD_PARTY_ACCESS_TOKEN=ssm:my-app.dev-third-party-access-token
We now need to pass this dev.env
file to ssmx
to fetch and decrypt the value for THIRD_PARTY_ACCESS_TOKEN
and then inject the two env. variables into the process that will run our node.js application.
$ ssmx exec --env-file ./env/dev.env -- npm start
Let's simplify our example from above and let's assume we store all our plain and secret env. variables in AWS SSM and we don't use .env
files.
We also prefix our keys in AWS SSM with <env>-my-app
, i.e.
+--------------------------------------+------------------------------+
| Name | Value |
+======================================+==============================+
| /dev-my-app/third-party-hostname | https://api.third-party.com |
| /dev-my-app/third-party-access-token | shhhh-my-access-token |
+--------------------------------------+------------------------------+
We can then acheive the same result in the previous example with the following command
$ ssmx exec --name dev-my-app -- npm start
Now this feature is really handy because if you're using docker to containerize your applications and AWS ECS to host your containers, you can simply provide an environment variable in your container definition, (i.e. APP_NAME
) to differentiate between each environment.
For example, in our Dockerfile we can do the following
ENTRYPOINT [ "./run-app.sh" ]
./run-app.sh
#!/usr/bin/env bash
set -e
echo "Starting up..."
# $APP_NAME is exposed by the container definition
ssmx exec --name $APP_NAME -- npm start
If you plan to use the --name
parameter with ssmx exec
, you need to follow a specific format for the keys you create in AWS SSM. The keys need to follow the path
format which works as follows:
/<root-path-prefix>/<another-path-prefix>/.../<MY_KEY>
# examples
/my-app/third-party-hostname
/my-app/dev/third-party-hostname
You can read in more detail about paths here
ssmx
is released under MIT
This project is a fork from HelloFresh's ssm-cli and drew inspiration from the following projects: