在 docker 中将机密作为环境变量注入安全吗？为什么ECS和EKS支持它？

Question

我很难协调一些在线建议，即将秘密（通常是密码）作为环境变量注入 docker 容器与 AWS ECS 甚至 EKS 的本机功能“不安全”，其中存储在 AWS Secrets Manager 中的秘密作为环境提供变量。我想使用这些平台的原生特性，但似乎这不是一个好主意。

我真的很喜欢/run/secrets“原始”docker的原生方法 - 但该功能无法扩展到 SecretsManager+ECS。我认为管理秘密和向我的应用程序公开的唯一“安全”方式是编写直接查询 AWS Secrets Manager 的专用应用程序代码。这个结论正确吗？或者我可以信任这个平台吗？

参考：

• 使用环境变量的危险在于，很容易通过日志记录意外泄露机密，因为软件记录整个环境是很常见的。有权访问日志的人员通常比需要生产键值的人员大得多。

• 为什么不应该将 ENV 变量用于秘密数据

和反驳：

• 作为安全最佳实践，将敏感信息作为环境变量传递给容器。

• ...生产机密应通过受控方式（如环境变量）访问

Answer 1

我认为这些文章中描述的大多数问题可以通过在阅读和确认变量后立即删除/替换变量来缓解。一旦将其删除，两种方法之间几乎没有区别。也许 ENV 方法甚至可能会得到一个点，因为没有地方可以读取值，而秘密文件将一直存在到最后，并且安装的文件无法删除。

我同意这些文章的观点，即向您发送崩溃报告的东西确实可能会意外暴露敏感值。但何时加载它们由您决定。因此，您可以首先处理敏感数据，然后启用处理日志/崩溃的功能。

在一种罕见的情况下，您必须避免将环境变量与敏感数据一起使用：cron。放在cron容器中本身就是一种不好的做法，最重要的是它会公开电子邮件标头中的所有环境变量：

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