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 run sudo get-application-env
(see How to access a database via SSH tunnel?) on these roles.
Note |
---|
Variables already being provided by Managed AWS Hosting platform can’t be overwritten. Duplicate variable names will be post-fixed with _CONFLICTING_KEY . |
Preconditions
List Secrets
As the secrets scope is per role, you must provide a role parameter.
Code Block |
---|
~$ r3 secret list --role example
+-------------+-----------------------------------------------+
| Secret | Value |
+-------------+-----------------------------------------------+
| EXAMPLE_VAR | these-are-not-the-secrets-you-are-looking-for |
+-------------+-----------------------------------------------+ |
Add/Update secrets
Secrets must be added/updated for a specific roleAs the secrets scope is per role, you must provide a role parameter.
Note |
---|
If you’re running container workloads using a secret which has been modified, remember to you should re-deploy the affected service(s) to pick up the changes. Otherwise If you don’t redeploy, ECS will fail to run keep your containers on scaling eventscurrent containers running with the old secret value and would start new containers using the new secret values. |
Code Block |
---|
~$ r3 secret update --role example --name 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
Secrets must be deleted for a specific roleAs the secrets scope is per role, you must provide a role parameter.
Note |
---|
If you’re running container workloads using a secret which has been modifieddeleted, remember to you mustre-deploy the affected service(s) to pick up the changes. Otherwise ECS will fail to run your containers on scaling eventsstart new containers for services that used the secret. |
Code Block |
---|
~$ r3 secret delete --role example --name 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 |
+-------------+-----------------------------------------------+ |
Filter by label (Content by label) |
---|
showLabels | false |
---|
showSpace | false |
---|
cql | label in ( "deployment" , "application" , "r3-suite" , "secrets" ) and ancestor = "2014352487" and space = currentSpace ( ) |
---|
|
Filter by label (Content by label) |
---|
showLabels | false |
---|
showSpace | false |
---|
cql | label in ( "deployment" , "application" , "r3-suite" , "secrets" ) and ancestor = "2014350220" and space = currentSpace ( ) |
---|
|