了解服务主体
服务主体提供了一种对管道、应用程序和软件进行身份验证的方法。 在本单元中，您将了解为什么服务主体对于部署管道很重要，它们如何适应 Azure 的安全模型，以及它们的工作原理。
为什么管道需要进行身份验证？
部署 Bicep 模板时，可以有效地要求 Azure 资源管理器创建或修改 Azure 资源。 在此示例方案中，你已创建一个 Bicep 模板来部署玩具公司的网站。 Bicep 模板声明的资源包括 Azure 应用服务计划、应用和 Application Insights 实例。
部署模板时，Resource Manager 会检查资源是否存在。 如果没有，Resource Manager 将创建它们。 如果已存在任何配置，Resource Manager 将确保其配置与您在模板中指定的配置匹配。
所有这些作都需要权限，因为它们访问和修改 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 管理、连接到数据库以及从 Azure Key Vault 读取机密数据等情况下对自身进行身份验证的好方法。 对于其他方案，还可以将托管标识与 Azure Arc 一起使用。
使用管道时，通常不能使用托管标识。 这是因为托管身份要求您拥有和管理运行部署的 Azure 资源。 使用 Azure Pipelines 时，通常依赖于 Microsoft 提供的共享基础结构。
注释
在某些情况下，管道可以使用托管标识。 在 Azure Pipelines 中，可以创建 自承载代理 ，以便在自己的基于 Azure 的虚拟机上运行管道的脚本和代码。 由于您拥有虚拟机，因此您可以为其分配托管身份并从管道中使用它。
但是，大多数情况下，管道使用 托管代理运行，该代理是 Microsoft 管理的服务器。 托管代理目前与托管身份不兼容。
小窍门
在解决方案的其他部分，如果可以选择使用托管标识或使用普通服务主体，最好使用托管标识。 它们更易于使用，并且通常更安全。
为什么不能只使用您的用户帐户？
您可能想知道，当您拥有运行良好的用户帐户时，为什么还需要创建这种全新的对象来对管道进行身份验证。
用户帐户不是为无人值守使用而设计的。 用户帐户的身份验证过程通常会检查人类是否是尝试登录的实体。 组织越来越多地在身份验证期间使用额外的安全检查。 这些检查包括 MFA、CAPTCHA 检查以及检查用户正在使用的设备和网络，以便他们可以验证登录请求的合法性。
Pipelines 旨在运行您的部署，即使没有人主动运行它们。 事实上，管道的大部分好处来自于它们是完全自动化的，不需要人工交互。 如果您将用户名和密码存储在管道中并尝试使用它们登录，则它们可能无法正常工作。 即使它们看起来确实有效，如果 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 对象结构适用。