使用VSTS部署ADLA U-SQL CI/CD遇存储权限错误，求授权方案

我来帮你梳理下这个问题的解决步骤，毕竟在ADLA的CI/CD流程里，权限配置确实是容易踩坑的点：

先搞清楚：VSTS构建用户是不是你的登录ID？ #

答案是不一定，取决于你在VSTS里配置的服务连接类型：

• 如果你的服务连接是用**个人账号（OAuth授权）**创建的，那构建时用的就是你登录VSTS和VS Code的那个账号；
• 如果是用Azure服务主体（这也是生产环境推荐的方式），那构建用户是一个专门的应用身份，和你的个人ID完全无关。

怎么获取构建用户的详细信息？ #

情况1：使用Azure服务主体（推荐生产用） #

1. 打开你的VSTS项目，进入左侧菜单的项目设置 > 服务连接；
2. 找到你用来部署ADLA的那个Azure服务连接，点击「编辑」；
3. 这里会显示服务主体的「应用ID」，复制这个ID；
4. 登录Azure门户，进入Azure Active Directory > 应用注册，在搜索框粘贴刚才的应用ID，就能找到这个服务主体的所有详细信息（比如名称、所属租户等）。

情况2：使用个人账号 #

这种情况下，构建用户就是你的VSTS登录账号（也就是你用来登录VS Code的那个邮箱/ID），你可以直接用这个账号去配置权限。

怎么给构建用户授权存储账户？ #

不管是服务主体还是个人账号，授权步骤都是一样的，要给它分配存储数据相关的角色（注意是数据角色，不是订阅级的管理角色）：

1. 登录Azure门户，找到你ADLA用到的目标存储账户；
2. 进入存储账户的**访问控制(IAM)**页面；
3. 点击「添加角色分配」；
4. 在「角色」里选择合适的权限：
   • 如果需要读写存储里的Blob/文件，选存储Blob数据参与者；
   • 如果只需要读取，选存储Blob数据读取者；
   • 尽量避免用「所有者」这类权限过大的角色，遵循最小权限原则；
5. 在「成员」标签页，选择「用户、组或服务主体」，然后搜索你刚才找到的构建用户ID（服务主体ID或者个人账号邮箱）；
6. 点击「保存」，等待3-5分钟让权限生效（Azure权限有时候不会即时生效）。

额外排查小技巧 #

• 去VSTS的构建日志里找更详细的错误信息，通常会包含请求的用户ID，能帮你精准确认是哪个身份在触发部署；
• 可以本地测试权限：用Connect-AzAccount命令，用构建用户的身份登录（服务主体的话用-ServicePrincipal参数），然后执行Get-AzStorageBlob这类存储操作，看是否能成功，排除脚本本身的问题；
• 确认你的PowerShell脚本里指定的存储账户和你授权的是同一个，别搞混了不同环境的存储资源。

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