New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

env-file support #247

Open
tbinna opened this Issue Nov 4, 2015 · 31 comments

Comments

Projects
None yet
@tbinna

tbinna commented Nov 4, 2015

I open this issue to pick up a point that was made in #127 to support the --env-file parameter. As pointed out in #127 this would be useful e.g. to add some environment variables that contain sensitive information. This way sensitive environment variables could be stored in a private S3 bucket and be pulled in from there either directly or via a mounted volume.

If the --env-file parameter is supported I guess the documentation on Task Definition Parameters could also be improved. Under environment it is mentioned that it is not recommended to put sensitive information in there, however it does not point to a solution on how to do this otherwise.

Extract from issue #127:

[...] Ideally it would allow an s3 endpoint:

"containerDefinitions":[
  {
    "env_file":[
      { "bucket":"my-bucket", "key":"myenvlist" }
    ]
  }
]

Elastic Beanstalk lets you do something similar in the Dockerrun.aws.json for docker private repository configuration:

"Authentication":{
  "Bucket":"my-bucket",
  "Key":"mydockercfg"
},
@jimlester

This comment has been minimized.

Show comment
Hide comment
@jimlester

jimlester Dec 1, 2015

I'm looking for env-file support as well.

jimlester commented Dec 1, 2015

I'm looking for env-file support as well.

@diranged

This comment has been minimized.

Show comment
Hide comment
@diranged

diranged commented Dec 2, 2015

👍

@aldarund

This comment has been minimized.

Show comment
Hide comment
@aldarund

aldarund commented Jan 5, 2016

+1

@esetnik

This comment has been minimized.

Show comment
Hide comment
@esetnik

esetnik Jan 8, 2016

I have the same issue. I'm running a db connected task on ecs and I don't want to embed my db auth in the compose / task. I'm currently using ecs-cli but there's no support for encrypting the environment variables as far as I know.

When I've worked with CI systems that utilize docker (travis for example) they usually provide a mechanism for encrypting environment variables such that they can be embedded in config and decrypted when they are passed into the container. Travis Encryption Keys. I'm wondering if AWS does or could offer a similar feature for encrypting sensitive information destined for the container.

esetnik commented Jan 8, 2016

I have the same issue. I'm running a db connected task on ecs and I don't want to embed my db auth in the compose / task. I'm currently using ecs-cli but there's no support for encrypting the environment variables as far as I know.

When I've worked with CI systems that utilize docker (travis for example) they usually provide a mechanism for encrypting environment variables such that they can be embedded in config and decrypted when they are passed into the container. Travis Encryption Keys. I'm wondering if AWS does or could offer a similar feature for encrypting sensitive information destined for the container.

@jtmarmon

This comment has been minimized.

Show comment
Hide comment
@jtmarmon

jtmarmon Jan 20, 2016

+1 would like to be able to use KMS or something similar to encrypt env vars

jtmarmon commented Jan 20, 2016

+1 would like to be able to use KMS or something similar to encrypt env vars

@oliverwilkie

This comment has been minimized.

Show comment
Hide comment
@oliverwilkie

oliverwilkie Jan 26, 2016

Does anyone have a good workaround for this?

oliverwilkie commented Jan 26, 2016

Does anyone have a good workaround for this?

@gavinheavyside

This comment has been minimized.

Show comment
Hide comment
@gavinheavyside

gavinheavyside Jan 27, 2016

I've sometimes used a pattern where the entry point of my container fetches an env file from S3 and sources it before running my actual command. The location of this file can be passed as an env var, and IAM permissions used to control access, e.g (from memory, so it might not work as is):

CMD ["/bin/sh", "-c", "aws s3 cp --region eu-west-1 `echo ${ENV_FILE_PATH}` ./env.sh; . ./env.sh; command-to-run"]

It isn't ideal, but seems to work OK.

gavinheavyside commented Jan 27, 2016

I've sometimes used a pattern where the entry point of my container fetches an env file from S3 and sources it before running my actual command. The location of this file can be passed as an env var, and IAM permissions used to control access, e.g (from memory, so it might not work as is):

CMD ["/bin/sh", "-c", "aws s3 cp --region eu-west-1 `echo ${ENV_FILE_PATH}` ./env.sh; . ./env.sh; command-to-run"]

It isn't ideal, but seems to work OK.

@ghaering

This comment has been minimized.

Show comment
Hide comment
@ghaering

ghaering Feb 26, 2016

I plan to use https://github.com/zeroturnaround/configo in my containers. It's a more general solution for loading environment variables from etcd, file, DynamoDB or Vault. Unfortunately, S3 is not supported yet.

