Workmail导出作业无法扮演角色问题排查及相关咨询

核心问题 #

通过编程方式创建Workmail邮箱导出作业时失败，错误信息显示：Unable to assume role "arn:aws:iam::{Account}:role/ApiReadRole"，已配置具备S3写入权限的IAM角色，并尝试添加Workmail作为信任主体，但问题未解决。

疑问解答 #

1. 控制台中导出作业的位置 #

AWS控制台没有提供Workmail导出作业的可视化管理界面，仅能通过AWS SDK（如boto3）、CLI或REST API来创建、查询和管理导出作业。

2. sts:AssumeRole策略的配置要求 #

需要为ApiReadRole配置正确的信任关系，允许Workmail服务扮演该角色。你的当前信任配置存在两处问题：

当前信任配置：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::{My Account}:user/{The username associated with the account}",
                "Service": [
                    "workmail.amazonaws.com",
                    "s3.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

修正方案：

1. 移除不必要的主体：删除s3.amazonaws.com，因为S3无需扮演该角色，只有Workmail服务需要通过该角色执行导出操作
2. 指定区域化服务主体：Workmail的服务主体需要指定作业所在区域（例如你的作业在us-west-2，需使用workmail.us-west-2.amazonaws.com，而非全局的workmail.amazonaws.com）

修正后的信任关系示例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "workmail.us-west-2.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "{你的账号ID}"
                }
            }
        }
    ]
}

额外必要检查 #

• 确认ApiReadRole的权限策略包含以下权限：
  • s3:PutObject（针对目标S3桶communications及前缀media/private/emails）
  • kms:GenerateDataKey（如果使用KMS加密S3对象，需对应指定的KMS密钥）
• 检查KMS密钥的密钥策略，是否允许ApiReadRole执行kms:GenerateDataKey操作
• 确保角色没有附加其他IAM权限边界或组织SCP限制，阻止Workmail服务扮演该角色

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