azure-cli: Values for request parameters are invalid: networkAcls.virtualNetworkRules[*].id

Describe the bug

Command Name az deployment group create

Errors:

InvalidTemplateDeployment - The template deployment 'api-deployment' is not valid according to the validation procedure. The tracking id is 'f1c7b947-7f69-4a85-910a-a182fc481255'. See inner errors for details.
PreflightValidationCheckFailed - Preflight validation failed. Please refer to the details for the specific errors.
InvalidValuesForRequestParameters - Values for request parameters are invalid: networkAcls.virtualNetworkRules[*].id. For more information, see - https://aka.ms/storagenetworkruleset

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

az deployment group create --name "api-deployment" --resource-group "api" --template-file "api.json" --parameters "api.parameters.json"

Expected Behavior

deploy template to resource group “api”

Environment Summary

Windows-10-10.0.18362-SP0
Python 3.6.6
Installer: MSI

azure-cli 2.9.1

Additional Context

I have three ARM templates: “network”, “database” and “api”. In the first step, I create a virtual network (VNET) with a subnet with the “network” template. Then I create a cosmosdb database with the “database” template with VNET integration and it works fine. In the third step I want to run the “api” template, but I get this error.

Here are some excerpts:

network:

...
"outputs": {
  ...
  "subnet1ResourceId": {
    "type": "string",
    "value": "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('vnetName'), parameters('subnet1Name'))]"
  }
}

database: (works fine)

...
"variables": {
  "networkDeploymentResourceId": "[resourceId(parameters('networkGroupName'), 'Microsoft.Resources/deployments', parameters('networkDeploymentName'))]",
...
},
...
"resources":{
  "type": "Microsoft.DocumentDB/databaseAccounts",
  ...
  "properties": {
    "isVirtualNetworkFilterEnabled": true,
    "virtualNetworkRules": [
      {
        "id": "[reference(variables('networkDeploymentResourceId'), '2020-06-01').outputs.subnet1ResourceId.value]"
      }
    ],
    ...
  }
  ...
}

...
"variables": {
  "networkDeploymentResourceId": "[resourceId(parameters('networkGroupName'), 'Microsoft.Resources/deployments', parameters('networkDeploymentName'))]",
...
},
...
"resources":{
  "type": "Microsoft.Storage/storageAccounts",
  "apiVersion": "2019-06-01",
  ...
  "properties": {
    "networkAcls": {
      "bypass": "AzureServices",
      "defaultAction": "Deny",
      "virtualNetworkRules": [
        {
          "id": "[reference(variables('networkDeploymentResourceId'), '2020-06-01').outputs.subnet1ResourceId.value]",
          "action": "Allow"
        }
      ]
    },
    "supportsHttpsTrafficOnly": true
  }
  ...
}

And here’s the strange thing: If I use the reference statement somewhere else, it works.

"[reference(variables('networkDeploymentResourceId'), '2020-06-01').outputs.subnet1ResourceId.value]"

And if I pass the resourceId directly, it also works:

"virtualNetworkRules": [
  {
    "id": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Network/virtualNetworks/.../subnets/...",
    "action": "Allow"
  }
]

Edit: I think it’s a problem with the CLI because it worked well with an older version of the CLI. But I don’t remember which version.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 3
Comments: 21 (5 by maintainers)

Most upvoted comments

Just started running into the same error using [concat(parameters('vnetId'), parameters('subnetId'))] for the storage account networkAcls.virtualNetworkRules.id.

Seems like the field does not accept any functions and needs a hardcoded value. Is there an update on this?

Nikash on Mar 3, 2021

This approach: “you can use the existing keyword to also obtain a strongly typed reference to the subnet” might be a temporary solution:

networkAcls: {
      bypass: 'None'
      virtualNetworkRules: [
        {
          id: virtualNetwork::subnet1.id
          action: 'Allow'
        }
      ]
      defaultAction: 'Deny'
    }

KarenTazayan on Oct 19, 2023

@Saj1234 I can confirm that directly passing the subnetId as parameter instead of passing the qualified name and creating a resource reference using existing makes the error disappear!

param subnetId string

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: configuration.name
  location: location
  sku: {
    name: configuration.sku
  }
  properties: {
    publicNetworkAccess: 'Disabled'
    allowBlobPublicAccess: false    
    networkAcls: {
      bypass: 'AzureServices'
      defaultAction: 'Deny'
      virtualNetworkRules: [
        {
          id: subnetId
        }
      ]
    }
  }
  kind: 'StorageV2'
}

pthalamy on Feb 6, 2023

Hi, I also faced that issue when using Bicep and trying to reference a subnet via vnet1.properties.subnets[0].id.

kamil-mrzyglod on Jun 25, 2022

I too was hitting “invalid: networkAcls.virtualNetworkRules” error when run from the bash terminal in VScode. What fixed it for me was [https://stackoverflow.com/questions/7250130/how-to-stop-mingw-and-msys-from-mangling-path-names-given-at-the-command-line#34386471] i.e. ensure MSYS_NO_PATHCONV=1 is one of the environment variables.

The link was provided by Microsoft support when I raised the issue. Other tips to pass on;

the az command worked fine in the Portal CLI
you can add “–debug” to the command, which in my case revealed that part of my filesystem path was being added into the parameter value and so creating an invalid resource id

robertparker9 on Jun 14, 2022