GetAccessPolicyAsync/SetAccessPolicyAsync搭配托管标识运行异常问题咨询

核心原因 #

你遇到的404并非实际资源不存在，这是Azure存储的默认安全策略：当请求方对目标资源没有对应操作的访问权限时，存储服务会返回404 ResourceNotFound而非403 Forbidden，避免攻击者枚举资源的存在性。
你使用StorageSharedKeyCredential时自带存储账户的全量操作权限，所以所有流程正常运行；使用托管标识时权限不足，触发了存储服务伪装的404响应。你之前猜测是Azure.Identity组件获取令牌时触发异常，这个可能性很低：如果令牌获取失败会直接返回401类认证错误，不会返回存储服务的XML格式404响应，当前异常已经明确是存储服务侧返回的。

为什么ExistsAsync()可以正常运行 #

ExistsAsync()仅需要容器的基础读权限，你当前给托管标识分配的角色（比如常见的「存储Blob数据参与者」）已经包含该权限，所以调用正常。但GetAccessPolicyAsync和SetAccessPolicyAsync属于容器权限策略的管理操作，普通的数据读写角色不包含这两个操作的权限。

解决方案 #

要正常调用访问策略相关接口，需要给你的托管标识分配包含以下权限的角色：

• Microsoft.Storage/storageAccounts/blobServices/containers/readPolicies/action（读访问策略权限）
• Microsoft.Storage/storageAccounts/blobServices/containers/writePolicies/action（写访问策略权限）

你可以先给托管标识分配「存储Blob数据所有者」角色验证问题是否解决，确认是权限问题后，再按需创建自定义角色分配最小必要权限即可。

其他可选排查点 #

• 升级SDK版本：将Azure.Storage.Files.DataLake和Azure.Identity包升级到最新稳定版，排除旧版本SDK对托管标识认证的已知适配bug
• 确认终结点配置：初始化DataLakeServiceClient时使用的终结点需要为ADLS Gen2的dfs终结点，格式为https://<你的存储账户名>.dfs.core.windows.net/，不要误用普通Blob终结点
• 确认托管标识配置正确：如果使用用户分配托管标识，需要确认代码中指定了正确的托管标识客户端ID，且角色分配的范围正确覆盖当前存储账户。

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