我刚刚开始使用Docker容器并在AWS Fargate中部署它们，我在这里发布更多关于如何将AWS凭证拉到容器的信息(请在下面找到我所做的解释)。我读了很多AWS文档和在线博客/帖子，但我认为有些事情我完全不理解。
我已经创建了一个具有以下权限的IAM用户:
AmazonECS_FullAccessAmazonSESFullAccessCloudWatchFullAccessAmazonS3FullAccessECR_FullAccess(这是我创建的所有弹性容器注册表操作(ecr:*)的自定义策略。
然后，我创建了一个Docker映像，在AWS Fargate上运行Python脚本。该脚本使用SES、S3和CloudWatch服务。此图像已上载至ECR。
出于安全原因，我没有在Dockerfile中硬编码环境变量。我获取环境变量的方式是从S3存储桶中提取一个.env文件。为此，我向ecsTaskExecutionRole添加了一个内联策略，该策略使用这些操作读取S3中的对象和桶位置(在本例中是.env文件)。
对于任务角色，根据我所读到的，它负责IAM角色与其他AWS服务交互。所以我创建了一个新角色，有三个新策略:(1)AmazonSESFullAccess;(2)CloudWatchFullAccess;(3)AmazonS3FullAccess。然后在Fargate中创建新任务时指定此角色。
我的问题是:
- 在我之前描述的内容上是否有不必要的步骤?考虑到容器使用CloudWatch、S3和SES服务(即在Python代码中，我需要为每个服务创建一个客户端)，任务角色和任务执行角色应该如何在策略方面设置?
- 尽管容器成功运行，但我不知道正在提取哪些凭据。例如，如果我在.env文件中设置
AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY，如果我打印它们，在CloudWatch中，当调用os.getenv("AWS_SECRET_ACCESS_KEY")时，它们显示为None。因此，我不知道究竟使用了什么凭据。你能告诉我Fargate是如何管理凭证的吗?
根据您的描述，您不需要IAM用户或.env文件(用于凭据)。一个IAM用户应该代表一个人，这个人的AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY是长期存在的凭据。理想情况下，您永远不希望容器(或EC2)具有长期存在的凭据。
分配给ECS任务的任务Role应该是该任务的凭据源。它应该包含任务需要访问的所有服务的权限。出于安全考虑，您通常希望将其缩减到最小。
当ECS任务启动时，容器将"假设"。授予它的角色。将根据该角色为其生成临时凭据。ECS服务将负责根据需要刷新这些。
如果您的python脚本使用AWS SDK (boto3)，那么它将自动使用容器的凭据，即任务所假定的凭据。您不需要为凭据提供任何额外的环境变量。