docker - 在 docker 中将 secret 作为环境变量注入(inject)安全吗？为什么ECS和EKS支持它？

Question

我很难协调一些在线建议，即将 secret (通常是密码)作为环境变量注入(inject) docker 容器与 AWS ECS 甚至 EKS 的 native 功能“不安全”，其中存储在 AWS Secrets Manager 中的 secret 作为环境提供变量。我想使用这些平台的原生特性，但似乎这不是一个好主意。
很喜欢土生土长的/run/secrets “原始” docker 的方法 - 但该功能无法扩展到 SecretsManager+ECS。我认为管理 secret 和向我的应用程序公开的唯一“安全”方式是编写直接查询 AWS Secrets Manager 的专用应用程序代码。这个结论正确吗？或者我可以信任这个平台吗？
引用:

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

和反驳:

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

Answer 1

我认为这些文章中描述的大多数问题都可以通过在读取和确认变量后立即删除/替换变量来缓解。一旦删除，这两种方法之间几乎没有区别。也许 ENV 方法甚至可能会得到一个点，因为将无处读取值，而 secret 文件将一直存在并且无法删除已安装的文件。
我同意那些向您发送崩溃报告的内容可能确实会意外暴露敏感值的文章。但是由您决定何时加载它们。因此，您可以先处理敏感数据，然后启用将处理日志/崩溃的东西。
在一种罕见的情况下，您必须避免对敏感数据使用环境变量:cron .有 cron在容器中本身就是一种不好的做法，最重要的是它会在电子邮件 header 中公开所有环境变量:

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