Is injecting secrets as environment variables in docker secure? Why does ECS and EKS support it?

user_228732 0
Viewed 614

I'm having a hard time reconciling some online advice that injecting secrets (usually passwords) as environment variables into docker containers is "not secure" with the native features of AWS ECS and even EKS where secrets stored within AWS Secrets Manager are provided as environment variables. I want to use the native features of these platforms, but it seems that this is not a good idea.

I really like the native /run/secrets approach of "raw" docker - but that feature doesn't scale up to SecretsManager+ECS. I'm left thinking that the only "secure" way of managing secrets and exposing to my app is to write dedicated application code that queries AWS Secrets Manager directly. Is this conclusion correct? Or can I trust the platform?

References:

And counter-arguments:

aws-secrets-manager amazon-eks amazon-ecs docker
1 Answers

I think most of the problems described in those articles can be mitigated by removing/replacing the variable immediately after it has been read and acknowledged. Once it has been removed there is little to no difference between the two methods. Perhaps the ENV method might even get a point for there will be nowhere to read the value from, while the secret file will be there to the end and as mounted files cannot be removed.

I agree with the articles that things which send you reports on crashes might indeed accidentally expose sensitive values. But it's up to you to decide when to load them. Therefore, you can first deal with sensitive data, then enable the things that will handle logs/crashes.

There is one rare case when you must avoid using environment variables with sensitive data: cron. Having cron in containers is a bad practice by itself and on top of that it exposes all environment variables in email headers:

X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/home/user>
X-Cron-Env: <PATH=/usr/bin:/bin>
user_113445020
Related