访问Azure Databricks Workspace API遇403权限错误求助

一、排查认证配置问题 #

• 确认个人访问令牌（PAT）有效性：
  • 必须使用对应工作区的有效PAT，未过期、未被撤销，且创建时勾选了clusters:read（或更高权限）。
  • 检查请求头Authorization格式是否正确，需为Bearer <你的PAT>，注意Bearer后有空格。
• Azure AD令牌验证（若使用该方式）：
  • 确保令牌的租户ID与Databricks工作区所属Azure租户完全匹配，且令牌包含api://2ff814a6-3304-4ab8-85cb-cd0e6f879c1d/.default的API权限范围。

二、检查网络与防火墙规则 #

• 验证客户端IP在工作区允许列表：
  • 登录Databricks工作区，进入管理控制台→网络→IP访问列表，确认发起请求的IP已添加至允许列表。若工作区启用IP限制，未在列表内的IP会直接被拦截返回403。
  • 若为VNet注入工作区，检查VNet的NSG规则、路由表是否允许出站流量访问*.azuredatabricks.net的443端口。
• 排查代理/防火墙流量干扰：
  • 若通过代理访问，确认代理未篡改Authorization请求头，也未添加无效头信息。可在工作区所属VNet内的虚拟机发起测试，排除代理影响。
  • 检查本地或企业级防火墙是否拦截请求，或因SSL解密导致令牌验证失败。

三、验证工作区权限与组织关联 #

• 确认用户/服务主体的工作区访问权限：
  • 生成PAT的用户（或Azure AD服务主体）需为工作区有效成员，且被分配至少用户级角色（非访客角色）。
  • 若使用服务主体，需确保已在Databricks工作区中添加该主体，并授予clusters:read权限（通过工作区权限页面配置）。
• 核对组织ID一致性：
  • 错误信息中的Org: xxxx需与工作区实际组织ID匹配，可在管理控制台→工作区设置中查看组织ID，确认请求未发送至错误的工作区端点。

四、实操测试与日志排查 #

1. 用curl直接发起请求，排除Postman配置问题：

   curl -X GET "https://workspacexxx.azuredatabricks.net/api/2.0/clusters/list" \
        -H "Authorization: Bearer <你的PAT>"
   

2. 若Azure虚拟机内测试成功，说明问题出在本地网络/代理；若虚拟机测试也失败，重点检查工作区IP列表与VNet规则。
3. 查看Databricks工作区审计日志，搜索对应403请求，日志会明确拒绝原因（如IP未授权、权限不足等）。

内容的提问来源于stack exchange，提问作者Đức Thiện Trần