I'm not sure env-file is supported in the Docker API, I guess it's a feature strictly of the "docker" commandline tool. Also it helps little in a clustered environment, as then you would still need to put this file on the host.

I'd prefer loading the environment variables from S3 instead, if you were to add this feature to ECS.

ghaering commented Feb 26, 2016

I plan to use https://github.com/zeroturnaround/configo in my containers. It's a more general solution for loading environment variables from etcd, file, DynamoDB or Vault. Unfortunately, S3 is not supported yet.

I'm not sure env-file is supported in the Docker API, I guess it's a feature strictly of the "docker" commandline tool. Also it helps little in a clustered environment, as then you would still need to put this file on the host.

I'd prefer loading the environment variables from S3 instead, if you were to add this feature to ECS.

@rfink

This comment has been minimized.

Show comment
Hide comment
@rfink

rfink Apr 15, 2016

+1 would be a great feature

rfink commented Apr 15, 2016

+1 would be a great feature

@jqmtor

This comment has been minimized.

Show comment
Hide comment
@jqmtor

jqmtor Jun 9, 2016

It would be cool to know what the maintainers think about this issue in terms of relevance/priority. I am really needing this and I might be able to submit a patch.

jqmtor commented Jun 9, 2016

It would be cool to know what the maintainers think about this issue in terms of relevance/priority. I am really needing this and I might be able to submit a patch.

@santouras

This comment has been minimized.

Show comment
Hide comment
@santouras

santouras commented Jul 13, 2016

+💯

@myronahn

This comment has been minimized.

Show comment
Hide comment
@enkoder

This comment has been minimized.

Show comment
Hide comment
@enkoder

enkoder Oct 13, 2016

💯 This would be an awesome feature!

enkoder commented Oct 13, 2016

💯 This would be an awesome feature!

@itsjamie

This comment has been minimized.

Show comment
Hide comment
@itsjamie

itsjamie Nov 17, 2016

I think it should be implemented very closely to what @tbinna recommended, although I would include support for using KMS to decrypt the envfile before running the container.

Perhaps

"containerDefinitions":[
  {
    "env_file":[
        { 
           "s3": {          
               "bucket": "my-bucket", 
               "key":"myenvlist" 
           }
           "kmsArn": "<kmsArn>" // Optional
        }
    ]
  }
]

This way if you have sensitive data in the file you encrypt it, upload it to s3. The container can pull it down and use KMS at runtime to decrypt and pass the file directly via --envfile.

Thoughts from the Amazon team? If I were to submit a PR for the agent level changes, might that help see it implemented at the task definition level?

itsjamie commented Nov 17, 2016

I think it should be implemented very closely to what @tbinna recommended, although I would include support for using KMS to decrypt the envfile before running the container.

Perhaps

"containerDefinitions":[
  {
    "env_file":[
        { 
           "s3": {          
               "bucket": "my-bucket", 
               "key":"myenvlist" 
           }
           "kmsArn": "<kmsArn>" // Optional
        }
    ]
  }
]

This way if you have sensitive data in the file you encrypt it, upload it to s3. The container can pull it down and use KMS at runtime to decrypt and pass the file directly via --envfile.

Thoughts from the Amazon team? If I were to submit a PR for the agent level changes, might that help see it implemented at the task definition level?

@tilgovi

This comment has been minimized.

Show comment
Hide comment
@tilgovi

tilgovi Nov 18, 2016

@itsjamie maybe rather than a separate kmsArn key, something in the s3 object that can be used to specify whatever value for the SSE, whether that's a kms arn or AES256, etc. This is part of the s3 API so it might make more sense as part of the s3 block.

tilgovi commented Nov 18, 2016

@itsjamie maybe rather than a separate kmsArn key, something in the s3 object that can be used to specify whatever value for the SSE, whether that's a kms arn or AES256, etc. This is part of the s3 API so it might make more sense as part of the s3 block.

@cbbarclay

This comment has been minimized.

Show comment
Hide comment
@cbbarclay

cbbarclay Feb 11, 2017

Another option might be to use parameter store.

cbbarclay commented Feb 11, 2017

Another option might be to use parameter store.

@jfarrell

This comment has been minimized.

Show comment
Hide comment
@jfarrell

jfarrell Feb 23, 2017

Would be extremely useful to have to env-file and an even bigger win to have that data come from parameter store in a TaskDefinition

jfarrell commented Feb 23, 2017

