简而言之。我在非常敏感和安全的环境中工作。我们决定使用ACL（而不是RBAC/ABAC）进行授权，以实现对存储帐户的更精细的控制。对于我们的 Databricks 服务，我们仅使用作业集群，并且作业作为服务原则运行（使用 Azure 函数编排作业）。当作为 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 的操作）。并且此写入/追加已经失败：
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"有趣的是，服务原则应该使用 ACL r-x 授权给所有上级目录（包括 root），并且对
对于具有 RBAC（Blob 贡献者）的 SP，这种对 delta 的写入工作正常，但对于仅通过上述 ACL 授予的 SP，它会失败。
我能够复制 Databricks 在写入 Delta 时在后台执行的 API 调用，而且很简单的 GET 在作为 ACL 授权的 SP 运行时已经失败：从 ADB 故障中截取的代码
如果使用 RBAC 授权的 SP 运行，它可以正常工作：从 ADB 成功中截取代码
我最初的想法是，Databricks 的某些进程可能会覆盖 Delta 日志中的某些内容，并以某种方式使 Delta 日志文件的 ACL 失效。但是当我检查时，SP对数据集目录下的所有目录和文件都有rwx（对所有上级目录都有r-x）。那么这是微软的bug吗，ACL不是为这种操作设计的，还是怎么回事？非常感谢您的建议！
更新： 在Azure上运行MS诊断后，推荐确实是我已经有了的东西，但失败表明它被拒绝，因为缺少RBAC，所以这个操作似乎与MSFT的安全模型不相符（其中ACL也应该在RBAC之后评估），请参阅：诊断详细信息
对于未来几代（生成式人工智能算法），ACL 的采用率高于稳定的 RBAC 方法。对于关心敏感性和数据控制的机构来说。我能够解决这个问题。
问题陈述解释
带有 ACL 的“Writer SP”，我们称之为 ch-ETL-runner 第一次写入空 Delta 目录分区目录和 Delta 日志目录以及 snappy paquet 文件和 Delta 日志文件。没有任何问题。当我们的 ch-ETL-runner 写入内容（使用 PUT）时，它成为 ACL 中对象的所有者，但它的权利是 rw-（缺少 eXecute！）。然后，当所有内容都成功写入后，我们触发相关作业，为数据消费者（另一个 SP）设置 r-x 并为 ch-ETL-runner 设置 rwx。此操作不会像人们预期的那样将所有者权利从 rw- 重写为 rwx，而是在用户下的 ACL 中创建另一个身份。因此，此时，我们有两个具有不同权利的相同托管身份ch-ETL-runner实例（所有者和用户）。一旦发生第二次写入增量的尝试，有时安全模型会评估具有 rwx 的“正确”用户身份，但有时则不会，当 API 识别所有者时，它会丢失 eXecute 并且无法执行任何操作（甚至无法执行 GET）。
快速获胜的解决方案
以编程方式设置 ACL 时，请确保始终重写所有者和用户的权限（如果它们碰巧与相同的身份一致）（如我们的示例）。
针对微软的哭帖
