添加BucketOwnerFullControl配置后GlueContext write_dynamic_frame失败如何解决

核心问题根因 #

你遇到的403报错是添加ACL配置后触发的额外权限校验失败导致的，主要有3个常见原因：

• Glue作业执行角色缺少s3:PutObjectAcl权限：不加ACL配置时，写入S3仅需要s3:PutObject权限；添加ACL配置后，写入时会额外发起设置对象ACL的请求，需要对应权限才能执行。
• S3配置键不匹配：Glue底层默认使用S3A文件系统实现，你配置的fs.s3.canned.acl是旧版S3N文件系统的参数，没有被正确识别生效。
• 配置生效时机错误：如果在DynamicFrame生成后才修改Hadoop配置，写入操作可能已经读取了之前的默认配置，导致配置不生效。

修复步骤 #

1. 补全IAM权限 #

• 给Glue作业关联的IAM角色添加s3:PutObjectAcl权限，资源配置为目标桶路径arn:aws:s3:::目标桶名称/*
• 确认目标跨账号S3桶的桶策略，已经给该Glue角色开放了s3:PutObject、s3:PutObjectAcl两个权限

2. 修正S3 ACL配置 #

将原有的单条配置替换为兼容多版本S3文件系统的配置，在GlueContext初始化完成后第一时间执行：

hadoop_conf = glueContext._jsc.hadoopConfiguration()
# 兼容旧版S3实现
hadoop_conf.set("fs.s3.canned.acl", "BucketOwnerFullControl")
hadoop_conf.set("fs.s3n.canned.acl", "BucketOwnerFullControl")
# S3A实现的正确配置键
hadoop_conf.set("fs.s3a.acl.default", "BucketOwnerFullControl")

3. 验证结果 #

修改配置后重新运行作业，写入的对象所有者会自动变更为目标桶所属账号，不会再出现403报错。

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