Would be extremely useful to have to env-file and an even bigger win to have that data come from parameter store in a TaskDefinition

@otanner

This comment has been minimized.

Show comment
Hide comment
@otanner

otanner Mar 30, 2017

I created a PoC with CloudFormation that creates a Lambda function to fetch values from the ParameterStore, and CFN then uses the Lambda function as a CustomResource. The same CFN template also creates the TaskDefinition (and the Cluster, Service, ALB etc.). This way it's possible to inject SecureText ParameterStore values into the TaskDefinition ENV (or to any other CloudFormation resource).

This is definitely not the most secure way to implement this as the Lambda needs to be able to read/decrypt values for all the Tasks in the CFN template. I would prefer to use IAM Roles for Tasks and grant each Task access to only it's own parameters, and decrypting them with the help of ecs-agent using the Task's IAM Role when creating the container. Also one downside is that the decrypted values can currently be seen from the TaskDefinition settings in AWS console. Anyway, this implementation needs no changes to the actual container and it's possible to use single key/value pairs instead of the full env-file.

otanner commented Mar 30, 2017

I created a PoC with CloudFormation that creates a Lambda function to fetch values from the ParameterStore, and CFN then uses the Lambda function as a CustomResource. The same CFN template also creates the TaskDefinition (and the Cluster, Service, ALB etc.). This way it's possible to inject SecureText ParameterStore values into the TaskDefinition ENV (or to any other CloudFormation resource).

This is definitely not the most secure way to implement this as the Lambda needs to be able to read/decrypt values for all the Tasks in the CFN template. I would prefer to use IAM Roles for Tasks and grant each Task access to only it's own parameters, and decrypting them with the help of ecs-agent using the Task's IAM Role when creating the container. Also one downside is that the decrypted values can currently be seen from the TaskDefinition settings in AWS console. Anyway, this implementation needs no changes to the actual container and it's possible to use single key/value pairs instead of the full env-file.

@lrvick

This comment has been minimized.

Show comment
Hide comment
@lrvick

lrvick Apr 9, 2017

All current solutions I have seen involve having a bootstrap container that fetches secrets and writes them to a file. Then you need some way to get the env vars into the target service container. Volumes are one obvious way to do this.

It would then be expected you need tools inside the target container to load the env vars from a volume.

This can work if your service container container bundles tools to source a file. If the target service is a bare bones container with only a binary, such as a go app, then there exists no method to load env vars to it on the fly.

Currently this is a hard blocker for me being able to use ECS at all. Bundling plaintext secrets into task definitions is -not- a solution.

Direct KMS integration would be great but at the very least there needs to be a way to load environment vars from a volume or file on disk. Then a bootstrap container could do the legwork.

lrvick commented Apr 9, 2017

All current solutions I have seen involve having a bootstrap container that fetches secrets and writes them to a file. Then you need some way to get the env vars into the target service container. Volumes are one obvious way to do this.

It would then be expected you need tools inside the target container to load the env vars from a volume.

This can work if your service container container bundles tools to source a file. If the target service is a bare bones container with only a binary, such as a go app, then there exists no method to load env vars to it on the fly.

Currently this is a hard blocker for me being able to use ECS at all. Bundling plaintext secrets into task definitions is -not- a solution.

Direct KMS integration would be great but at the very least there needs to be a way to load environment vars from a volume or file on disk. Then a bootstrap container could do the legwork.

@michaelshaffer37

This comment has been minimized.

Show comment
Hide comment
@michaelshaffer37

michaelshaffer37 May 19, 2017

@cbbarclay I think that the parameter store would be a much better solution as the host EC2 instance running the Clusters wouldn't need to store the file for the env vars. Essentially what @mrburrito is stating on #328 would solve the problem with out exposing them to the host env file system. Much like the link that @myronahn provided but running in ECS agent rather than a special container.
Perhaps if we had something like the following.

"ContainerDefinitions":[
  {
    "Environment":[
        {
           "Name": "PRIVATE_VAR",
           "Value": {
               "Type": "parameter-store",
               "Name": "some.value",
               "Decrypt": true
           }
        }
    ]
  }
]

Then we could just manage the access through the tasks Role.

Just my two cents.

michaelshaffer37 commented May 19, 2017

@cbbarclay I think that the parameter store would be a much better solution as the host EC2 instance running the Clusters wouldn't need to store the file for the env vars. Essentially what @mrburrito is stating on #328 would solve the problem with out exposing them to the host env file system. Much like the link that @myronahn provided but running in ECS agent rather than a special container.
Perhaps if we had something like the following.

