Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#3,907 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
azure, powershell
Ambito
tooling

Direzione di ricerca

Inizia da GetBicepParamResources e segui il livello di mock generico usato quando non è possibile risolvere le risorse referenziate. Riproduci i due errori cidrHost/cidrSubnet, quindi verifica che i segnaposto tipizzati preservino l’espansione per le proprietà di indirizzo elencate, mentre le proprietà mancanti non correlate e la convalida rigorosa CIDR mantengano il comportamento attuale.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
PowerShell
Stelle
449
Fork
111
Merge medio
2g 4h
PR unite (30g)
8

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Azure/PSRule.Rules.Azure

Tutte le issue di Azure/PSRule.Rules.Azure

Issue simili

Altre issue su DevTools

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.