获取服务主体的 Microsoft Entra ID（旧称 Azure Active Directory）令牌
重要
本部分介绍如何手动获取服务主体的 Microsoft Entra ID（以前称为 Azure Active Directory）令牌。
Azure Databricks 托管服务主体直接在 Azure Databricks 中进行管理。 Microsoft Entra ID 托管服务主体在 Microsoft Entra ID 中进行管理，这需要其他权限。 Databricks 建议在大多数用例中使用 Azure Databricks 托管服务主体。 但是，Databricks 建议在必须同时向 Azure Databricks 和其他 Azure 资源进行身份验证的情况下使用 Microsoft Entra ID 托管服务主体。
若要创建 Azure Databricks 托管服务主体，而不是 Microsoft Entra ID 托管服务主体，请参阅管理服务主体。
Databricks 建议不要手动为 Microsoft Entra ID（前 Azure Active Directory）服务主体创建 Microsoft Entra ID 标记。 这是因为每个 Microsoft Entra ID 令牌的生存期很短，通常在一小时内就会过期。 在此时间之后，必须手动生成替换 Microsoft Entra ID 令牌。 请改用实现 Databricks 客户端统一身份验证标准的参与工具或 SDK 之一。 这些工具和 SDK 可以利用以下 Databricks 身份验证类型，自动生成并替换过期的 Microsoft Entra ID 令牌：
如果没有服务主体，可以按照以下说明之一预配一个服务主体：
本文介绍在 Microsoft Entra ID 中定义的服务主体如何还可以充当在 Azure Databricks 中强制执行身份验证和授权策略的主体。 Azure Databricks 工作区中的服务主体可以有不同于常规用户（用户主体）的精细访问控制。
服务主体充当客户端角色，并使用 OAuth 2.0 客户端凭据流来授权访问 Azure Databricks 资源。
可以在 Databricks 中管理服务主体，也可以使用 Azure 门户中的以下过程来管理。
还可以使用 Microsoft 身份验证库 (MSAL) 以编程方式为用户获取 Microsoft Entra ID 访问令牌，而不是服务主体。 请参阅使用 MSAL 为用户获取 Microsoft Entra ID（以前称为 Azure Active Directory）令牌。
在 Azure 门户中预配服务主体
登录 Azure 门户。
注意
要使用的门户根据 Microsoft Entra ID（以前称为 Azure Active Directory）应用程序是在 Azure 公有云中运行还是在国家云或主权云中运行而异。 有关详细信息，请参阅国家云。
如果有权访问多个租户、订阅或目录，请单击顶部菜单中的“目录 + 订阅”（目录包含筛选器）图标，以切换到要预配服务主体的目录。
在“搜索资源、服务和文档”中，搜索并选择“Microsoft Entra ID”。
单击“+ 添加”，然后选择“应用注册”。
对于“名称”，请输入应用程序的名称。
在“支持的帐户类型”部分中，选择“仅组织目录中的帐户(单一租户)”。
单击“注册”。
在应用程序页的“概述”页上的“概要”部分中，复制以下值：
- 应用程序(客户端) ID
- 目录（租户）ID
若要生成客户端密码，请在“管理”中单击“证书和机密”。
注意
使用此客户端密码生成 Microsoft Entra ID 令牌，以使用 Azure Databricks 对 Microsoft Entra ID 服务主体进行身份验证。 要确定 Azure Databricks 工具或 SDK 是否可以使用 Microsoft Entra ID 令牌，请参阅该工具或 SDK 的文档。
在“客户端密码”选项卡上，单击“新建客户端密码” 。
在“添加客户端机密”窗格中的“说明”，输入客户端机密的说明。
对于“过期”，选择客户端机密的过期时间段，然后单击“添加”。
复制客户端密码的“值”并将其存储在安全位置，因为此客户端密码是应用程序的密码。
使用 Azure CLI 预配服务主体
请参阅使用 Azure CLI 创建 Microsoft Entra ID（旧称 Azure Active Directory）服务主体。
使用 Microsoft 标识平台 REST API 获取 Microsoft Entra ID 访问令牌
重要
本部分介绍如何使用 Microsoft 标识平台 REST API 为服务主体手动获取 Microsoft Entra ID 令牌。
Databricks 建议不要手动为 Microsoft Entra ID（以前称为 Azure Active Directory）服务主体创建 Microsoft Entra ID 标记。 这是因为每个 Microsoft Entra ID 令牌的生存期很短，通常在一小时内就会过期。 在此时间之后，必须手动生成替换 Microsoft Entra ID 令牌。 请改用实现 Databricks 客户端统一身份验证标准的参与工具或 SDK 之一。 这些工具和 SDK 可以利用以下 Databricks 身份验证类型，自动生成并替换过期的 Microsoft Entra ID 令牌：
如果要使用服务主体访问 Databricks REST API，需要获取然后使用服务主体的 Microsoft Entra ID 访问令牌。 有关详细信息，请参阅第一种情况：使用共享密钥访问令牌请求。
提示
还可以使用 Azure CLI 获取 Microsoft Entra ID 访问令牌。 请参阅使用 Azure CLI 获取 Microsoft Entra ID 访问令牌。
收集以下信息：
参数 说明 Tenant ID在 Microsoft Entra ID 中注册的相关应用程序的 Directory (tenant) ID。Client ID在 Microsoft Entra ID 中注册的相关应用程序的 Application (client) ID。Client secret在 Microsoft Entra ID 中注册的相关应用程序的客户端密码的 Value。使用上述信息以及 curl 获取 Microsoft Entra ID（前 Azure Active Directory）访问令牌。
curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \ https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token \ -d 'client_id=<client-id>' \ -d 'grant_type=client_credentials' \ -d 'scope=2ff814a6-3304-4ab8-85cb-cd0e6f879c1d%2F.default' \ -d 'client_secret=<client-secret>'将：
<tenant-id>替换为已注册应用程序的租户 ID。<client-id>替换为已注册应用程序的客户端 ID。<client-secret>与已注册应用程序的客户端密码值。
不要更改
scope参数的值。 它表示 Azure Databricks 的编程 ID（2ff814a6-3304-4ab8-85cb-cd0e6f879c1d），以及默认作用域（/.default，URL 编码为%2f.default）。例如：
curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \ https://login.microsoftonline.com/a1bc2d34-5e67-8f89-01ab-c2345d6c78de/oauth2/v2.0/token \ -d 'client_id=12a34b56-789c-0d12-e3fa-b456789c0123' \ -d 'grant_type=client_credentials' \ -d 'scope=2ff814a6-3304-4ab8-85cb-cd0e6f879c1d%2F.default' \ -d 'client_secret=abc1D~Ef...2ghIJKlM3'Microsoft Entra ID 访问令牌位于调用输出中的
access_token值中。
使用 Azure CLI 获取 Microsoft Entra ID 访问令牌
重要
本部分介绍如何使用 Azure CLI 为服务主体手动获取 Microsoft Entra ID 令牌。
Databricks 建议不要手动为 Microsoft Entra ID（以前称为 Azure Active Directory）服务主体创建 Microsoft Entra ID 标记。 这是因为每个 Microsoft Entra ID 令牌的生存期很短，通常在一小时内就会过期。 在此时间之后，必须手动生成替换 Microsoft Entra ID 令牌。 请改用实现 Databricks 客户端统一身份验证标准的参与工具或 SDK 之一。 这些工具和 SDK 可以利用以下 Databricks 身份验证类型，自动生成并替换过期的 Microsoft Entra ID 令牌：
如果要使用服务主体访问 Databricks REST API，需要获取然后使用服务主体的 Microsoft Entra ID 访问令牌。
收集以下信息：
参数 说明 Tenant ID在 Microsoft Entra ID 中注册的相关应用程序的 Directory (tenant) ID。Client ID在 Microsoft Entra ID 中注册的相关应用程序的 Application (client) ID。Client secret在 Microsoft Entra ID 中注册的相关应用程序的客户端密码的 Value。请通过执行以下操作之一获取 Microsoft Entra ID 服务主体的正确 Azure 订阅 ID（如果你尚不知道此 ID）：
在 Azure Databricks 工作区的顶部导航栏中，单击你的用户名，然后单击“Azure 门户”。 在显示的 Azure Databricks 工作区资源页上，单击边栏中的“概述”。 然后查找“订阅 ID”字段，其中包含订阅 ID。
使用 Azure CLI 运行 az databricks workspace list 命令，使用
--query和-o或--output选项缩小结果范围。 将adb-0000000000000000.0.azuredatabricks.net替换为你的工作区实例的名称，不包括https://。 在此示例中，输出中/subscriptions/后的00000000-0000-0000-0000-000000000000是订阅 ID。az databricks workspace list --query "[?workspaceUrl==\`adb-0000000000000000.0.azuredatabricks.net\`].{id:id}" -o tsv # /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-rg/providers/Microsoft.Databricks/workspaces/my-ws如果显示了以下消息，则表示登录到了错误的租户：
The subscription of '<subscription-id>' doesn't exist in cloud 'AzureCloud'.若要登录到正确的租户，必须再次运行az login命令，使用-t或--tenant选项指定正确的租户 ID。可以通过运行命令
curl -v <per-workspace-URL>/aad/auth并查看输出< location: https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000来获取 Azure Databricks 工作区的租户 ID，其中的00000000-0000-0000-0000-000000000000是租户 ID。 另请参阅在 Azure 门户中获取订阅和租户 ID。az login -t <tenant-id>
获得 Microsoft Entra ID 服务主体的正确 Azure 租户 ID、客户端 ID、客户端密码和订阅 ID 后，请使用 Azure CLI 运行 az login 命令来登录到 Azure。 使用
--service-principal选项，同时为在 Microsoft Entra ID（旧称 Azure Active Directory）中注册的相关应用程序指定Tenant ID(Directory (tenant) ID)、Client ID(Application (client) ID) 和Client secret(Value) 参数的值。az login \ --service-principal \ -t <Tenant-ID> \ -u <Client-ID> \ -p <Client-secret>确认你已登录到已登录 Microsoft Entra ID 服务主体的正确订阅。 为此，请运行 az account set 命令，使用
-s或--subscription选项来指定正确的订阅 ID。az account set -s <subscription-id>通过运行 az account get-access-token 命令为已登录的 Microsoft Entra ID 服务主体生成 Microsoft Entra ID 访问令牌。 使用
--resource选项指定 Azure Databricks 服务的唯一资源 ID，即2ff814a6-3304-4ab8-85cb-cd0e6f879c1d。 可以使用--query和-o或--output选项在命令的输出中仅显示 Microsoft Entra ID（前 Azure Active Directory）令牌的值。az account get-access-token \ --resource 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d \ --query "accessToken" \ -o tsv
使用服务主体的 Microsoft Entra ID 访问令牌来访问 Databricks REST API
重要
本部分介绍如何使用 curl 和服务主体的 Microsoft Entra ID 访问令牌来访问 Databricks REST API。
你可以使用实现了 Databricks 客户端统一身份验证标准的参与工具或 SDK 之一（而非使用 curl）。 这些工具和 SDK 还可以利用以下 Databricks 身份验证类型，自动生成并替换过期的 Microsoft Entra ID 令牌：
作为 Databricks 用户的服务主体，可以使用 Microsoft Entra ID 令牌向 Databricks REST API 进行身份验证。
如果服务主体对 Azure 中的目标工作区资源具有参与者或所有者角色，则该服务主体还可以将自己添加为工作区的工作区管理员。 如果服务主体是目标工作区的参与者或所有者，而你想要使用其 Microsoft Entra ID 令牌将其添加到工作区，请转到非 Azure Databricks 用户的服务主体的工作区级别 API 访问权限。
否则，请转到作为 Azure Databricks 用户和管理员的服务主体的 API 访问权限。
作为 Azure Databricks 用户和管理员的服务主体的 API 访问权限
若要完成此过程，必须首先将该服务主体添加到 Azure Databricks 帐户或工作区。 可以使用 SCIM（帐户）API 将服务主体直接添加到帐户，而无需授予其工作区访问权限。
可以使用服务主体 API 终结点将服务主体添加到工作区。 这还会将服务主体添加到 Azure Databricks 帐户。 例如：
使用 Databricks CLI 版本 0.205 或更高版本（建议）：
添加服务主体：
databricks service-principals create --application-id 12a34b56-789c-0d12-e3fa-b456789c0123 --display-name "My Service Principal" -p <profile-name-that-references-calling-users-access-token>
更新服务主体的工作区权利：
databricks service-principals patch 1234567890123456 --json @update-service-principal.json -p <profile-name-that-references-access-token>
update-service-principal.json：
{
"Operations": [
{
"op": "add",
"path": "entitlements",
"value": {
"value": "workspace-acccess",
"value": "allow-cluster-create",
"value": "databricks-sql-access"
}
}
],
"schema": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
]
}
请参阅 Databricks CLI 身份验证。
通过使用 curl：
curl -X POST \
-H 'Authorization: Bearer <access-token>' \
https://adb-1234567890123456.7.azuredatabricks.net/api/2.0/preview/scim/v2/ServicePrincipals \
-H 'Content-type: application/scim+json' \
-d @create-service-principal.json
create-service-principal.json：
{
"displayName": "My Service Principal",
"applicationId": "12a34b56-789c-0d12-e3fa-b456789c0123",
"entitlements": [
{
"value": "allow-cluster-create"
}
],
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:ServicePrincipal"
],
"active": true
}
如果存在以下任一情况，请转到非 Azure Databricks 用户的服务主体的工作区级别 API 访问权限：
- 要调用的 Azure Databricks REST API 需要工作区管理员访问权限，并且服务主体是工作区的成员，但该 API 当前对工作区没有管理员访问权限。
- 尚未将服务主体添加到目标 Azure Databricks 工作区。
收集以下信息。
参数 说明 Microsoft Entra ID 访问令牌 使用 Microsoft 标识平台 REST API 获取 Microsoft Entra ID 访问令牌或使用 Azure CLI 获取 Microsoft Entra ID 访问令牌中的请求返回的 Microsoft Entra ID 访问令牌。 使用 Microsoft Entra ID 访问令牌与
curl，调用 Databricks REST API。 例如：使用 Databricks CLI 版本 0.205 或更高版本（建议）：
databricks clusters list -p <profile-name-that-references-azure-ad-access-token>请参阅 Databricks CLI 身份验证。
通过使用
curl：curl -X GET \ -H 'Authorization: Bearer <access-token>' \ https://<databricks-instance>/api/2.0/clusters/list将：
<access-token>与 Microsoft Entra ID 访问令牌。<databricks-instance>与 Azure Databricks 部署的每个工作区 URL。GET和/api/2.0/clusters/list（具有目标 Databricks REST API 的相应 HTTP 操作和终结点）。
例如：
curl -X GET \ -H 'Authorization: Bearer <access-token>' \ https://adb-1234567890123456.7.azuredatabricks.net/api/2.0/clusters/list
非 Azure Databricks 用户的服务主体的工作区级别 API 访问权限
如果存在以下任一情况，请遵循此过程：
- 要调用的 Azure Databricks REST API 需要工作区管理员访问权限，并且服务主体是工作区的成员，但该 API 当前对工作区没有管理员访问权限。
- 尚未将服务主体添加到目标 Azure Databricks 工作区。
要求：
- 服务主体需要对 Azure 中的目标工作区资源具有参与者或所有者角色。
收集以下信息：
参数 说明 租户 ID 在 Azure 门户预配服务主体中 Microsoft Entra ID 中注册的相关应用程序的“目录(租户) ID”。 客户端 ID 在 Microsoft Entra ID 中注册的相关应用程序的“应用程序(客户端) ID”。 客户端机密 在在 Azure 门户预配服务主体中创建的 Microsoft Entra ID 中注册的相关应用程序的客户端密码的“值”。 Microsoft Entra ID 访问令牌 使用 Microsoft 标识平台 REST API 获取 Microsoft Entra ID 访问令牌或使用 Azure CLI 获取 Microsoft Entra ID 访问令牌中的请求返回的 Microsoft Entra ID 访问令牌。 订阅 ID 与目标 Azure Databricks 工作区关联的 Azure 订阅的 ID（而不是名称）。 若要获取此信息和以下信息，请参阅开放资源。 若要打开目标资源，可以在 Azure 中搜索 Azure Databricks 服务类型以及 Azure 中有关目标 Azure Databricks 工作区的任何其他信息。 资源组名称 与目标 Azure Databricks 工作区关联的 Azure 资源组的名称。 工作区名称 目标 Azure Databricks 工作区在 Azure 中的名称。 使用上述某些信息与
curl，获取 Microsoft Entra ID 管理终结点访问令牌。curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \ https://login.microsoftonline.com/<tenant-id>/oauth2/token \ -d 'client_id=<client-id>' \ -d 'grant_type=client_credentials' \ -d 'resource=https%3A%2F%2Fmanagement.core.windows.net%2F' \ -d 'client_secret=<client-secret>'将：
<tenant-id>替换为已注册应用程序的租户 ID。<client-id>替换为已注册应用程序的客户端 ID。<client-secret>与已注册应用程序的客户端密码值。
不要更改
resource参数的值。 它表示 Microsoft Entra ID 管理终结点（https://management.core.windows.net/，URL 编码为https%3A%2F%2Fmanagement.core.windows.net%2F）。例如：
curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \ https://login.microsoftonline.com/a1bc2d34-5e67-8f89-01ab-c2345d6c78de/oauth2/token \ -d 'client_id=12a34b56-789c-0d12-e3fa-b456789c0123' \ -d 'grant_type=client_credentials' \ -d 'resource=https%3A%2F%2Fmanagement.core.windows.net%2F' \ -d 'client_secret=abc1D~Ef...2ghIJKlM3'Microsoft Entra ID 管理终结点访问令牌位于调用输出中的
access_token值中。使用 Microsoft Entra ID 管理终结点访问令牌、上述其余信息与
curl，调用 Databricks REST API，例如：curl -X GET \ -H 'Authorization: Bearer <access-token>' \ -H 'X-Databricks-Azure-SP-Management-Token: <management-access-token>' \ -H 'X-Databricks-Azure-Workspace-Resource-Id: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Databricks/workspaces/<workspace-name>' \ https://<databricks-instance>/api/2.0/clusters/list将：
<access-token>与 Microsoft Entra ID 访问令牌。<management-access-token>与 Microsoft Entra ID 管理终结点访问令牌。<subscription-id>与目标 Azure Databricks 工作区关联的订阅 ID。<resource-group-name>与目标 Azure Databricks 工作区关联的资源组的名称。<workspace-name>与目标 Azure Databricks 工作区的名称。<databricks-instance>与 Azure Databricks 部署的每个工作区 URL。GET和/api/2.0/clusters/list（具有目标 Databricks REST API 的相应 HTTP 操作和终结点）。
例如：
curl -X GET \ -H 'Authorization:Bearer <access-token>' \ -H 'X-Databricks-Azure-SP-Management-Token: abC1dE...ghIj23kl' \ -H 'X-Databricks-Azure-Workspace-Resource-Id: /subscriptions/12a345...bcd6789e/resourceGroups/my-resource-group/providers/Microsoft.Databricks/workspaces/my-workspace' \ https://adb-1234567890123456.7.azuredatabricks.net/api/2.0/clusters/list
对工作区进行身份验证后，服务主体将成为 Azure Databricks 工作区管理员，不再需要参与者或所有者角色即可访问该工作区。
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