[ECS] [request]: Support version and label filters for parameter store

[alkalinecoffee]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request

The Parameter Store API allows the user to specify a version or label simply by appending it to the parameter name:

# version
aws ssm get-parameters --names "/hello-world/config.json:2"

# label
aws ssm get-parameters --names "/hello-world/config.json:testlabel"

However, there is no (documented) way to specify a version or label of a Parameter Store value in our task definition.

In our task definition, we've tried appending a version in a similar way:

"secrets": [
  {
    "name": "SERVICE_CONFIG_JSON",
    "valueFrom": "/hello-world/config.json:2"
  }
]

However, this results in the following error:

The Systems Manager parameter name specified for secret SERVICE_CONFIGJSON is invalid. The parameter name can be up to 2048 characters and include the following letters and symbols: a-zA-Z0-9.-,

Which service(s) is this request for?

ECS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

We wish to use the version or labeling feature provided by Parameter Store in our task definitions. Instead, we must use completely separate, but mostly duplicated parameters.

We are suggesting supporting the colon-delimited format of the Parameter Store API to specify the version and label of configs in the valueFrom parameter, or otherwise allow us to specify this value in our task definitions through a new secrets parameter, ie selector:

"secrets": [
  {
    "name": "SERVICE_CONFIG_JSON",
    "valueFrom": "/hello-world/config.json",
    "selector": "label or version"
  }
]

[lobsterdore]

This is a much needed addition, at the moment I am having to add a version to the name of the parameters in order to preserve old values.

[lordz-ei]

Most of the time the latest version of the SSM parameter store is good enough, but in our case the whole Java Spring Application profile is stored in a big json, which lives in SSM. Of course, this big json is composed using multiple environment variables in plain text and secure string.

In case of update to a new Ecs task definition, it might be the case that this Java Sping Json format is changed or some parameter inside it are modified. Considering that something went wrong and i have to rollback to the previous Ecs task definition revision, i would prefer only to specify the previous revision and use the specific Java Spring Json version - stored in SSM - compatibile with it, not to recreate a new SSM version to be the latest one.

[Andrey9kin]

Here is another scenario. Currently, when deploying with Terraform, an update of the SSM parameter will not trigger new deployment, and we have to create additional env variables that contain the current version of the SSM parameter to trigger deployment. In other words, Terraform will update the SSM parameter, and currently, there is no way to trigger ECS re-deployment to pick up new values. Adding a version to the SSM parameter reference in the task definition will cause the recreation of the task definition and, as a result of a new deployment.

[edin-kesetovic]

Another scenario - For each microservice version we need to apply a label to the ssm parameter and reference that label in taskdefinition. Unfortunately this is not supported yet.