Skip to content
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

ECS Secrets Management #8

Closed
abby-fuller opened this issue Nov 28, 2018 · 27 comments
Closed

ECS Secrets Management #8

abby-fuller opened this issue Nov 28, 2018 · 27 comments
Labels
ECS Amazon Elastic Container Service Fargate AWS Fargate

Comments

@abby-fuller
Copy link
Contributor

abby-fuller commented Nov 28, 2018

Enable customers to vend sensitive information from AWS Systems Manager Parameter Store and AWS Secrets Manager in the form of environment variables when a service on ECS or Fargate is started. The various components of this issue are:

@abby-fuller abby-fuller added Fargate AWS Fargate ECS Amazon Elastic Container Service labels Nov 28, 2018
@Bensign Bensign changed the title Secrets Management v2 ECS Secrets Management v2 Dec 5, 2018
@whithajess
Copy link

Will this only be AWS Secrets Manager and not AWS Systems Manager Parameter Store?

@Bensign
Copy link

Bensign commented Dec 12, 2018

@whithajess ECS supports AWS Systems Manager Parameter Store as of 11/15/18: https://aws.amazon.com/about-aws/whats-new/2018/11/aws-launches-secrets-support-for-amazon-elastic-container-servic/

@whithajess
Copy link

whithajess commented Dec 12, 2018

@Bensign Thanks for the info I guess I missed that - Unfortunately still lacking support for Fargate at the moment so will have to stick to: https://github.com/segmentio/chamber

@Bensign
Copy link

Bensign commented Dec 12, 2018

@whithajess We are actively working on Fargate support for both options: AWS Systems Manager Parameter Store & AWS Secrets Manager. I'll update back here on this thread as things go live.

@whithajess
Copy link

@Bensign Awesome - Thanks I really like this new public roadmap and hope it continues, has already given me a lot of useful info.

I follow a RSS feed of whats new in AWS but its pretty easy to miss relevant stuff given the amount of new things daily.

@maartenvanderhoef
Copy link

First of all. It's great this roadmap is shared, kudos for that!

The new Task definition parameter secrets is a good start for variables stored in SSM/KMS. But it's not a replacement for Chamber unfortunately. It would be great to have a parameter with which one can expose all variables of a certain path inside SSM as Environment Variables like chamber does.

Next to that SSM has been problematic when it comes to API limits. It would help if AWS would come clear regarding the API limits so that it's possible to use SSM more extensively without the risk of hitting API limits.

@garrardkitchen
Copy link

@maartenvanderhoef This is such a great idea...I would request for Secrets and Fargate too.

We've also been hit by SSM API throttling (via Lambda) :(

@taraspos
Copy link

What about being able to mount secret into the container as the file, as Kubernetes does?

@tabern
Copy link
Contributor

tabern commented Dec 17, 2018

@Bensign Awesome - Thanks I really like this new public roadmap and hope it continues, has already given me a lot of useful info.

I follow a RSS feed of whats new in AWS but its pretty easy to miss relevant stuff given the amount of new things daily.

You can also check out https://aws.amazon.com/containers/new – we keep this regularly updated with the latest containers related release postings and blog links.

@Bensign
Copy link

Bensign commented Dec 18, 2018

Hi all,

A few updates here:

Volume mounts for secrets rather than environment variables has been something we've discussed in the past. Thanks for opening the issue on that. I think I'll also separately create an issue for vending an entire path as that has popped up a few times as well.

Thanks everyone for the continued feedback on this!

@sj26
Copy link

sj26 commented Dec 18, 2018

vending an entire path

Yes please! This would be very useful for mounting in config files for community built images of non-cloud-native software without having to re-bake images or juggle sidecar containers.

@Bensign Bensign changed the title ECS Secrets Management v2 ECS Secrets Management Dec 18, 2018
@rlafferty
Copy link

Would this potentially change the # of api calls that are made to the SSM service at container start? Currently, if you have a custom startup script to get N number of secrets from SSM? We've found it fairly cost prohibitive if you start/stop containers very frequently and have 10+ secrets that get fetched/decrypted at container start time in terms of the SSM costs.

@Nr18
Copy link

Nr18 commented Dec 20, 2018

Will this also contain using the secrets from the AWS::ECS::TaskDefinition resource in CloudFormation?

@cervantek
Copy link

cervantek commented Jan 13, 2019

