我想知道是否总是建议在Azure中使用托管身份,主要是系统分配的还是服务主体?与托管身份相比,什么时候应该在Azure中使用服务主体,两者相比有什么优势?任何帮助都将不胜感激。
6yt4nkrj1#
在内部,托管身份是特殊类型的服务主体,它们被锁定为仅用于Azure资源。删除托管身份时,将自动删除相应的服务主体。此外,创建用户分配或系统分配的身份时,托管身份资源提供程序(MSRP)会在内部向该身份颁发证书。
和
有什么区别
简而言之,托管身份和服务主体之间的区别在于,托管身份代表您管理服务主体的创建和自动续订。
cwtwac6a2#
托管标识是服务主体的一种类型。服务主体可以是以下三种类型之一:应用程序、托管身份和遗留。对类型的划分基于它们的使用环境。因此,它们的具体处理也基于它们的类型而不同。rickvdbosch提供了一篇文章的链接,该文章讨论了服务主体的托管身份类型的细节。对于那些想了解服务主体对象及其类型的概念的人,这里是另一篇文章的链接:Application and service principal objects in Azure Active Directory。
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应用程序,存储帐户,功能,逻辑应用程序......所有属于同一应用程序架构。
pzfprimi4#
Azure服务原则就像一个应用程序,其他Azure资源可以使用其令牌来验证和授予对Azure资源的访问权限。托管身份是特殊类型的服务主体,它们被锁定为仅与Azure资源一起使用。两者之间的主要区别是,在托管身份中,您不需要在代码中指定任何凭据,而服务原则则需要指定应用程序ID,客户端ID等来生成令牌以访问任何Azure资源。理想情况下,只有当您使用的服务不支持托管身份时,您才应该选择服务主体。
tf7tbtn25#
托管标识与资源(VM、Logib App等)绑定。要给予资源访问(CRUD)其他资源的赠款和权限,请使用托管标识。Service Principial不必绑定到资源,它们在租户和订阅之上,更重要的是-有一些可以存储在某个地方(密钥库)的授权令牌。这就像一个拥有一些凭证和令牌的假用户。
ivqmmu1c6#
在更传统的本地应用程序或服务方案中,服务主体可以被视为类似于服务帐户。托管身份用于将服务主体安全对象“链接”到Azure资源,如虚拟机、Web应用程序、逻辑应用程序或类似资源
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)。
https://vault.azure.net
注意事项这些可能不是其他工具(如Azure CLI)中的问题-或者我可能忽略了一些东西...
这只是基于我在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 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资源
7条答案
按热度按时间6yt4nkrj1#
在内部,托管身份是特殊类型的服务主体,它们被锁定为仅用于Azure资源。删除托管身份时,将自动删除相应的服务主体。此外,创建用户分配或系统分配的身份时,托管身份资源提供程序(MSRP)会在内部向该身份颁发证书。
和
有什么区别
简而言之,托管身份和服务主体之间的区别在于,托管身份代表您管理服务主体的创建和自动续订。
cwtwac6a2#
托管标识是服务主体的一种类型。
服务主体可以是以下三种类型之一:应用程序、托管身份和遗留。对类型的划分基于它们的使用环境。因此,它们的具体处理也基于它们的类型而不同。
rickvdbosch提供了一篇文章的链接,该文章讨论了服务主体的托管身份类型的细节。对于那些想了解服务主体对象及其类型的概念的人,这里是另一篇文章的链接:Application and service principal objects in Azure Active Directory。
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应用程序,存储帐户,功能,逻辑应用程序......所有属于同一应用程序架构。
pzfprimi4#
Azure服务原则就像一个应用程序,其他Azure资源可以使用其令牌来验证和授予对Azure资源的访问权限。
托管身份是特殊类型的服务主体,它们被锁定为仅与Azure资源一起使用。
两者之间的主要区别是,在托管身份中,您不需要在代码中指定任何凭据,而服务原则则需要指定应用程序ID,客户端ID等来生成令牌以访问任何Azure资源。理想情况下,只有当您使用的服务不支持托管身份时,您才应该选择服务主体。
tf7tbtn25#
托管标识与资源(VM、Logib App等)绑定。要给予资源访问(CRUD)其他资源的赠款和权限,请使用托管标识。
Service Principial不必绑定到资源,它们在租户和订阅之上,更重要的是-有一些可以存储在某个地方(密钥库)的授权令牌。这就像一个拥有一些凭证和令牌的假用户。
ivqmmu1c6#
在更传统的本地应用程序或服务方案中,服务主体可以被视为类似于服务帐户。托管身份用于将服务主体安全对象“链接”到Azure资源,如虚拟机、Web应用程序、逻辑应用程序或类似资源
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,后者需要单独搜索。
这只是基于我在Portal上的经验,但似乎系统分配的MSI不属于资源组(或隐藏),即用户分配的在调用时显示清楚,但系统分配的MSI找不到此信息,这是没有意义的。后者与MSI resource紧密相连,所以我去了特定资源的资源组,列出了所有成员,但他们也没有显示在那里。奇怪。
条款
Azure标识的快速概述(其中“标识”指Azure Active Directory标识):
*服务负责人
应用程序或服务用于访问特定Azure资源的安全标识。您可以将其视为应用程序的用户标识(用户名和密码或证书)。
(from Steps to assign an Azure role)
或
本质上,通过使用服务主体,您可以避免在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资源