Azure 应用的托管身份与服务主体

Microsoft Entra ID -- 前称 Azure Active Directory -- 提供强大的身份验证和授权功能。托管身份和服务主体通过限制凭据暴露的风险来帮助确保对 Azure 资源的访问安全。

托管身份为Azure原生应用程序自动管理身份，而服务主体则非常适合需要访问Azure资源的外部应用程序。

托管身份简化了授予Azure服务访问其他资源的过程，通过自动管理标识来实现。相比之下，服务主体提供了更详细的控制级别，对于自动化任务和将外部应用程序集成到Azure资源中至关重要。区分这两种方法提高了安全性，并简化了资源管理和运营效率。

在比较 Azure 中的托管身份和服务主体时，出现以下关键差异：

身份分配和删除。
自动与手动凭据管理。
凭据暴露和风险。
在 Azure 原生应用程序与外部应用程序中的使用。

理解这些身份验证方法对于维护安全和高效的云基础设施至关重要，无论是配置需要访问存储账户的虚拟机，还是使用 Azure DevOps 自动化部署。

托管身份（managed identity）

Microsoft Entra ID 中的受管身份使 Azure 服务能够在不安全地管理凭据的情况下，向其他 Azure 资源进行身份验证。它自动提供一个可以获取 Entra ID 令牌的身份。这个过程消除了硬编码凭据的需要，从而增强了安全性，并简化了身份验证和授权。

受管身份有两种选项可供选择：

系统分配的托管身份。
用户分配的托管身份。

什么是系统分配的托管身份？

系统分配的托管身份是与 Azure 服务实例（例如 VM 或 Web 应用）一起自动创建的。该身份与该资源绑定，使其易于管理但无法共享。例如，由于该身份与服务共享相同的生命周期，删除服务也会删除该身份。这种类型的身份在单个资源需要访问其他 Azure 资源并且需要最少的管理时效果最好。系统分配的托管身份具有以下属性：

自动创建。
标识生命周期与服务绑定。
需要最少的管理。
最适用于单个资源。

什么是用户分配的托管身份？

一个具有用户分配的托管身份的Azure资源独立操作，用户可以将该身份分配给一个或多个服务实例。用户手动创建该身份作为独立资源，并与任何服务实例分开管理。该身份在明确删除之前会一直存在。当多个资源共享相同身份时，这个资源特别有用。当用户需要对身份的生命周期管理有更多灵活性和控制时，它也是有益的。总之，用户分配的托管身份具有以下特点：

独立创建。
可以在多个资源之间共享。
更大的管理控制。
需要手动删除。

演示

让我们快速演示一个场景，使用虚拟机作为 Azure 资源：

从 Azure 门户中，选择虚拟机；在设置中找到身份。

将状态设置为开启，并保存更改。

然后切换到 Azure key vault / IAM，我们可以定义这个系统分配的托管身份，拥有reader. role（或其他权限）。例如，读取 Azure 存储帐户的访问密钥或类似的东西。在指派的对象中选择managed identity。

同样，让我们在下一个示例中移除虚拟机的系统分配托管身份，使用用户分配的身份（一个 Azure 资源只能链接一个，不能同时链接两个……）：从 Azure 虚拟机面板中，导航到身份并将“状态”切换按钮关闭。保存设置时会提示您进行确认。

创建一个user managed identity

然后将该user managed identity指派给这台web01 vm。

最后在key vault /IAM中为该user identity分配read role。让它能够读取key valut 中的secret。

保存更改后，结果是现在 Azure 虚拟机以及分配给它们的用户分配的托管标识的 Web 应用程序都可以从 Azure 密钥保管库中读取我们的secret。

什么是服务主体？

服务主体的定义

服务主体是Microsoft Entra ID中的一种安全身份，使得应用程序、托管服务和自动化工具能够安全地访问Azure资源。它的功能类似于用户身份，但它代表的是一个应用程序或服务，需进行身份验证并获得授权以访问特定资源，而不是人类用户。

