aws
[ECS] [request]: Secrets in file and tmpfs support
Tell us about your request I really enjoy the ability to have secrets made available to my container at runtime through the task definition. However, I'm not a big fan of exposing them as environment variables, as they are easily leaked (diagnostic logs, server info pages, linked containers, etc.).
I would like the ability to indicate a secret for my container, but have the secret be made available as a file (similar to Swarm secrets). My container can then pick up the value from the file. Preferably, the file is mounted in a tmpfs. I personally don't have the need to specify the target location (where in the container to drop the secret), but I imagine other apps might need a specific location.
Which service(s) is this request for? This could be Fargate, ECS, or EKS.
Are you currently working around this issue? Currently, I'm just using the integration as currently available, but would prefer to leverage files instead of env variables. I then would have an env variable that serves as a pointer to the file containing the secret value.
Additional context
Container images that leverage this approach are plentiful. One example is the mysql image. While I wouldn't configure a container this way, I can specify either the MYSQL_ROOT_PASSWORD env variable or the MYSQL_ROOT_PASSWORD_FILE to serve as a pointer to file containing the actual password. This feature change would help customers leverage several off-the-shelf images that already support file pointing.
This feature already exists in EKS.
A secret is only sent to a node if a pod on that node requires it. Kubelet stores the secret into a tmpfs so that the secret is not written to disk storage. Once the Pod that depends on the secret is deleted, kubelet will delete its local copy of the secret data as well.
https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod
@ajohnstone - It’s true for EKS if you’re using the native secrets support. However, there is no current secrets manager integration for EKS (see #168). The goal of this request is to have a similar feature, but utilizing from secrets manager.
In our use case we're adding environment variables to a task definition that point to the arn of a secret stored in AWS Secrets Manager e.g.
MY_SECRET=arn:of/secret/`
These environment variables are then read by the application at startup, secrets are pulled from AWS Secrets Manager and stored using C# secure strings in memory for the lifetime of the application. The coupling of application code to AWS Secrets Manager is something that would be nicer to push out to the control plane. This could also release the development time constraint of the application on AWS Secrets Manager.
@mikesir87 https://github.com/aws/containers-roadmap/issues/263 will also help solve this for EKS.
Thanks @tabern. For my use case, I’m specifically interested in ECS and Fargate, not EKS. Maybe I can update the issue description to allow this to be the ECS/Fargate issue while the other solves EKS.
Secrets in Kubernetes can be mounted as data volumes or be exposed as environment variables. https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets
Our security folks are asking for this feature in ECS/Fargate and it seems like it'd be nice to have feature parity with k8s here.
@mikesir87 - do you feel that this ticket is a duplicate of https://github.com/aws/containers-roadmap/issues/56? If so... it looks like the status (as of 2023-10-19) has moved to "We're Working On It".
We've made a sidecar container that does something similar, see here: https://github.com/elasticscale/elasticscale_envsidecar (it is in testing now), feel free to give feedback!
