我想提高部署的安全性，将秘密密钥存放在安全的地方。
所以我遵循了本教程：How to Manage Secrets for Amazon EC2 Container Service–Based Applications by Using Amazon S3 and Docker 但是没有CloudWatch模板（我已经有了VPC，集群和其他实例） 我正在使用我自己的项目（一个Flask应用程序可以正常使用任务定义中的秘密）
我设置了S3存储桶，VPC端点，一切正常。 但是当我的docker容器启动时，我收到了一个错误：
download failed: s3://[my-bucket]/[my-secrets].txt to - An error occurred (403) when calling the HeadObject operation: Forbidden
当入口点脚本运行命令
时，基本上会发生这种情况aws s3 cp s3://${SECRETS_BUCKET_NAME}/secrets.txt -
注意：我在任务定义中定义了SECRETS_BUCKET_NAME，以及其他不需要保密的变量。
首先我认为我的实例没有正确的角色，因此出于调试目的，我将其附加了AdministratorAccess策略，但没有成功。
其次，我读到Docker容器共享主机的凭据（EC2实例），因此我直接在实例上安装了aws-cli包，并为具有AdministratorAccess策略的用户设置凭据。
现在我可以在我的实例登录命令
时手动运行aws s3 cp s3://${SECRETS_BUCKET_NAME}/secrets.txt -
它工作正常，但我的容器仍然出现403错误。
我的EC2实例是amzn-ami-2017.03.c-amazon-ecs优化图像（奇怪的是，不包括aws-cli）
如果有人知道我做错了什么......
答案 0 :(得分：0)
解决！
我将AMI更新为更新的AMI，重新制作了适当的角色并且有效。
我注意到一个奇怪的事情：ECS优化亚马逊的AMI不包括aws-cli。
答案 1 :(得分：0)
还有一个潜在的问题可能会导致 AWS CLI 在容器中运行时拒绝访问，而直接在主机上运行完美无缺。
如果您切换到 IMDS v2 并设置策略来拒绝使用 IMDS v1 凭证的操作，它可能会阻止所有 AWS CLI 调用，因为：
默认的 ECS 启动配置设置将 instance-metadata-options' w http-put-response-hop-limit 设置为 1，
docker 为网络连接引入了一个额外的层，因此需要 2 跳才能到达元数据，
因此，AWS CLI 无法从元数据中获取令牌，因此切换到 IMDS v1，然后被上述策略阻止。
解决方法是将 http-put-response-hop-limit 设置为 2。