"ContainerDefinitions":[
  {
    "Environment":[
        {
           "Name": "PRIVATE_VAR",
           "Value": {
               "Type": "parameter-store",
               "Name": "some.value",
               "Decrypt": true
           }
        }
    ]
  }
]

Then we could just manage the access through the tasks Role.

Just my two cents.

@WhileLoop

This comment has been minimized.

Show comment
Hide comment
@WhileLoop

WhileLoop May 19, 2017

Better integration between EC2 Parameter Store and ECS would be great. Please consider this.

WhileLoop commented May 19, 2017

Better integration between EC2 Parameter Store and ECS would be great. Please consider this.

@Adrian-Sherwood

This comment has been minimized.

Show comment
Hide comment
@Adrian-Sherwood

Adrian-Sherwood Jun 9, 2017

Better integration of all docker command line parameter of the run command would be great.

Docker offers many smart and interesting possibilities, ECS shoots them down, thanks Amazon.

Adrian-Sherwood commented Jun 9, 2017

Better integration of all docker command line parameter of the run command would be great.

Docker offers many smart and interesting possibilities, ECS shoots them down, thanks Amazon.

@orfin

This comment has been minimized.

Show comment
Hide comment
@orfin

orfin Jul 12, 2017

Hi! as we also ran into the issue of secure passing env variables, we've just released small utility that handles that problem.

It's using AWS Parameter Store for injecting env vars on container startup. Check sample Dockerfile on: https://github.com/Droplr/aws-env

Cheers! :-)

orfin commented Jul 12, 2017

Hi! as we also ran into the issue of secure passing env variables, we've just released small utility that handles that problem.

It's using AWS Parameter Store for injecting env vars on container startup. Check sample Dockerfile on: https://github.com/Droplr/aws-env

Cheers! :-)

@emanuil-tolev

This comment has been minimized.

Show comment
Hide comment
@emanuil-tolev

emanuil-tolev commented Jul 18, 2017

I'm currently trying out https://github.com/promptworks/aws-secrets . Associated blog posts:

https://www.promptworks.com/blog/handling-environment-secrets-in-docker-on-the-aws-container-service

https://www.promptworks.com/blog/cli-for-managing-secrets-for-amazon-ec2-container-service-based-applications-with-amazon-kms-and-docker

Looks like it: a/ has a simple interface; b/ has been around for about a year c/ is used in production by its authors and others.

@aregier

This comment has been minimized.

Show comment
Hide comment
@aregier

aregier Nov 2, 2017

Please consider this. It would be very nice to help maintain clean docker images and be able to inject environment variables from the /etc/ecs/ecs.config file by specifying the environment file in the container / task definition.

aregier commented Nov 2, 2017

Please consider this. It would be very nice to help maintain clean docker images and be able to inject environment variables from the /etc/ecs/ecs.config file by specifying the environment file in the container / task definition.

@dev-head

This comment has been minimized.

Show comment
Hide comment
@dev-head

dev-head Jan 12, 2018

not having a secure way to do this, is a bug. perhaps we should dup this request as a bug to get some aws love

dev-head commented Jan 12, 2018

not having a secure way to do this, is a bug. perhaps we should dup this request as a bug to get some aws love

@jtoberon

This comment has been minimized.

Show comment
Hide comment
@jtoberon

jtoberon Jan 26, 2018

There are several related issues, including #1209 and #328.

jtoberon commented Jan 26, 2018

There are several related issues, including #1209 and #328.

@felipefrancisco

This comment has been minimized.

Show comment
Hide comment
@felipefrancisco

felipefrancisco Mar 1, 2018

over two years and no response from aws team? wow...

felipefrancisco commented Mar 1, 2018

over two years and no response from aws team? wow...

@ajslater

This comment has been minimized.

Show comment
Hide comment
@ajslater

ajslater Mar 2, 2018

ajslater commented Mar 2, 2018

@jtoberon

This comment has been minimized.

Show comment
Hide comment
@jtoberon

jtoberon Mar 2, 2018

Please see #1209. We'd love your feedback there to help guide our approach.

jtoberon commented Mar 2, 2018

Please see #1209. We'd love your feedback there to help guide our approach.

@FernandoMiguel

This comment has been minimized.

Show comment
Hide comment
@FernandoMiguel

FernandoMiguel Mar 2, 2018

ECS is far from being abandoned.
Many big companies depend on it, including amazon retail

FernandoMiguel commented Mar 2, 2018

ECS is far from being abandoned.
Many big companies depend on it, including amazon retail

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment