<p>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.</p>

<p><a href="https://hackernoon.com/secrets-management-within-aws-ecs-1b6975819ccd" rel="nofollow noreferrer">https://hackernoon.com/secrets-management-within-aws-ecs-1b6975819ccd</a> - Connor Beardsmore</p>

<p>The alternatives listed are:</p>

<ol>
<li>Bake into Docker - not an option with an open source repo</li>
<li>ECS Environment Variables - as I mentioned less secure</li>
<li>Docker Fetches from SSM Parameter Store - secure but "architecturally dirty"</li>
<li>Wait for Fargate SSM to be able to inject sensitive data!</li>
</ol>

<p>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?</p>

CC BY-SA 4.0
2019-07-10T17:47:01.133Z
From the link there is an update showing that now you can request the secrets to be injected

Update:
As of November 2018, Amazon have now officially released support for injecting sensitive data in ECS containers via SSM! This is an awesome first step based on user feedback from the feature request shown in the links. There’s currently no support for the Fargate launch type, or for pulling multiple parameters given a single path, but hopefully we can see these advancements over the coming months.
Ivailo Bardarov
CC BY-SA 4.0
2018-12-14T03:56:22.703Z
2018-12-14T03:56:22.703Z
scipilot
<p>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 <code>docker-compose up</code>. 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.</p>

<p>In FARGATE, I can't see how to pass these secure parameters into to the <code>ecs-cli compose service up</code> 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).</p>

<p>The <a href="https://github.com/aws/amazon-ecs-cli#using-ecs-parameters" rel="nofollow noreferrer">ECS CLI documentation</a> explains to use SSM</p>

<blockquote>
  <p><code>secrets</code> allows you to specify secrets which will be retrieved from
  SSM Parameter Store. See the <a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html" rel="nofollow noreferrer">ECS Docs</a> 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.</p>
</blockquote>

<p>But under the <a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html" rel="nofollow noreferrer">ECS Docs</a> </p>

<blockquote>
  <p>"This feature is not yet supported for tasks using the Fargate launch
  type."</p>
</blockquote>

<p>I presume the "yet" means there will be one day.</p>

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

<docker><amazon-web-services><docker-compose><security><amazon-ecs>
How can you pass private environment variables to FARGATE tasks specified from a Docker Compose config
scipilot
# How can you pass private environment variables to FARGATE tasks specified from a Docker Compose config

(Asked by: username_0 on 2018-12-14)

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](https://github.com/aws/amazon-ecs-cli#using-ecs-parameters) explains to use SSM

> `secrets` allows you to specify secrets which will be retrieved from
> SSM Parameter Store. See the [ECS Docs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html) 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](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html)

> "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?

**Tags:** docker, amazon-web-services, docker-compose, security, amazon-ecs


---

## 1 answers

### Answer by username_0 on 2018-12-14. Score: 2

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?

> **Comments:**
> **username_1**: From the link there is an update showing that now you can request the secrets to be injected  Update: As of November 2018, Amazon have now officially released support for injecting sensitive data in ECS containers via SSM! This is an awesome first step based on user feedback from the feature request shown in the links. There’s currently no support for the Fargate launch type, or for pulling multiple parameters given a single path, but hopefully we can see these advancements over the coming months.  

---

