AWS IAM User与Role使用疑问：本地Docker运行脚本访问S3是否需配置Role

你这个结论是错误的，在IAM User和业务权限Policy之间加一层Role并非冗余设计，反而能带来多个维度的安全收益，是符合AWS最佳实践的方案，核心原因如下：

• 长期凭证权限最小化
  用于调用AssumeRole的IAM User仅需要授予sts:AssumeRole权限，且可以限制该用户仅能Assume指定的上传专用Role，不需要直接绑定S3上传等业务权限。即使该IAM User的长期AKSK泄露，攻击者也仅能获取该Role的临时凭证，临时凭证默认最长有效期为12小时，可自定义缩短到15分钟，相比泄露带业务权限的长期AKSK，攻击窗口和危害范围会被大幅压缩。
• 权限运维与审计更便捷
  后续需要调整上传相关的业务权限时，仅需要修改Role绑定的Policy即可，不需要调整IAM User的权限，也不需要重新分发更新AKSK。同时所有AssumeRole操作、Role对应的业务操作都会在CloudTrail中留下独立日志，权限溯源、操作审计的维度比直接使用IAM User更清晰。
• 架构扩展性更强
  该架构可以平滑适配后续的部署迁移需求：如果后续将脚本迁移到EC2、EKS等AWS托管服务上，可以直接为计算资源绑定Role，完全移除IAM User长期凭证的使用；如果需要迁移到第三方部署环境，也可以对接OIDC身份提供商、IAM Identity Center等身份源替换IAM User，不需要调整业务权限层的配置。

本地部署的补充注意事项 #

不要将IAM User的AKSK打包到Docker镜像中，推荐通过Docker Secret、宿主机.aws配置目录挂载的方式将凭证注入容器，避免镜像泄露直接导致凭证丢失。
你可以直接通过AWS配置文件实现自动AssumeRole，不需要自行编写STS调用逻辑，示例配置如下：

# ~/.aws/credentials （存放仅拥有AssumeRole权限的IAM User凭证）
[assume-role-base-user]
aws_access_key_id = 你的AK
aws_secret_access_key = 你的SK

# ~/.aws/config （配置上传专用Role信息）
[profile s3-upload]
role_arn = arn:aws:iam::你的AWS账号ID:role/你的上传专用Role名称
source_profile = assume-role-base-user
duration_seconds = 3600

Python代码中直接使用该配置即可，boto3会自动处理临时凭证的申请与刷新：

import boto3
s3_client = boto3.client('s3', profile_name='s3-upload')

内容的提问来源于stack exchange，提问作者OSUDamian