【问题标题】:Bicep configure network access restriction not recognizing existing rulesBicep 配置网络访问限制不识别现有规则
【发布时间】:2022-12-08 22:29:54
【问题描述】:

我是一名从事现有 Azure 项目的承包商。目前,我的客户正在为每个环境(开发、QA、生产)手动配置所有 Azure 资源。我知道这会让人们感到震惊,但他们的订阅一团糟。我正在尝试使用二头肌设置 IaC 部署。

对于 Azure 应用服务,他们有一个 IP 访问限制设置,只允许来自他们的 APIM 实例的流量。当我查看主站点的应用程序服务(在网络下)的访问限制时,我可以看到它已列出。

但是,当我使用 --what-if 进行部署时,它返回说它将创建访问限制规则。我不期待这个,因为它应该已经存在了。我到处搜索,但找不到答案。

apiAppService.bicep

@description('The name of the target app service without any prefix or suffix. i.e. Contoso')
param apiName string

@description('The abbreviation of the target environment. i.e. dev')
@allowed([
  'dev'
  'qa'
  'prod'
])
param environment string

@description('The Azure region the resource group is to be created in.')
param region string

@description('The abbreviation of the Azure region included as part of the resource group name. i.e. NCUS')
param regionAbbreviation string

@description('The properties of the SKU for the app service plan.')
param appServicePlanSku object

@description('The runtime stack of the target app service. i.e. DOTNETCORE|6.0')
param runtimeStack string

@description('The values required to setup the IP access restriction')
param ipRestriction object


var appServicePlanName = 'ASP-${apiName}-${regionAbbreviation}-${environment}'
var appServiceName = 'productname-${apiName}-api-${environment}'


resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: appServicePlanName
  location: region
  sku: {
    name: appServicePlanSku.name
    tier: appServicePlanSku.tier
  }
  kind: 'linux'
  properties: {
    reserved: true
  }
}

resource appService 'Microsoft.Web/sites@2022-03-01' = {
  name: appServiceName
  location: region
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
    siteConfig: {
      linuxFxVersion: runtimeStack
      ipSecurityRestrictions: [
        {
          name: ipRestriction.name
          action: ipRestriction.action
          priority: ipRestriction.priority
          ipAddress: ipRestriction.ipAddress
        }
      ]
    }
  }
}

--what-if 部署的结果

 ~ Microsoft.Web/sites/productname-apiname-api-dev [2022-03-01]
    + properties.siteConfig.ipSecurityRestrictions: [
        0:

          action:    "allow"
          ipAddress: "a.b.c.d/32"
          name:      "Allow ONLY APIM"
          priority:  300

      ]
    + properties.siteConfig.localMySqlEnabled: false
    ~ properties.httpsOnly:                    false => true

我在尝试配置不同的东西吗?我究竟做错了什么?

【问题讨论】:

  • 您好,也许您应该尝试创建此新规则并在门户网站上检查两者之间是否存在任何差异。我建议提高新优先级(假设为 400)。您可以检查资源的 json 模板以便更好地查看。
  • @mwa 我希望不必部署来弄清楚发生了什么。但我确实喜欢你的建议,如果那是我必须走的路的话,首先增加优先级。幸运的是,我创建二头肌文件的方式很容易只针对单个资源,因此如果我必须进行测试来解决这个问题,我不会弄乱整个开发环境。
  • @erionpc 创建了 this SO post 他引用了另一篇文章。它提到使用Azure Resource Explorer 对资源进行一些调查。我认为这最终将成为让我的问题得到解答的门票。停了一天,明天再去取。

标签: azure azure-web-app-service


【解决方案1】:

使用 Azure Resource Explorer 被证明是非常有帮助的。如果您还没有并且正在构建二头肌文件,请检查一下。 IP 限制实际上位于应用服务资源之外的路径为“config/web”的资源中。基本上定义看起来像

resource webConfig 'Microsoft.Web/sites/config@2022-03-01' = {
  name: 'web'
  parent: appService
  properties: {
    linuxFxVersion: runtimeStack
    ipSecurityRestrictions: [
      {
        name: ipRestriction.name
        action: ipRestriction.action
        priority: ipRestriction.priority
        ipAddress: ipRestriction.ipAddress
      }
      {
        name: 'Deny all'
        description: 'Deny all access'
        action: 'Deny'
        priority: 2147483647
        ipAddress: 'Any'
      }
    ]
  }
}

name: 'web'parent: appService 非常重要,因为最后默认拒绝所有规则。

【讨论】: