Menu
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:
The danger of using environment variables is that it's easy for the secrets to be accidentally leaked through logging, as it's common for software to log its entire environment. The set of people who have access to logs is often much bigger than the people who need production key values.
Why you shouldn't use ENV variables for secret data
And counter-arguments:
As a security best practice, pass sensitive information to containers as environment variables.
...production secrets should be accessed through a controlled means like environment variables
720
Lambda stores environment variables securely by encrypting them at rest. You can configure Lambda to use a different encryption key, encrypt environment variable values on the client side, or set environment variables in an AWS CloudFormation template with AWS Secrets Manager.
Multi cloud portability This is what portability is all about. To achieve it, you need interoperability among cloud services. While ECS is an AWS proprietary technology, EKS is based on Kubernetes, which is open-source. Kubernetes in EKS allows you to package your containers and move them to another platform quickly.
Amazon ECS is a highly scalable, high performance container management service that supports Docker containers and allows you to easily run applications on a managed cluster of Amazon EC2 instances.
There is no one way to inject secrets as environment variables into Docker containers. There are quite a few options of which we will highlight two in this post. To follow along, you will need a couple of things:
When a task is launched using the task definition that you create, the Amazon ECS container agent automatically resolves the secrets and injects the values as environment variables to the container. Important: Sensitive data is injected into your container when the container is initially started.
In general storing secrets in environment variables does have some downsides, as Diogo says in his post. Generically, for platforms like Heroku, or using technologies like Docker where the application is expected to be ephemeral, dedicated secrets management tools are the best way to go.
You can securely inject data into containers by referencing values stored in AWS Systems Manager Parameter Store or AWS Secrets Manager in the container definition of an Amazon ECS task definition. Then, you can expose your sensitive information as environment variables or in the log configuration of a container.
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>
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
