使用ACL授权时Databricks写入ADLS Gen2 Delta二次失败问题

问题背景 #

• 环境对安全性要求极高，采用ACL而非RBAC/ABAC实现存储账户细粒度权限控制
• 使用Databricks作业集群，通过Azure Functions以服务主体（SP）运行作业
• 首次写入Delta表可正常执行，代码如下：

if diff_count > 0:
    (df_diff
     .write
     .partitionBy(partition)
     .format(self.trg_format.lower())
     .mode(mode)
     .option("overwriteSchema", overwrite_flg)
     .save(self.trg_location))

• 二次写入（如SCD-2场景下的追加操作）时触发403权限错误：

Operation failed: "This request is not authorized to perform this operation using this permission.", 403, GET, https://[REDACTED].dfs.core.windows.net/lake?upn=false&resource=filesystem&maxResults=5000&directory=[REDACTED]&timeout=90&recursive=false, AuthorizationPermissionMismatch, "This request is not authorized to perform this operation using this permission. RequestId:82f621f0-301f-004f-60c7-9b5197000000 Time:2024-05-01T13:02:06.8819444Z"

• 权限配置：SP对所有上级目录（含根目录）拥有r-x权限，对<dataset_dir>/Delta/及其子目录（如分区目录、_delta_log）和所有文件递归设置rwx权限；仅配置ACL的SP执行二次写入失败，拥有RBAC（Blob Contributor）权限的SP可正常完成操作
• 排查结果：复现Databricks后台的GET请求，仅ACL授权的SP执行失败；Delta日志的ACL配置无误；Azure诊断显示因缺少RBAC权限被拒绝，与微软ACL+RBAC安全模型预期不符

核心原因分析 #

这并非微软Bug，而是Databricks操作Delta表时的特定API调用依赖RBAC权限兜底，ACL无法完全替代：

1. 二次写入时，Databricks会调用Azure存储的文件系统级目录列表GET API（即报错中的请求），该API的权限校验逻辑优先依赖RBAC，而非路径级ACL
2. 首次写入时，SP仅需目标路径的ACL权限即可创建新目录/文件；但二次写入需要遍历上级目录结构，触发的元数据查询类API要求SP拥有存储账户或文件系统级的基础RBAC权限，否则会被拒绝
3. 在微软ACL+RBAC混合模型中，部分批量元数据操作仍需要最低权限的RBAC角色支持，ACL仅针对具体文件/目录的读写操作生效

解决方案 #

1. 给SP添加最小权限的RBAC角色：仅授予Storage Blob Data Reader角色（作用范围限定为目标存储账户或文件系统），该角色仅允许读取存储元数据，不会破坏ACL的细粒度权限控制
2. 验证权限：添加角色后重新执行二次写入操作，确认403错误消失
3. 权限加固：保持SP对<dataset_dir>/Delta/路径的递归rwx ACL权限，避免因权限继承问题引发其他写入故障

补充说明 #

• 避免直接授予Blob Contributor等高权限RBAC角色，防止突破ACL的安全边界
• 若需严格规避RBAC，可尝试修改Databricks Delta表配置，强制使用路径级元数据查询，但该操作可能影响Delta表的分区发现、日志同步等核心功能，需谨慎测试

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