Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[BUG] cidrHost/cidrSubnet fail during Bicep expansion when address prefixes are assigned outside the template

Open
  • Is something wrong?
#3,907 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
azure, powershell
Domain
tooling

Research direction

Start at GetBicepParamResources and trace the generic mock layer used when referenced resources cannot be resolved. Reproduce the two cidrHost/cidrSubnet failures, then verify that typed placeholders preserve expansion for the listed address properties while unrelated missing properties and strict CIDR validation retain their current behavior.

Written by the indexing model from the issue text.

Description

bug feature: bicep-language feature: pre-flight-expansion
Existing rule

N/A — this affects Bicep expansion rather than a specific rule.

Description of the issue

When a virtual network, subnet, or IPAM pool gets its address prefixes assigned outside the template being analyzed, the properties.addressPrefixes value cannot be resolved during expansion. PSRule for Azure creates a generic mock for the unresolved reference, and unknown string properties on that mock resolve to an empty string.

The cidr*() functions validate their input strictly, so any expression that consumes such a value fails expansion of the whole deployment:

The specified CIDR '' is not valid.

This is increasingly common with Azure Virtual Network Manager IPAM. The prefixes are allocated by IPAM at deploy time via ipamPoolPrefixAllocations, so they are genuinely not knowable from the source. Anything derived from them with cidrHost() or cidrSubnet() — a static private frontend IP for an Application Gateway is the typical case — cannot be analyzed at all today.

The generic mock already knows the resource type of the reference. That is enough to supply a well-formed placeholder for a small set of well-known address properties, so expansion can continue instead of failing outright.

Two related gaps make this worse than it first appears:

  1. Existing (existing = {}) resources are registered as deployment symbols but are not added to the resource ID lookup, so reference('vnet::subnet') can fall back to a mock built from the bare symbolic name and lose the resource type entirely.
  2. When a resource declares a partial properties object (for example a subnet that sets ipamPoolPrefixAllocations but not addressPrefixes), the properties are wrapped in a plain mock object. Resource type context is lost, so missing sibling properties cannot be inferred even when the type is known.

Importantly, a fix here should not relax the cidr*() functions themselves. Keeping them strict is what still catches genuine authoring mistakes such as passing id instead of an address prefix, or passing addressPrefixes without indexing it.

Error messages
Failed to expand bicep source 'deploy.bicepparam'. Exception calling "GetBicepParamResources" with "2" argument(s):
"Unable to expand resources because the source file 'deploy.bicepparam' was not valid.
The deployment 'root/example' with symbolic name 'example' failed.
An error occurred evaluating expression '[cidrHost(reference('vnet::subnet').addressPrefixes[0], 3)]'
at path 'properties.frontendIPConfigurations[1].properties.privateIPAddress'.
The function 'cidrHost' failed. The specified CIDR '' is not valid."

An error occurred evaluating expression '[cidrSubnet(reference('networkManager::platformPool').addressPrefixes[0], 23, 0)]'.
The function 'cidrSubnet' failed. The specified CIDR '' is not valid."
Reproduction

Both cases below fail expansion.

Case 1 — subnet address prefix allocated by IPAM

targetScope = 'resourceGroup'

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' existing = {
  name: 'vnet-example'

  resource subnet 'subnets' = {
    name: 'ApplicationGatewaySubnet'
    properties: {
      ipamPoolPrefixAllocations: [
        {
          numberOfIpAddresses: '256'
          pool: { id: '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-example/providers/Microsoft.Network/networkManagers/vnm-example/ipamPools/pool-example' }
        }
      ]
      defaultOutboundAccess: true
    }
  }
}

// Fails: The specified CIDR '' is not valid.
output privateFrontendIP string = cidrHost(vnet::subnet.properties.addressPrefixes[0], 3)

Case 2 — IPAM pool address prefix

targetScope = 'resourceGroup'

resource networkManager 'Microsoft.Network/networkManagers@2024-05-01' existing = {
  name: 'vnm-example'

  resource platformPool 'ipamPools' existing = {
    name: 'pool-example'
  }
}

// Fails: The specified CIDR '' is not valid.
output reservation string = cidrSubnet(networkManager::platformPool.properties.addressPrefixes[0], 23, 0)

The same failure occurs for a virtual network whose properties.addressSpace.addressPrefixes is IPAM-allocated.

Version of PSRule

2.9.0

Version of PSRule for Azure

1.48.0-B0231

Additional context

A targeted fix would be to give the existing mock layer source awareness: a small table mapping resource type plus normalized property path to a typed placeholder, so only well-known address properties return a valid placeholder CIDR and everything else keeps today's behaviour.

Using the reserved documentation range from RFC 5737 (192.0.2.0/24) makes placeholders obvious in output and avoids colliding with plausible customer address space.

The minimal set that unblocks the IPAM scenarios:

  • Microsoft.Network/virtualNetworks → properties.addressSpace.addressPrefixes[]
  • Microsoft.Network/virtualNetworks/subnets → properties.addressPrefix
  • Microsoft.Network/virtualNetworks/subnets → properties.addressPrefixes[]
  • Microsoft.Network/networkManagers/ipamPools → properties.addressPrefixes[]

A table-driven approach keeps this easy to extend later to other resources that expose address-like outputs (network interfaces, public IPs, firewalls, DNS resolver inbound endpoints) without reworking the mock layer, and without requiring full ARM property schemas.

I have a working implementation of this and will follow up with a PR.

Dominant language
PowerShell
Stars
449
Forks
111
Avg merge
2d 4h
Merged PRs (30d)
8

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Azure/PSRule.Rules.Azure

All issues in Azure/PSRule.Rules.Azure

Similar issues

More DevTools issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.