Bicep configure network access restriction not recognizing existing rules

Question

I'm a contractor working on an existing Azure project. Currently, my client is manually configuring all their Azure resources for each environment (Dev, QA, Prod). I know this is shocking to people, but their subscriptions are a mess. I'm trying to setup IaC deployments using bicep.

For the Azure App Services, they have an IP Access Restriction setup to only allow traffic from their APIM instance. When I look at the access restrictions for the app service (under networking) for the main site, I can see it listed.

However, when I deploy using --what-if, it comes back saying it will create the access restriction rule. I'm not expecting this because it should already exist. I've searched high and low but can't find the answer.

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
        }
      ]
    }
  }
}

The results of the --what-if deployment

 ~ 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

Am I trying to configure different things? What am I doing wrong?

Hi, may be you should try to create this new rule and check on the portal if there is any differences between both. I would suggest to elevate the priority for the new one ( lets say 400). You can check the json template of your resource to see better. — mwa, Dec 07 '22 at 08:13
@mwa I was hoping to not have to deploy to figure out what's going on. But I do like your suggestion to increase the priority first if that's the route I have to go. Fortunately, I've created the bicep files in a way it'll be easy to only target a single resource so I don't mess up the entire dev environment if I have to do a test to figure this out. — BTSoft, Dec 07 '22 at 13:56
[@erionpc](https://stackoverflow.com/users/2495345/erionpc) created [this SO post](https://stackoverflow.com/questions/69897663/setting-azure-app-service-server-stack-on-a-bicep-template) where he referenced another article. It mentioned using the [Azure Resource Explorer](https://resources.azure.com) to do some investigation on resources. I think this will end up being the ticket to getting my question answered. Stopping for the day so picking it up tomorrow. — BTSoft, Dec 07 '22 at 22:14

score 0 · Answer 1 · answered Dec 08 '22 at 14:22

Using Azure Resource Explorer proved to be very helpful. Check it out if you haven't and you're building bicep files. The IP restrictions are actually in a resource with a path 'config/web' off the app service resource. Essentially the definition looks like

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'
      }
    ]
  }
}

The name: 'web' and parent: appService is very important as is the default deny all rule at the end.

Bicep configure network access restriction not recognizing existing rules

1 Answers1