问题描述
正在使用现有的docker-compose.yml文件将应用程序迁移到ECS。配置文件引用了几个$ENV变量，以前在运行docker-compose up时，可以将它们作为环境变量传递进去。其中一个变量是密码，以前是在Docker主机上指定的。在ECS中，建议不要将敏感信息与环境变量一起传递，因此用户希望改进这一点，并使用最佳实践。
在Fargate中，用户无法找到如何将这些安全参数传递给ecs-cli compose service up，而不将它们发送到ecs-cli使用的docker-compose中（然后它们最终会显示在控制台上，可能会被记录等）。
ECS CLI文档解释了如何使用SSM：
secrets允许您指定将从SSM参数存储中检索的密钥。有关更多信息，请参见ECS文档，包括如何从SSM参数存储中引用AWS Secrets Manager密钥。value_from是SSM参数的ARN或名称（如果参数与ECS任务位于同一区域）。name是将存储密钥的环境变量的名称。
但在ECS文档中有这样的说明：
“此功能尚不支持使用Fargate启动类型的任务。”
用户猜测”yet”意味着将来会有支持。
用户想知道Fargate是否有当前的替代方案，或者在他们添加对它的支持之前，我们是否必须降低安全性？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
根据用户提供的信息，目前在Fargate中没有完美的解决方案。然而，有几种替代方案可以考虑：
1. 将敏感数据嵌入Docker镜像中：这种方法不适用于开源仓库。
2. 使用ECS环境变量：这种方法不够安全，因为环境变量在AWS控制台中是可见的。
3. Docker从SSM参数存储中获取数据：这种方法是安全的，但在架构上不够优雅。
4. 等待Fargate支持SSM注入敏感数据：这是一个期待的功能，但目前还不支持。
根据用户提供的链接，Amazon已经正式发布了通过SSM在ECS容器中注入敏感数据的支持。这是根据用户反馈从功能请求中得出的一个很好的第一步。目前，Fargate启动类型还不支持，也不支持从单个路径中拉取多个参数，但希望在未来几个月内能看到这些进展。
请注意，如果攻击者可以访问您的AWS控制台，那么您已经处于相当糟糕的境地。因此，使用ECS环境变量可能是一个实际上可以接受的解决方案。
参考链接：
– https://hackernoon.com/secrets-management-within-aws-ecs-1b6975819ccd
– https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html