How can you pass private environment variables to FARGATE tasks specified from a Docker Compose config

Question

I am using an existing docker-compose.yml to migrate an app to ECS. The config references several $ENV vars which I used to pass in simply as environment variables when running docker-compose up. One of these is a password, which used to be specified on the Docker host. In ECS you are advised not to pass sensitive stuff along with the env-vars, so I'd like to improve this and use the best practises.

In FARGATE, I can't see how to pass these secure parameters into to the ecs-cli compose service up without sending them into the docker-compose used by ecs-cli (and then they end up displayed in the console, I guess possibly logged, etc).

The ECS CLI documentation explains to use SSM

secrets allows you to specify secrets which will be retrieved from SSM Parameter Store. See the ECS Docs for more information, including how reference AWS Secrets Managers secrets from SSM Parameter Store. value_from is the SSM Parameter ARN or name (if the parameter is in the same region as your ECS Task). name is the name of the environment variable in which the secret will be stored.

But under the ECS Docs

"This feature is not yet supported for tasks using the Fargate launch type."

I presume the "yet" means there will be one day.

I wonder if there's an current alternative for Fargate, or if we have to be less secure while they add support for it?

Answer 1

This is a well-written and up-to-date article which summarises the problem I've hit and confirms there isn't really a perfect solution at the moment in Fargate.

https://hackernoon.com/secrets-management-within-aws-ecs-1b6975819ccd - Connor Beardsmore

The alternatives listed are:

1. Bake into Docker - not an option with an open source repo
2. ECS Environment Variables - as I mentioned less secure
3. Docker Fetches from SSM Parameter Store - secure but "architecturally dirty"
4. Wait for Fargate SSM to be able to inject sensitive data!

Re. option 2. the problem is the environment variables are visible in the AWS console. But I wonder: if an attacker has access to your AWS console, you're pretty screwed already? So isn't this in fact an practically acceptable solution?