在内部，托管身份是特殊类型的服务主体，它们被锁定为仅用于Azure资源。删除托管身份时，将自动删除相应的服务主体。此外，创建用户分配或系统分配的身份时，托管身份资源提供程序（MSRP）会在内部向该身份颁发证书。

• 来源：What are managed identities for Azure resources?*

和

有什么区别

简而言之，托管身份和服务主体之间的区别在于，托管身份代表您管理服务主体的创建和自动续订。

• 来源：What’s an Azure Service Principal and Managed Identity?*

托管标识是服务主体的一种类型。
服务主体可以是以下三种类型之一：应用程序、托管身份和遗留。对类型的划分基于它们的使用环境。因此，它们的具体处理也基于它们的类型而不同。
rickvdbosch提供了一篇文章的链接，该文章讨论了服务主体的托管身份类型的细节。对于那些想了解服务主体对象及其类型的概念的人，这里是另一篇文章的链接：Application and service principal objects in Azure Active Directory。

业务负责人

我们可以说服务主体中最相关的部分是Azure Active Directory下的Enterprise Apps部分。这基本上是一个应用程序，它允许您的用户应用基于RBAC进行身份验证和访问Azure资源。
它本质上是需要访问Azure资源的应用程序的ID。通俗地说，想象一下，如果您必须向同事分配某些访问权限，以便他/她可以访问Azure资源并执行所需的任务，您可以使用他们的电子邮件ID作为对用户进行身份验证的方式。

身份管理

我们可以说，托管身份实际上是服务主体，它们在功能和用途上是相同的。
唯一的区别是，托管身份始终链接到Azure资源，不像上面提到的应用程序或第三方连接器。它们是自动为您创建的，包括凭据;一个很大的好处就是没有人知道
有两种类型的托管身份：
1.)系统分配;在这种情况下，身份被链接到单个Azure资源，例如虚拟机，Web应用程序，函数...几乎任何东西。接下来，它们也与Azure资源“共存”，这意味着当Azure资源被删除时，它们也会被删除。
2.)User Assigned Managed Identity，这意味着您必须首先将其创建为独立的Azure资源，然后才能将其链接到多个Azure资源。此处的示例可能与Key Vault不集成，其中属于同一应用程序堆栈的不同Workload服务需要从Key Vault读取信息。在这种情况下，可以创建“读取KV”托管身份，并将其链接到Web应用程序，存储帐户，功能，逻辑应用程序......所有属于同一应用程序架构。

Azure服务原则就像一个应用程序，其他Azure资源可以使用其令牌来验证和授予对Azure资源的访问权限。
托管身份是特殊类型的服务主体，它们被锁定为仅与Azure资源一起使用。
两者之间的主要区别是，在托管身份中，您不需要在代码中指定任何凭据，而服务原则则需要指定应用程序ID，客户端ID等来生成令牌以访问任何Azure资源。理想情况下，只有当您使用的服务不支持托管身份时，您才应该选择服务主体。

托管标识与资源（VM、Logib App等）绑定。要给予资源访问（CRUD）其他资源的赠款和权限，请使用托管标识。
Service Principial不必绑定到资源，它们在租户和订阅之上，更重要的是-有一些可以存储在某个地方（密钥库）的授权令牌。这就像一个拥有一些凭证和令牌的假用户。

在更传统的本地应用程序或服务方案中，服务主体可以被视为类似于服务帐户。托管身份用于将服务主体安全对象“链接”到Azure资源，如虚拟机、Web应用程序、逻辑应用程序或类似资源

（优点）托管身份与服务主体有何不同？

1.它们始终链接到Azure资源，而不是应用程序或第三方连接器。
1.创建资源时自动创建（对于resources that support wielding managed identities。
有两种“口味”：用户分配***和***系统分配，以上句子指的是后者;即使在资源创建时没有设置，也可以通过单击启用。
1.托管身份使用access tokens，无需凭证。
为了设置服务主体，需要提供服务的客户端ID、租户ID和密码/秘密（例如，作为环境变量）。
相反，从/通过MSI资源访问目标资源是通过access tokens完成的。
(The这些内容最初摘自“揭秘服务主体-托管身份”一文，但经过充分改写，直接引用这些内容并不适用。）

缺点

在我看来，复杂性：

• 必须彻底理解“身份”、“安全主体”、“服务主体”、“角色”等术语以及它们之间的关系。
• 令牌使用起来并不简单。

文档到处都是，我做的大部分事情都是通过反复试验（...并在网上查找大量的错误信息）。
例如，请求令牌需要使用root资源URI（在密钥保管库的情况下，它是https://vault.azure.net），并且需要在特定的目标资源上使用。后者很简单，但前者不是。不确定这在文档中的位置，但它让我陷入了一段时间的兔子洞（例如，参见this thread）。

• 其他怪癖

注意事项
这些可能不是其他工具（如Azure CLI）中的问题-或者我可能忽略了一些东西...

• 在门户上查找托管身份（MSI）
  用户分配的MSI有自己的子类别“托管身份”，但不会显示系统分配的MSI，后者需要单独搜索。
• 资源组和MSI

这只是基于我在Portal上的经验，但似乎系统分配的MSI不属于资源组（或隐藏），即用户分配的在调用时显示清楚，但系统分配的MSI找不到此信息，这是没有意义的。后者与MSI resource紧密相连，所以我去了特定资源的资源组，列出了所有成员，但他们也没有显示在那里。奇怪。

条款

Azure标识的快速概述（其中“标识”指Azure Active Directory标识）：

│
    ├─► user
    │
    ├─► group
    │                  managed
    └─► service  ────► identity
       principal      (MSI)

*服务负责人

应用程序或服务用于访问特定Azure资源的安全标识。您可以将其视为应用程序的用户标识（用户名和密码或证书）。
(from Steps to assign an Azure role）
或

• 当组织使用Azure Active Directory时，其令牌可用于从用户应用程序、服务或自动化工具对特定Azure资源进行身份验证和授予访问权限的应用程序 *

本质上，通过使用服务主体，您可以避免在Azure AD中创建“假用户”（我们将其称为本地Active Directory中的服务帐户...），以便在需要访问Azure资源时管理身份验证。
(from揭秘服务主体-托管身份）

管理身份（MSI）
托管身份（MSI）是一种特殊类型的 * 服务主体 ，分配给an Azure resource that supports wielding managed identities以访问其他Azure服务/资源而无需凭据。

(from this answer）

***托管身份***与***服务主体***在功能和用例上本质上是100%相同的，实际上它们就是服务主体。

(from揭秘服务主体-托管身份）

*MSI资源：an Azure resource that support having (or endowed with) managed identities
*目标资源：MSI resource尝试访问的Azure资源