跨租户跨订阅场景下Azure SQL专用端点经资源所有者批准后仍处于挂起状态，提示“Network resource provider denied access”

我最近碰到了一个非常棘手的Azure跨租户跨订阅专用端点问题，想在这里跟大家聊聊情况，看看有没有人遇到过类似的问题。

背景：之前成功的跨租户跨订阅场景 #

我们之前已经成功实现过跨订阅、跨租户的Azure SQL专用端点访问：

• 专用端点创建在订阅Subscription-A，Azure SQL Server实例属于另一个租户的Subscription-SQL
• 创建专用端点时，我们直接指定了SQL Server的资源ID，格式如下：

  /subscriptions/<Subscription-SQL-Guid>/resourceGroups/<AzureSQL-resource-group-name>/providers/Microsoft.Sql/servers/<AzureSQL-server-name>
  

• 之后Subscription-SQL的所有者在Azure门户的Security > Private endpoint connections中批准该请求
• 请求方（Subscription-A）会看到专用端点连接状态变为Approved，之后就能正常访问SQL Server了

当前问题：新订阅重复操作后状态异常 #

但是当我们用另一个订阅Subscription-B执行完全相同的流程时，出现了异常：

1. Subscription-SQL的所有者批准专用端点请求时，操作显示成功
2. 但Subscription-B这边看到专用端点的连接状态一直卡在Pending
3. 等待4-5分钟后，实际状态会变成Failed，但没有明确的错误提示

故障排查步骤 #

为了定位问题，我们尝试了以下操作：

用Azure CLI手动批准连接 #

我们执行了CLI命令来批准连接：

az network private-endpoint-connection approve --resource-group "<AzureSQL-resource-group-name>" --name "<Subscription-B-private-endpoint-name>-<some-guid>" --type Microsoft.Sql/servers --description "Approved" --resource-name "<AzureSQL-server-name>" --debug

命令运行了4-5分钟后返回失败，响应内容显示"provisioningState": "Failed"，同时提示用az network private-endpoint-connection show查看状态：

{
"properties": {
"privateEndpoint": {
"id": "/subscriptions/<Subscription-B-Guid>/resourceGroups/<Subscription-B-resource-group-name>/providers/Microsoft.Network/privateEndpoints/<Subscription-B-private-endpoint-name>"
},
"groupIds": [
"sqlServer"
],
"privateLinkServiceConnectionState": {
"status": "Approved",
"description": "Approved",
"actionsRequired": "None"
},
"provisioningState": "Failed"
},
"id": "/subscriptions/<Subscription-SQL-Guid>/resourceGroups/<AzureSQL-resource-group-name>/providers/Microsoft.Sql/servers/<AzureSQL-server-name>/privateEndpointConnections/<Subscription-B-private-endpoint-name>-<some-guid>",
"name": "<Subscription-B-private-endpoint-name>-<some-guid>",
"type": "Microsoft.Sql/servers/privateEndpointConnections"
}

查看连接状态详情 #

接着我们运行show命令查看详细状态：

az network private-endpoint-connection show --resource-group "<AzureSQL-resource-group-name>" --name "<Subscription-B-private-endpoint-name>-<some-guid>" --type Microsoft.Sql/servers --resource-name "<AzureSQL-server-name>" --debug

结果同样显示provisioningState: Failed，依然没有给出具体的失败原因：

{
"id": "/subscriptions/<Subscription-SQL-Guid>/resourceGroups/<AzureSQL-resource-group-name>/providers/Microsoft.Sql/servers/<AzureSQL-resource-group-name>/privateEndpointConnections/<Subscription-B-private-endpoint-name>-<some-guid>",
"name": "<Subscription-B-private-endpoint-name>-<some-guid>",
"properties": {
"groupIds": [
"sqlServer"
],
"privateEndpoint": {
"id": "/subscriptions/<Subscription-B-Guid>/resourceGroups/<Subscription-B-resource-group-name>/providers/Microsoft.Network/privateEndpoints/<Subscription-B-private-endpoint-name>",
"resourceGroup": "<Subscription-B-resource-group-name>"
},
"privateLinkServiceConnectionState": {
"actionsRequired": "None",
"description": "Approved",
"status": "Approved"
},
"provisioningState": "Failed"
},
"resourceGroup": "<AzureSQL-resource-group-name>",
"type": "Microsoft.Sql/servers/privateEndpointConnections"
}

查看Azure门户事件日志 #

后来我们发现，在批准操作完成4-5分钟后，Azure门户的事件日志中会出现一条错误记录，但没有详细说明。

微软支持的处理情况 #

我们已经向微软支持提交了工单，至今已经一个半月了，但问题依然没有解决：

• 我们多次复现问题并提交日志，但支持团队一直给出不合理的建议，说问题出在SQL所有者缺少专用端点的权限
• 这显然站不住脚：跨租户跨订阅场景下，SQL所有者根本不需要拥有Subscription-B中专用端点的权限，而且专用端点本身就是通过资源ID创建的，完全不需要对方订阅的权限
• 最后微软支持给出了一个非常模糊的错误信息：Network resource provider denied access: '%ls'，这个错误在谷歌上只有3条搜索结果，完全找不到有效的解释

备注：内容来源于stack exchange，提问作者Thibault D.