一，引言

　　又到了新的一周了，也到了我新的分享的时间了，还记得上一周立得Flag，其中 “保证每周输出一篇文章” ，让我特别“在意”（这里用词不太恰当）。主要是我的一个大学舍友，他突然问了我一个关于写博的事情，自己也在上周开通了账号，也想着坚持写博客。在我看来，这确实是一件好事，写博不仅仅是分享的过程；也是自己提炼写博的一个过程，以及文章组织的能力，对自己还是很有好处的。这不仅仅要写内容要精炼，同时也要让别人能看的懂。加油，默默的在这里给他打气。(ง •_•)ง

好了，开始今天的分析????????????????????

------------------------------------我是分割线------------------------------------

　　上一周有介绍到Azure AD资源托管标识的内容，其实就包括如何去操作开启系统分配的托管标识，以及通过开启托管标识，VM如何去访问Azure 中的一些资源，如 “Key Vault” 等。今天去分析一波关于“Service Principal”（服务主体）。

二，正文

1，服务主体对象

　　若要访问受 Azure AD 租户保护的资源，需要访问的实体必须由安全主体来表示。 这同时适用于用户（用户主体）和应用程序（服务主体）。安全主体定义 Azure AD 租户中用户/应用程序的访问策略和权限。 这样便可实现核心功能，如在登录时对用户/应用程序进行身份验证，在访问资源时进行授权。当应用程序被授予了对租户中资源的访问权限时（根据注册或许可），将创建一个服务主体对象。 Microsoft Graph ServicePrincipal 实体定义服务主体对象属性的架构。

2，应用程序和服务主体的关系

可以将应用程序对象视为应用程序的全局表示形式（供所有租户使用），将服务主体视为本地表示形式（在特定租户中使用）。

应用程序对象用作模板，常见属性和默认属性从其中派生，以便在创建相应服务主体对象时使用。 因此，应用程序对象与软件应用程序存在 1 对 1 关系，而与其对应的服务主体对象存在 1 对多关系。

必须在将使用应用程序的每个租户中创建服务主体，让它能够建立用于登录和/或访问受租户保护的资源的标识。 单租户应用程序只有一个服务主体（在其宿主租户中），在应用程序注册期间创建并被允许使用。 多租户 Web 应用程序/API 还会在租户中的某个用户已同意使用它的每个租户中创建服务主体。

下图演示了应用程序的应用程序对象和对应的服务主体对象之间的关系，其上下文是在名为 HR 应用的示例多租户应用程序中。 此示例方案中有三个 Azure AD 租户：

• Adatum -开发HR 应用的公司使用的租户

• Contoso -contoso 组织使用的租户，即HR 应用的使用者

• Fabrikam -fabrikam 组织使用的租户，它也使用HR 应用

在此示例方案中：

表 1

步骤	说明
1	是在应用程序的宿主租户中创建应用程序对象和服务主体对象的过程。
2	当 Contoso 和 Fabrikam 的管理员完成同意并向应用程序授予访问权限时，会在其公司的 Azure AD 租户中创建服务主体对象，并向其分配管理员所授予的权限。 另请注意，HR 应用可能配置/设计为允许由用户同意以供个人使用。
3	HR 应用程序的使用者租户（例如 Contoso 和 Fabrikam）各有自己的服务主体对象。 每个对象代表其在运行时使用的应用程序实例，该实例受相关管理员同意的权限控制。

3，使用Azure CLI创建Azure服务主体（示例）

使用 az ad sp create-for-rbac 命令创建服务主体。创建服务主体时，请选择其使用的登录身份验证的类型。

 注意

如果您的帐户无权创建服务主体，将返回一条错误消息，其中包含“权限不足，无法完成操作”。请与您的Azure Active Directory管理员联系以创建服务主体。

3.1，在 “azure portal” 中验证当前的Azure订阅

1	az account show

3.2，显示订阅名称ID值的列表

1	az account list --query "[].{name:name, subscriptionId:id}"

 

3.3，使用 az ad sp create-for-rbac 命令，将其替换<subscription_id>为要使用的订阅帐户的ID

1	az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/<subscription_id>"

注意：我们将创建一个具有 “Contributor” （贡献者角色：默认角色）的服务主体。该 “Contributor” 角色具有完全的权限读取和写入到Azure的账户，

成功完成后，该命令将显示几个值，包括自动生成的密码　　

 

同时，我们可以在 “azure portal” 中可以找到对应的设置 选择=》Azure Active Directory

 

点击 “App registrations”

 

 同时，我们可以在当前订阅下的 “IAM”中找到对应的角色访问权限信息。当然了，上面我创建服务主体的时候给的 scope 是整个订阅，也就是我们可以通过这个服务主体去访问azure的任何资源。

例如 "azure devops Pipeline" 在CD的过程，需要配置 "Service Principal"

 

 例如使用Terraform 构建基础架构资源的时候，需要配置 Service Principal

三，总结

　　使用Azure服务的自动化工具应始终具有受限权限。Azure提供服务主体，而不是让应用程序以完全特权用户身份登录。Azure服务主体是为与应用程序，托管服务和自动化工具一起使用而创建的身份，以访问Azure资源。这种访问受到分配给服务主体的角色的限制，使您可以控制可以访问哪些资源以及可以访问哪个级别。出于安全原因，始终建议将服务主体与自动化工具一起使用，而不是允许他们使用用户身份登录。

服务主体的默认角色是Contributor。该角色具有读取和写入Azure帐户的完整权限

参考资料：RBAC内置角色：https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles

作者：Allen

版权：转载请在文章明显位置注明作者及出处。如发现错误，欢迎批评指正。