非AWS环境下使用AWS CLI、Boto3安全访问AWS资源的最佳实践及IAM角色相关疑问

嗨，我来帮你理清这些疑问，结合AWS的最佳实践给你拆解一下：

首先，先解答你最疑惑的点：用IAM角色+source用户的好处在哪？ #

你说得没错，假设角色确实需要一个“源身份”（比如文档里的user1），而这个用户确实需要长期密钥，但这么做的优势比直接用IAM用户访问资源大太多：

• 权限风险可控：你可以给这个source用户设置最小权限——只允许它执行sts:AssumeRole操作，完全没有直接访问S3或其他资源的权限。就算这个用户的密钥泄露了，攻击者最多只能假设你指定的那个角色，而角色本身的权限是你严格限定的（比如只允许上传到特定S3桶），而且角色的临时凭证是短期有效的（默认1小时，最长可设12小时），过期就失效了，不像长期密钥泄露后风险会一直存在。
• 权限粒度更灵活：你可以给不同的脚本/服务创建不同的IAM角色，每个角色只拥有它需要的权限（比如一个角色负责S3上传，另一个负责日志推送），而不用给单个IAM用户加一堆杂乱的权限。如果后续某个脚本不需要了，直接删除对应的角色就行，不用修改用户权限。
• 审计追踪更清晰：CloudTrail里会记录谁（哪个source用户）假设了哪个角色，以及角色执行的所有操作，你能精准区分不同脚本的行为，排查问题更方便。而直接用IAM用户的话，所有操作都归到这个用户名下，很难区分是哪个脚本做的。

非AWS服务器上的最佳实践（适合你的系统服务脚本） #

因为你的脚本是自动运行的系统服务，没法用交互式的SSO，最推荐的方案是最小权限IAM用户 + 专用IAM角色，具体配置步骤大概是这样：

1. 创建一个专用的IAM角色：比如命名为S3RegularUploadRole，给它配置仅允许上传目标S3桶的权限（比如s3:PutObject、s3:ListBucket等，只加你需要的权限）。
2. 创建一个最小权限的IAM用户：比如命名为RoleAssumeUser，只给它添加一条权限策略：允许它假设上面的S3RegularUploadRole，策略示例大概是：

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "sts:AssumeRole",
         "Resource": "arn:aws:iam::你的AWS账号ID:role/S3RegularUploadRole"
       }
     ]
   }
   

3. 配置AWS CLI/SDK的凭证文件：
   • 在服务器的~/.aws/credentials文件里，只保存这个RoleAssumeUser的访问密钥和密钥ID：

     [RoleAssumeUser]
     aws_access_key_id = 你的用户访问密钥ID
     aws_secret_access_key = 你的用户密钥
     

   • 在~/.aws/config文件里，配置一个使用角色的profile：

     [profile S3Uploader]
     role_arn = arn:aws:iam::你的AWS账号ID:role/S3RegularUploadRole
     source_profile = RoleAssumeUser
     region = 你的S3桶所在区域
     

4. 在脚本里指定这个profile：比如用AWS CLI的话加--profile S3Uploader参数；用boto3的话，初始化客户端时指定profile_name='S3Uploader'。

额外的安全加固建议 #

• 给服务器上的.aws目录和凭证文件设置严格的权限：比如chmod 700 ~/.aws、chmod 600 ~/.aws/credentials，只有运行脚本的系统用户能访问。
• 启用AWS CloudTrail，监控所有的角色假设和S3操作，一旦发现异常可以及时响应。
• 定期轮换RoleAssumeUser的长期密钥（比如每90天），或者用AWS Secrets Manager自动管理密钥轮换，进一步降低风险。
• 在IAM角色的信任关系里，只允许RoleAssumeUser来假设它，避免其他身份滥用这个角色。

备注：内容来源于stack exchange，提问作者Plebo13