创建服务主体和密钥
了解服务主体的概念后，你可能想知道它如何向 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，这些 ID 是由 Microsoft Entra ID 分配的唯一标识符。 有时，在管理服务主体时，需要使用这些对象 ID。
- 显示名称：这是描述服务主体的用户可读名称。
小窍门
请为服务主体使用明确的描述性显示名称。 请务必帮助团队了解服务主体的用途，以便没有人意外删除它或更改其权限。
谨慎
显示名称不唯一。 多个服务主体可能共享相同的显示名称。 在通过显示名称来确认服务主体身份时，授予权限需谨慎。 可能会意外地向错误的服务主体授予权限。 最好改用应用程序 ID。
创建服务主体时，通常只设置显示名称。 Azure 自动分配其他名称和标识符。
处理过期密钥
服务主体不会过期，但它们的密钥会过期。 创建密钥时，可以配置其过期时间。 默认情况下，到期时间设置为一年。 在此过期时间之后，密钥不再有效，管道无法登录到 Microsoft Entra ID。 需要定期续订或 轮换 密钥。
谨慎
为密钥设置较长的过期时间可能很有吸引力，但不应这样做。 服务主体仅受其凭据保护。 如果攻击者获取服务主体的密钥，他们可能会造成很大的损害。 最大程度地减少攻击可能持续的时间的最佳方法是定期更改密钥。 如果怀疑密钥泄露，还应删除并重新创建密钥。
若要重置服务主体的密钥，请使用 az ad sp 具有应用程序 ID 的命令，如以下示例所示：
az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"
还可以通过使用az ad sp credential deleteaz 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。
- 服务主体的用途。
- 谁创建了它，谁负责管理它及其密钥，以及谁可能有答案，如果有问题。
- 它需要的权限，以及它为何需要权限的明确理由。
- 它的预期寿命是多少。
应定期审核服务主体，以确保它们仍在使用中，并且分配的权限仍然正确。