Containers-roadmap: [ECS, Fargate] [request]: Pull environment variable values from SSM

[kevinkuszyk]

Tell us about your request
I want to be able to pull values for environment variables from SSM, in the same way that secrets can be pulled. The task definition would look something like this:

"environment": [
  { "name": "SOME_ENVIRONMENT_VAR", "valueFrom": "/foo/some-environment-var" }
]

Which service(s) is this request for?
Fargate, ECS.

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
I want to keep my config values outside of the containers, and have them pull the correct values for the environment they are running in from SSM when they boot (like they already do for secrets).

Are you currently working around this issue?
By using secrets for config values which are not sensitive.

[clareliguori]

Hi @kevinkuszyk can you tell me more about why you would like this option in the "environment" section of the task def, instead of using the "secrets" section? Secrets stored in SSM do not necessarily have to be sensitive information. For example, you can pull from a 'String' type SSM parameter; it does not have to be 'SecureString' type (which is recommended for truly sensitive information).

[kevinkuszyk]

@clareliguori it's just semantics and what feels like a gap in the product.

why you would like this option in the "environment" section of the task def, instead of using the "secrets" section? Secrets stored in SSM do not necessarily have to be sensitive information

Exactly - we store non-secret config like urls for external services etc in SSM which we need to make available to containers as environment variables.

At the moment we are working around by declaring them as secrets in the task definitions, but really they are not secrets, they are plain environment variables. It feels like the right place to declare these as environment variables in the environment section.

[FernandoMiguel]

"secrets" is just the internal name that aws uses for Parameter Store.
I used to use many of PS values in clear text, just fine on ECS

[kevinkuszyk]

@FernandoMiguel we have plain text "secrets" working just fine. It's the modelling in the task definition which I think is off.

[FernandoMiguel]

i'm very confused here @kevinkuszyk
from what I understand, you can already do what you said in the OP you want to do.

so what exactly would you like to see change?
the name of the JSON group?

a bit too late for that, since millions of users now have that coded into their code base

[kevinkuszyk]

@FernandoMiguel I think the task definition should add support for this:

"environment": [
  { "name": "SOME_ENVIRONMENT_VAR", "valueFrom": "/foo/some-environment-var" }
]

In addition to this:

"environment": [
  { "name": "SOME_ENVIRONMENT_VAR", "value": "bar" }
]

That would't be a breaking change - it's in addition to what we have today.

[clareliguori]

Would there be any difference in behavior when providing an SSM parameter in environment section vs secrets section? My concern is that generally users find it more confusing when there are two ways to achieve the exact same behavior.

[whereisaaron]

SSM can be used to store more than just secrets. Right now I have to use the 'secrets' section for entirely non-secret values for environment variables, just in order to use SSM.

Taking a step back - nothing about the 'secret' section environment variables is more or less secret than 'environment' section environment variables. There are all injected as unencrypted environment variables.

Whether the referenced value is from an SSM SecureString or Secret Manager secret or not, or in the 'secrets' section or not, it is still going into an environment variable, which are treated no differently from each other from then on. The separate 'secrets' section seems superfluous and potentially misleading.

I think there should just be the 'environment' section that supports constant values, values from SSM, and values from Secrets Manager. The 'secrets' section could then be deprecated.