Will this also contain using the secrets from the AWS::ECS::TaskDefinition resource in CloudFormation?

Just want to second this. You (Amazon) would know better than us, but I think many of your customers manage their TaskDefinitions in CFN. Also, looks like it is a separate issue to track this #97 .

@ronkorving
Copy link

ronkorving commented Jan 17, 2019

Is it me, or does https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-containerdefinitions.html not yet reflect the new Secrets property that is mentioned here?

@hluchej
Copy link

hluchej commented Jan 28, 2019

What about similar support in EKS? We have run into it here: kubernetes-sigs/aws-load-balancer-controller#754 (comment)

@Zanndorin
Copy link

Zanndorin commented Mar 29, 2019

Hi,

Is there an ETA for

Fargate support for AWS Secrets Manager [In Progress]

Has been in Coming Soon for quite a while now :)

@Zanndorin
Copy link

If anyone missed it:
Beginning on April 2, 2019, any new Fargate task launched supports injecting sensitive data into your containers by storing your sensitive data in either AWS Secrets Manager secrets or AWS Systems Manager Parameter Store.

@sarojgharat
Copy link

sarojgharat commented Apr 4, 2019 via email

@Zanndorin
Copy link

Zanndorin commented Apr 4, 2019

@sarojgharat We have started doing a workaround creating the container_definitions outside of CFN and then letting CFN referencing it when creating the task. Which works just fine for our needs..

@sarojgharat
Copy link

sarojgharat commented Apr 4, 2019 via email

@Zanndorin
Copy link

Well

{
   "containerDefinitions": [ 
      { 
         "name": "Service",
         "image": "XYZ:1.0.37",
         "environment": [
          {
            "name": "ENV_NAME",
            "value": "prod"
          },
        "secrets": [
          {
            "name": "XYZ_PASSWORD",
            "valueFrom": "arn:aws:ssm:region:accountid:parameter/secretname"
          }],
        "logConfiguration": { 
          "logDriver": "awslogs",
            "options": { 
              "awslogs-group" : "",
              "awslogs-region": "",
              "awslogs-stream-prefix": "XYZService"
            }
          }
      },

Then we have a script that checks for changes on this file and pushes it. We then change the Revision number we want to deploy by hand actually (organizational process) but you could for example let your CFN always run the latest (by not specifying a number) but then I think CFN has problems finishing the creation of the stack...

@cornerman
Copy link

Is it somehow possible to specify the Version of a systems manager parameter?

I tried parameter NAME:VERSION but then I get an error:

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

@kiros-sc
Copy link

Hello I believe I might have an issues with this integration?
I'm setting up FireLens using Fargate and Http container as a test, sending the httpd log to datadog. When I tried to define the "apiKey" using a secret in secretsmanager the containers starts but the connection to datadog returns 400. When I pass the "api-key" literally, I see it on the conf of the container, and the connection works.

I check if I was able to get the value of the secret using the aws CLI, and yes, doe it brings more than just the value of the secret. I'm wondering if maybe there might be and issue with this when using the secret on ECS?

@fenxiong
Copy link

@kiros-sc can you send your task definition (the one that failed) to ecs-agent-external AT amazon.com so we can take a look? thanks.

@kiros-sc
Copy link

kiros-sc commented Nov 22, 2019

Ok, mail sent with the TaskDef on it.

@kiros-sc
Copy link

I hope this doesn't bother anyone but I found the solution to my issue. It was more related to how I was creating the "secret" in the secret manager.
At first I thought the issue was related to having a diferent "secret name" and "Name" in the "secretOptions" (task definition), yesterday that seem to be solving the issue, but, looking into two differents documents from amazon I change the way I created the "secret", instead of using the "key/value" pair, I created it as "plaintext", replacing any existing text with the "value" of my datadog apiKey, and when require to set the "secret Name" set the work apikey (just in case). After that the issue was gone.

This morning I used another secret which was created the same way, using "plain text" ()not the key/value, but as "secret Name" it was used the word "datadog", updated my task configuration with the new ARN and carefull here, setting the "name" in the "secretOptions" to "ApiKey" (just in case try different way to set that up >> apikey, Apikey, apiKey and ApiKey) and the issue was gone aswell.

So resuming all of this... I believe my issue was resolved when creating the secre using the "plaintext" setting.
Hope this helps someone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ECS Amazon Elastic Container Service Fargate AWS Fargate
Projects
None yet
Development

No branches or pull requests