时间戳

首页 > 解决方案 > 为什么 `az webapp up` 需要对订阅中的所有应用服务的读取权限？

azure - 为什么 `az webapp up` 需要对订阅中的所有应用服务的读取权限？

问题描述

我们有一系列应用服务，每个服务都部署到特定于用户的各个资源组。每个用户没有广泛的权限，但是是该单个资源组的完整贡献者，并且可以通过门户查看和修改这些资源。但是，当我们用户更新应用程序并尝试使用 部署它时az webapp up，我们会看到错误消息：

Webapp '<name>' already exists. The command will deploy contents to the 
existing app.
(BadGateway) Response from service 'Microsoft.Web' does not contain sufficient information to enforce access control policy.

运行命令--debug显示返回带有该消息的 502 的端点是： GET /subscriptions/<subscription_id>/providers/Microsoft.Web/sites?api-version=2020-09-01

我尝试使用 、 和 & 参数的各种组合运行该命令，--name希望--ids指定--plan所有--resource-group详细信息将允许 Azure 跳过检查存在哪些其他服务，但没有运气。

正如错误所暗示的那样，为每个用户提供Microsoft.Web/sites/read订阅权限可以解决问题，但这也意味着所有这些用户都可以在其职权范围之外看到所有其他应用服务的名称，例如通过访问“所有资源”页面。在贡献者角色之上显式应用权限，但仅限于资源组并没有帮助。

所以问题：

  1. 为什么 Azure 需要读取订阅的所有应用服务才能部署现有的命名服务？
  2. 有没有办法绕过它，并允许这些用户在不了解az webapp up其他用户的应用服务的情况下进行部署？

标签： azurepermissionsazure-web-app-serviceazure-cli

解决方案

(BadGateway) Response from service 'Microsoft.Web' does not contain sufficient information to enforce access control policy.

从上述错误消息中， Microsoft.Web资源表示“应用服务”或“功能应用”。

因此，请通过门户检查您的应用服务是否可用。

该az webapp up命令需要从您要部署的代码所在的文件夹中运行。

az webapp up命令不需要对订阅中的所有应用程序服务的读取权限，并且贡献者角色足以管理资源。

推荐阅读