什么是 Azure 服务主体？答案

【问题标题】：What is Azure Service Principal?什么是 Azure 服务主体？
【发布时间】：2018-06-14 05:55:52
【问题描述】：

我的要求很简单。我想通过我的 shell 脚本以非交互模式登录 Azure，但是“az login -u username -p password”命令给出了以下错误：

Get Token request returned http error: 400 and server response: {"error":"invalid_grant","error_description":"AADSTS70002: Error validating credentials. : SAML token is invalid. : The element with ID 'xxxxxx' was either unsigned or the signature was invalid.

一些网站告诉我创建一个服务主体。现在我的问题是，什么是服务主体，如何创建服务主体，以便我可以从我的 shell 脚本执行我的命令（用于创建不同的资源，如应用程序网关）？

【问题讨论】：

标签： azure azure-cli

【解决方案1】：

请参考这个official document。

Azure 服务主体是用户创建的安全标识用于访问特定 Azure 的应用、服务和自动化工具资源。将其视为“用户身份”（登录名和密码或证书）具有特定角色和严格控制的权限访问您的资源。它只需要能够做具体的事物，不像一般的用户身份。如果您使用它可以提高安全性只授予它执行其所需的最低权限级别管理任务。

如果要使用 Azure CLi 2.0 创建新的服务主体 (sp)。您可以使用您的 Azure AD 用户登录。然后执行以下命令。

az ad sp create-for-rbac --name {appId} --password "{strong password}"

结果如下：

{
  "appId": "a487e0c1-82af-47d9-9a0b-af184eb87646d",
  "displayName": "MyDemoWebApp",
  "name": "http://MyDemoWebApp",
  "password": {strong password},
  "tenant": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}

appId 是您的登录用户，password 是登录密码。

sp创建完成后，你还需要给它Contributor角色，然后你就可以管理你的Azure资源了。

az role assignment create --assignee <objectID> --role Contributor

现在，您可以使用以下命令以非交互模式登录。

az login --service-principal -u <appid> --password {password-or-path-to-cert} --tenant {tenant}

【讨论】：

这里的appid是什么，我的问题是我需要根据shell资源中的certin计算部署几个资源，可以是公共IP或应用程序网关等。
如果你想将资源部署到Azure，你需要创建一个sp并赋予它owner角色，当然你可以赋予自定义角色，只能创建公共IP和网关。
当您使用 cli 2.0 登录 Azure 时。 appid 是用户名。它也称为客户端 ID。称为客户端密码的密码。
Appid 是新用户或我现有的登录ID
让我们continue this discussion in chat。

【解决方案2】：

服务主体仅充当 Azure AD 中的用户模拟。参考-https://sanganakauthority.blogspot.com/2019/04/how-to-create-service-principal-or-app.html

使用它，您可以使用 REST API 对 Azure 执行任何类型的管理任务。这样，您就无需在弹出窗口中提供凭据，从而有助于使用 REST API 在 Azure 中实现自动化。

【讨论】：

【解决方案3】：

你去吧：Use portal to create an Azure Active Directory application and service principal that can access resources。

当您的应用程序需要访问或修改资源时，您必须设置 Azure Active Directory (AD) 应用程序并为其分配所需的权限。这种方法比在您自己的凭据下运行应用程序更可取，因为：

您可以为应用程序标识分配不同于您自己权限的权限。通常，这些权限仅限于应用程序需要执行的操作。

如果您的职责发生变化，您无需更改应用的凭据。

您可以在执行无人参与的脚本时使用证书自动进行身份验证。

【讨论】：