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