The root360 platform does provide a default set of environment variables already, e.g. details about other components (databases, cache layers, filesystems and so on) or the current environment (test, stage, prod, ….). Using those environment variables via install.sh you can configure your application with the appropriate endpoints of the environment.

You can enhance or extend this list of variables by adding new items yourself using the CLI-Suite (root360). The content will be added to an encrypted vault inside AWS SecretsManager.

To verify the values on the targets you’re setting the secrets for, you can either run sudo get-application-env (see How to access a database via SSH tunnel?) on these roles when using EC2 instance deployment or r3 container deploy <params> --only-show-taskdefinition for container based workloads (see Usage of CLI-suite for container).

Variables already being provided by Managed AWS Hosting platform can’t be overwritten. Duplicate variable key names will be post-fixed with _CONFLICTING_KEY.

Preconditions

List Secrets

List all available secrets.

~$ r3 secret list
+--------+----------------------------------+---------------------------+
|  Name  |         LastChangedDate          |      LastAccessedDate     |
+--------+----------------------------------+---------------------------+
| role_a | 2022-11-03 07:01:31.038000+00:00 | 2022-12-02 00:00:00+00:00 |
| role_b | 2022-08-04 06:05:47.389000+00:00 | 2022-11-29 00:00:00+00:00 |
+--------+----------------------------------+---------------------------+

Show Secrets

As the secrets scope is per role, you must provide a role parameter.

~$ r3 secret show --role=example
+-------------+-----------------------------------------------+
|   Secret    |                     Value                     |
+-------------+-----------------------------------------------+
| EXAMPLE_VAR | these-are-not-the-secrets-you-are-looking-for |
+-------------+-----------------------------------------------+

Add/Update secrets

As the secrets scope is per role, you must provide a role parameter.

If you’re running container workloads using a secret and modify the secret you must re-deploy the affected service(s) to pick up the changes. If you don’t redeploy, ECS will keep your current containers with the old secret value and would start new containers using the new secret values.

You can use an interactive editor:

~$ r3 secret update --role=example --key=MYVAR --editor nano
... an editor window opens up, now paste your content and save the file...
2020-11-17 10:42:40 r3-11364 SUCCESS  Secret "MYVAR" successfully updated.
+-------------+-----------------------------------------------+
|   Secret    |                     Value                     |
+-------------+-----------------------------------------------+
| EXAMPLE_VAR | these-are-not-the-secrets-you-are-looking-for |
| MYVAR       | may-the-cloud-be-with-you                     |
+-------------+-----------------------------------------------+

Complex values are supported by using a textfile:

~$ r3 secret update --role=example --key=MYVAR --value-from-file /tmp/private.key
2020-11-17 10:42:40 r3-11364 SUCCESS  Secret "MYVAR" successfully updated.
+-------------+-----------------------------------------------+
|   Secret    |                     Value                     |
+-------------+-----------------------------------------------+
| EXAMPLE_VAR | these-are-not-the-secrets-you-are-looking-for |
| MYVAR       | may-the-cloud-be-with-you                     |
+-------------+-----------------------------------------------+

Values can also be submitted directly (which should be avoided due to security concerns)

~$ r3 secret update --role=example --key=MYVAR --value='may-the-cloud-be-with-you'
2020-11-17 10:42:40 r3-11364 SUCCESS  Secret "MYVAR" successfully updated.
+-------------+-----------------------------------------------+
|   Secret    |                     Value                     |
+-------------+-----------------------------------------------+
| EXAMPLE_VAR | these-are-not-the-secrets-you-are-looking-for |
| MYVAR       | may-the-cloud-be-with-you                     |
+-------------+-----------------------------------------------+

Delete secrets

As the secrets scope is per role, you must provide a role parameter.

If you’re running container workloads that are using a secret and delete the secret you must re-deploy the affected service(s) to pick up the changes. If you don’t redeploy ECS will fail to start new containers for services that used the secret.

~$ r3 secret delete --role=example --key=MYVAR
2020-11-17 10:44:18 r3-11387 SUCCESS  Secret "MYVAR" successfully deleted.
+-------------+-----------------------------------------------+
|   Secret    |                     Value                     |
+-------------+-----------------------------------------------+
| EXAMPLE_VAR | these-are-not-the-secrets-you-are-looking-for |
+-------------+-----------------------------------------------+

Select specific secret for container deployment

note

Only available for container workloads.

Only available for container workloads.

If you’re running container workloads that are using a secret and delete the secret you must re-deploy the affected service(s) to pick up the changes. If you don’t redeploy ECS will fail to start new containers for services that used the secret.

For container workloads, you can share a secret between multiple services. This way you create a single secret to use for e.g. Frontend, Backend and Cron based on the same framework. Just specify --secret-name=<secret name> during deployment.

Related tutorials

Related components

note

INTERMEDIATE