了解服务主体
服务主体提供了一种对管道、应用程序和软件进行身份验证的方法。 在本单元中，你将了解服务主体为何对部署管道很重要，它们如何适应 Azure 的安全模型，以及它们如何工作。
管道为什么需要进行身份验证？
部署 Bicep 模板时，你可有效地要求 Azure 资源管理器创建或修改 Azure 资源。 在此示例场景中，你创建了一个 Bicep 模板来部署你的玩具公司的网站。 Bicep 模板声明的资源包含一个 Azure 应用服务计划、一个应用和一个 Application Insights 实例。
部署模板时，资源管理器会检查资源是否存在。 如果不存在，资源管理器会创建它们。 如果已存在，资源管理器会确保其配置与你在模板中指定的配置匹配。
所有这些操作都需要权限，因为它们会访问和修改你的 Azure 资源。 部署所需的特定权限取决于模板包含的内容。 若要为你的玩具公司网站部署示例 Bicep 模板，你需要在要部署到的资源组中具有以下权限：
- 创建部署的能力。 部署被认为是
Microsoft.Resources/deployments类型的资源。 - 创建和修改应用服务计划与应用的能力。
- 创建和修改 Application Insights 实例的能力。
到目前为止，你可能已使用 Azure CLI 或 Azure PowerShell 自行部署了 Bicep 模板。 使用这些工具时，你通常使用自己的用户帐户，并使用浏览器进行身份验证。 这称为自带标识。 提交部署时，Azure 会验证你的标识是否具有必要的权限来执行 Bicep 模板指定的操作。
移动到管道后，你需要使用其他类型的标识，因为管道会自行运行部署，无需你直接参与。
安全主体的类型
Microsoft Entra ID 是管理 Azure 标识的服务。 Microsoft Entra ID 具有多种类型的标识，也称为安全主体：
- 用户表示通常使用浏览器进行交互式登录的人。 用户在登录时通常需要执行其他安全检查，例如多重身份验证 (MFA) 和基于其位置或网络的条件访问。
- 组表示用户的集合。 组不直接进行身份验证，但它们提供了一种便捷方式来将权限同时分配给一组用户。
- 服务主体表示一个自动化进程或系统，通常没有人直接运行它。
- 托管标识是一种特殊类型的服务主体，专用于身份验证过程中不涉及到人的情况。
服务主体
服务主体是一种帐户类型。 它可登录到 Microsoft Entra ID，但是没有真人登录，也没有真人与身份验证过程交互。 服务主体没有 MFA 或类似保护，因为这些要求人员执行某些操作来证明其身份。
在 Microsoft Entra ID 中，服务主体由应用程序 ID 和凭据标识。 应用程序 ID 是全局唯一 ID (GUID)。 对于管道，凭据通常是称作密钥的强密码。 或者，你可使用证书作为凭据。
托管标识
与其他类型的服务主体相比，托管标识不需要你知道或维护其凭据。 托管标识与 Azure 资源相关联。 Azure 会自动管理凭据。 当资源需要访问某些内容时，Azure 会使用凭据自动登录。
托管标识可用于 Azure 托管资源，例如虚拟机和应用服务应用。 在自动执行 Azure 管理、连接数据库和从 Azure Key Vault 读取机密数据等情况下，它们是 Azure 资源对自身进行身份验证的最佳方式。 还可以通过 Azure Arc 将托管标识用于其他场景。
使用管道时，通常无法使用托管标识。 这是因为托管身份要求你拥有并管理运行部署的 Azure 资源。 使用 Azure Pipelines 时，通常依赖于 Microsoft 提供的共享基础结构。
备注
在某些情况下，管道可使用托管标识。 在 Azure Pipelines 中，你可创建一个自托管代理，通过在自己基于 Azure 的虚拟机上使用它来运行管道的脚本和代码。 因为你拥有虚拟机，所以可为其分配一个托管标识，并从管道使用它。
但是，在大多数情况下，管道使用托管代理运行，这是 Microsoft 管理的服务器。 托管代理目前与托管标识不兼容。
提示
在解决方案的其他部分，如果要在使用托管标识和使用常规服务主体之间进行选择，最好使用托管标识。 它们更易于使用，且通常更安全。
为什么无法直接使用用户帐户？
你可能想知道，当你拥有运行良好的用户帐户时，为什么需要创建这种全新的对象类型来对管道进行身份验证。
用户帐户不是为无人参与的使用而设计的。 用户帐户的身份验证过程通常会检查人员是否是尝试登录的实体。 越来越多的组织在身份验证过程中使用其他安全检查。 这些检查包括 MFA、CAPTCHA 检查，还有检查用户使用的设备和网络，以便可验证登录请求是否合法。
管道用来运行你的部署，即使在无人主动运行它们时。 事实上，管道的主要优势源于它们是完全自动化的，无需人机交互。 如果将用户名和密码存储在一个管道中，并尝试使用它们来登录，则它们可能不起作用。 即使它们似乎可正常工作，但将来如果 Microsoft Entra ID 或组织管理员在用户身份验证过程中添加更多的安全检查，它们也很容易中断。
警告
将用户名和密码随处保存也是一个糟糕的想法，因为其他人可能会访问它们，然后使用它们来冒充你。
出于这些原因，与 Azure 交互的内置管道任务禁止你提供用户帐户的凭证。 它们要求你使用服务主体。
服务主体如何工作？
在使用服务主体或工具（例如 Azure 门户或 Microsoft Graph API）时，你可能会看到一些不同的术语。 虽然仅在管道中使用服务主体并不一定要理解这些术语，但了解一点概念是有帮助的。
服务主体是 Microsoft Entra ID 的一项功能。 Microsoft Entra ID 是一项全局标识服务。 许多公司使用 Microsoft Entra ID，每个公司则称为租户。
Microsoft Entra ID 具有应用程序的概念，它表示系统、软件片段、进程或一些其他非真人代理。 你可以将部署管道看作是应用程序。
在 Microsoft Entra ID 中，应用程序可执行身份验证和管道部署范围以外的许多操作。 在创建应用程序并将其告知 Microsoft Entra ID 时，你将创建一个称为应用程序注册的对象。 应用程序注册表示 Microsoft Entra ID 中的应用程序。
服务主体和应用程序紧密关联。 每当将应用程序注册添加到 Microsoft Entra 租户时，都会在该 Microsoft Entra 租户中创建服务主体对象。 当你在 Azure 门户中查看服务主体时，会看到其他许多可能看起来不相关的功能和配置。 这主要是因为服务主体与应用程序相关联。
创建服务主体时，使用的大多数工具同时也会创建应用程序注册。 因此，你可能没有注意到有两个不同的对象。
有一种类型的服务主体与应用程序注册没有关联，它是托管标识。 如前所述，Azure 会管理托管标识的配置和凭据。
备注
服务主体有时称为企业应用程序。 某些工具使用一个名称，其他工具使用另一个名称。 你可能还会在本地目录中看到名为“托管应用程序”的服务主体，但它们与托管标识不同。
总之，在创建服务主体时，首先创建应用程序注册，然后创建该应用程序注册要使用的服务主体。 你使用的大多数工具将代你执行此操作，因此你甚至注意不到。 在使用部署管道时，你可能不会用到 Microsoft Entra 应用程序的所有功能。 即便如此，由于服务主体与应用程序相关，因此适用相同的 Microsoft Entra 对象结构。