为何在Azure DevOps的ARM服务连接中需指定Service Principal？

一、核心概念拆解 #

• 应用注册：可以理解为Azure AD里的「身份模板」，用来登记需要借助Azure AD做身份验证的应用（包括你的Azure Pipelines、自定义脚本程序等）。注册完成后会生成唯一的Application ID，相当于这个应用的「身份证号」。
• Service Principal（服务主体）：这是应用注册在具体Azure租户内的「可操作身份实例」。打个比方，应用注册是公司的「岗位描述」，服务主体就是应聘该岗位的「员工」——它有明确的权限范围，能被分配到特定Azure资源的访问权限，是真正用来执行自动化操作的身份实体。

简言之：应用注册是定义身份的元数据，服务主体是这个身份的实际执行载体。

二、和Azure DevOps ARM服务连接的关联 #

当你在Azure DevOps中创建Azure Resource Manager连接并选择Service Principal认证时，本质是让Azure Pipelines借助这个服务主体的身份，访问并操作你的Azure订阅资源（比如部署ARM模板到虚拟机、存储账户等）。具体逻辑是：

1. 先在Azure AD完成应用注册，系统会自动生成对应的服务主体（也可手动创建）。
2. 给这个服务主体分配Azure订阅内的必要权限（比如Contributor权限，满足ARM模板部署的基本需求）。
3. 在Azure DevOps的服务连接配置中，填入服务主体的Application ID、客户端密钥（或证书）、Azure租户ID、订阅ID这些核心信息。
4. 当Azure Pipelines执行「ARM template deployment」任务时，会用这些信息向Azure AD请求访问令牌，拿到令牌后就可以以服务主体的身份，在Azure订阅内完成模板部署操作。

选择Service Principal作为认证方式的核心原因：它是专为程序/服务设计的身份，不像用户账号有会话过期、MFA验证等限制，能让CI/CD流水线长期稳定地执行自动化操作。

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