服务主体的分类

服务主体使得应用程序能够以最小权限登录并执行任务，确保操作的安全性。Azure中有三种主要类型的服务主体：

应用程序服务主体。当应用程序在Microsoft Entra ID中注册时，会创建应用程序服务主体。它们代表该应用程序在其部署中的身份，使其能够在Azure或Microsoft Entra ID中进行身份验证并访问资源。
托管身份服务主体。在Azure上启用托管身份时，会创建托管身份服务主体。这种类型的主体通过为应用程序提供身份，简化了凭证管理，使其能够连接到支持Azure身份验证的资源。
传统服务主体。这些主体是较旧的方法，通常涉及手动管理凭证，例如密码或证书。组织通常在现代身份验证机制不可行的环境中使用这些主体。

演示：

PS /home/rockwang415> az ad sp create-for-rbac --name "rockdevblogsp"

复制这些信息；在 Azure DevOps 服务连接的例子中，这些信息将如下使用：

您只需在相应的参数字段中复制正确的信息：

Subscription Id =  用“/subscriptions/xxxxxx-xxxx-xxxx” 替换
Subscription Name =  从Azure Portal / Subscriptions中查看
Service Principal Id = 从前面的命令的appId获得
Service Principal Key = 从前面命令的password 获得
Tenant ID =  azure ad tenant 标识ID

托管身份与服务主体之间的区别

理解托管身份与服务主体之间的区别对于选择适当的 Azure 资源身份验证方法至关重要。虽然两者都能让应用程序和服务安全地访问 Azure 资源，但它们具有不同的特征和使用场景。
托管身份简化了凭据管理，因为 Azure 会自动处理和轮换它们。服务主体则需要手动处理客户端密钥或证书，并必须安全存储和轮换。
在生命周期和范围方面，用户可以将托管身份分配为系统分配（用于单个资源）或用户分配（可在多个资源之间共享）。与此同时，用户可以独立创建和删除服务主体，从而提供更细致的访问控制。
托管身份适合 Azure 原生资源，而服务主体适合需要与 Azure 交互的外部应用程序或服务。
在安全性方面，托管身份通过避免凭据暴露来增强安全性，由 Azure 管理轮换。相反，服务主体要求严格管理凭据以降低风险。

何时使用

每种方式使用托管身份或服务主体的决定取决于几个因素。当应用程序或服务在 Azure 内运行时，使用托管身份。Azure 可以自动处理凭据管理，并最大程度地降低凭据暴露的风险。托管身份还简化了身份验证过程并自动化身份管理，从而减少了管理工作量。
当应用程序或服务在 Azure 之外运行时，服务主体是最佳选择。它是自动化与 Azure 资源交互的任务或脚本的必要条件，或者需要对权限和访问级别进行更细致的控制。服务主体还对于与外部服务或第三方应用程序的集成是必要的。它们需要安全的凭据处理和持续的管理，但为外部应用程序提供了更多灵活性。
这两种方法都支持 Azure RBAC 进行访问控制，尽管服务主体更适合外部使用。托管身份通过最低限度的凭据暴露简化了合规性，而服务主体需要更严格的政策以满足 GDPR 或 HIPAA 等法规。

真实场景示例

管理身份的一个使用案例是当 Azure Functions 需要从 Azure Queue Storage 读取数据并写入 Azure Cosmos DB 时。用户为函数启用一个系统分配的管理身份，并在 Azure RBAC 中分配必要的角色。这简化了身份验证，并消除了凭据管理，由 Azure 处理安全性和凭据轮换。
对于服务主体，想象一下一个在第三方 CI/CD 工具中将代码部署到 Azure 的 DevOps 管道。用户可以在 Microsoft Entra ID 中创建一个服务主体，分配诸如贡献者的角色，并在 CI/CD 工具中安全存储其凭据。这个设置使工具能够安全地进行身份验证并自动化 Azure 资源管理。