创建服务主体和密钥
现在你已了解服务主体的概念，你可能想知道它是如何向 Microsoft Entra ID 证明自己的标识。 在本单元中，你将了解服务主体的身份验证过程和凭据。 你还将学习如何创建服务主体并为其提供密钥。
了解如何对服务主体进行身份验证
当服务主体需要与 Azure 通信时，它会登录 Microsoft Entra ID。 在 Microsoft Entra ID 验证服务主体的标识后，它会颁发令牌。客户端应用程序会存储该令牌，并在向 Azure 发出任何请求时使用它。
一般说来，此过程类似于你自己以用户身份登录 Azure 时操作情况。 但是与用户相比，服务主体有一种略微不同的凭证类型来证明其标识。 服务主体使用两种主要凭据：密钥和证书。
备注
请记住，托管标识是在 Azure 中工作的特殊服务主体。 它们具有不同类型的身份验证过程，完全无需你了解或处理凭据。
键
密钥类似于密码。 但是，密钥要长得多且更复杂。 事实上在大多数情况下，Microsoft Entra ID 本身会生成密钥来确保：
- 密钥在密码上是随机的。 也就是说，很难猜出它们。
- 用户不会意外地使用弱密码作为密钥。
服务主体通常具有高特权的权限，因此确保它们的安全至关重要。 通常，你只需要在首次配置服务主体和管道时简要处理密钥。 因此，密钥无需易记或易于键入。
单个服务主体可同时拥有多个密钥，但用户无法拥有多个密码。 与密码一样，密钥也有到期日期。 你很快就会了解到详细信息。
备注
将密钥看作非常重要的密码，类似于存储帐户密钥。 你在对待它们时应执行同样级别的安全性且同样谨慎操作。
证书
证书是对服务主体进行身份验证的另一种方法。 它们非常安全，但很难管理。 某些组织要求对某些类型的服务主体使用证书。
我们不会在此模块中讨论证书。 但是，如果采用使用证书身份验证的服务主体，那么在管理它和向其授予管道权限时，其工作方式与任何其他服务主体大致相同。
备注
当可使用证书时，证书是一个不错的选择。 攻击者更难窃取它们。 而且，更难截获和修改使用证书的请求。 不过，证书需要更多的基础结构，并且具有一些持续的维护开销。
对服务主体使用密钥
创建服务主体时，通常会要求 Azure 同时创建一个密钥。 Azure 通常会为你生成一个随机密钥。
注意
还记得我们之前对服务主体工作原理的讨论吗？ 密钥存储为应用程序注册对象的一部分。 如果打开 Azure 门户，查看 Microsoft Entra 配置，然后转到应用程序注册，也可在那里创建和删除密钥。
创建服务主体时，Azure 会显示密钥。 这是 Azure 唯一一次向你显示密钥。 之后，再也无法检索它。 有必要安全地复制密钥，以便可在配置管道时使用它。 请勿通过电子邮件或其他非安全方式共享密钥。 如果丢失了密钥，则必须将其删除，再新建一个。
管理用于 Azure Pipelines 的服务主体
为管道的服务主体创建密钥时，最好是立即将密钥复制到管道的配置中。 这样可避免不必要地存储或传输密钥。
管道工具包括指定服务主体的应用程序 ID 和密钥的安全方法。 切勿在源代码管理中存储任何类型的凭据。 改为在使用 Azure Pipelines 时使用服务连接。 在本模块中，我们仅讨论如何创建服务主体和密钥。 你将在后面的模块中了解如何使用密钥配置管道。
提示
Azure Pipelines 可自动创建服务主体。 在此模块中，你将手动创建和管理服务主体，以便更好地理解发生的情况。 在其他模块中，为了简单起见，你将使用自动创建方法。
创建服务主体和密钥
可使用 Azure CLI 创建和管理服务主体。
注意
创建和修改服务主体要求你在 Microsoft Entra ID 中具有相关权限。 在某些组织中，可能需要管理员为你执行这些步骤。
若要创建服务主体和密钥，请使用 az ad sp create-for-rbac 命令。 此命令接受多个参数，并可选择性地为服务主体分配角色。 你稍后将在本模块中了解此主题。 现在，以下示例演示如何创建没有任何 Azure 角色分配的服务主体：
az ad sp create-for-rbac --name MyPipeline
运行此命令时，Azure CLI 返回具有 password 属性的 JSON 响应。 此属性是服务主体的密钥。 你无法再次获取此密钥，因此要确保立即使用它或将其安全地保存到某处。
注意
az ad sp create-for-rbac 命令在 Microsoft Entra ID 创建应用程序注册，将服务主体添加到 Microsoft Entra 租户，并为应用程序注册创建密钥。 另一个命令 az ad sp create 仅在租户（而不是应用程序注册）中创建服务主体。 为管道创建服务主体时，通常最好使用 az ad sp create-for-rbac 命令。
可以使用 Azure PowerShell cmdlet 来创建和管理服务主体。
注意
创建和修改服务主体要求你在 Microsoft Entra ID 中具有相关权限。 在某些组织中，可能需要管理员为你执行这些步骤。
若要创建服务主体和密钥，请使用 New-AzADServicePrincipal cmdlet。 此 cmdlet 接受多个参数，并可选择性地为服务主体分配角色。 你稍后将在本模块中了解此主题。 现在，以下示例演示如何创建没有任何 Azure 角色分配的服务主体：
$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline
运行此命令时，Azure PowerShell 将使用服务主体的信息（包括密钥）填充 servicePrincipal 变量：
$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText
你无法再次获取此密钥，因此要确保立即使用它或将其安全地保存到某处。
注意
New-AzADServicePrincipal cmdlet 会在 Microsoft Entra ID 创建应用程序注册，将服务主体添加到 Microsoft Entra 租户，并为应用程序注册创建密钥。
标识服务主体
服务主体具有多个标识符和名称，用于标识和使用它们。 最常用的标识符是：
- 应用程序 ID：应用程序注册具有唯一标识符，通常称为“应用程序 ID”，有时也称为“客户端 ID”。 服务主体登录到 Azure 时，通常使用它作为用户名。
- 对象 ID：应用程序注册和服务主体都有自己单独的对象 ID，它们是由 Microsoft Entra ID 分配的唯一标识符。 在管理服务主体时，偶尔需要使用这些对象 ID。
- 显示名称：这是描述服务主体的用户可读名称。
提示
请为服务主体使用明确的描述性显示名称。 有必要帮助团队了解服务主体的用途，以便不会有人意外删除它或更改其权限。
注意
显示名称不是唯一的。 多个服务主体可能共享同一显示名称。 在使用服务主体的显示名称来标识它，从而对其授予权限时，请小心操作。 你可能会意外地向错误的服务主体授予权限。 好的做法是改用应用程序 ID。
创建服务主体时，通常只设置显示名称。 Azure 会自动分配其他名称和标识符。
处理已过期的密钥
服务主体不会过期，但其密钥会过期。 创建密钥时，可配置其过期时间。 默认情况下，过期时间设置为一年。 在此过期时间之后，密钥不再有效，并且管道无法登录到 Microsoft Entra ID。 你需要定期续订或轮换密钥。
注意
为密钥设置较长的过期时间可能很有吸引力，但不应这样做。 服务主体仅受其凭据的保护。 如果攻击者获取了服务主体的密钥，就会造成很大的破坏。 要最大限度减少攻击时长，最佳方法是定期更换密钥。 如果怀疑密钥已泄露，还应删除并重新创建密钥。
若要重置服务主体的密钥，请对应用程序 ID 使用 az ad sp 命令，如下例所示：
az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"
还可先后使用 az ad sp credential delete 和 az ad sp credential reset --append 命令，在两个单独的步骤中删除并重新创建服务主体的密钥。
若要重置服务主体的密钥，请首先使用 Remove-AzADServicePrincipalCredential cmdlet 删除现有凭据。 然后使用 New-AzADServicePrincipalCredential cmdlet 添加新凭据。 这些 cmdlet 都使用服务主体的对象 ID 来标识它。 在使用 cmdlet 之前，需要从应用程序 ID 获取此 ID：
$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id
Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText
提示
单个服务主体可以有多个密钥。 你可安全地更新应用程序，在旧密钥仍然有效时使用新密钥，然后在不再使用旧密钥时删除它。 此方法避免了密钥过期导致的停机。
管理服务主体的生命周期
有必要考虑所创建的每个服务主体的整个生命周期。 为管道生成服务主体时，如果管道最终被删除或不再使用，将会发生什么情况？
服务主体不会自动删除，因此需要审核和删除旧的服务主体。 删除旧的服务主体很重要，原因与删除旧的用户帐户相同：攻击者可能会获得其密钥的访问权限。 最好不要使用不常用的凭据。
最佳做法是将服务主体记录在你和团队可轻松访问的位置。 每个服务主体应包含以下信息：
- 基本标识信息（包括其名称和应用程序 ID）。
- 服务主体的用途。
- 它是谁创建的、谁负责管理它、它的密钥，以及如果有问题，谁可能提供解答。
- 它需要的权限，以及为何需要这些权限的明确理由。
- 它的预期生存期是什么。
应定期审核服务主体，确保它们仍然在使用，并且为它们分配的权限仍然是正确的。