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 specifiedImportant 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-tokenWe 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 startLet'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 startNow 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 startIf 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-hostnameYou 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:
