Azure中的服务主体和托管身份之间的区别

pgvzfuti  于 2023-04-07  发布在  其他
关注(0)|答案(7)|浏览(176)

我想知道是否总是建议在Azure中使用托管身份,主要是系统分配的还是服务主体?与托管身份相比,什么时候应该在Azure中使用服务主体,两者相比有什么优势?任何帮助都将不胜感激。

6yt4nkrj

6yt4nkrj1#

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

有什么区别

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

cwtwac6a

cwtwac6a2#

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

vptzau2j

vptzau2j3#

业务负责人

我们可以说服务主体中最相关的部分是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应用程序,存储帐户,功能,逻辑应用程序......所有属于同一应用程序架构。

pzfprimi

pzfprimi4#

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

tf7tbtn2

tf7tbtn25#

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

ivqmmu1c

ivqmmu1c6#

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

gudnpqoy

gudnpqoy7#

(优点)托管身份与服务主体有何不同?

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资源

相关问题