azurerm_cosmosdb_account ip_range_filter doesn't actually allow /8 in CIDR

[stefan-kiss]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

v1.2.8

AzureRM Provider Version

v3.20.0

Affected Resource(s)/Data Source(s)

azurerm_cosmosdb_account

Terraform Configuration Files

resource "azurerm_cosmosdb_account" "db" {
  name                              = "test-cosmos"
  location                          = "eastus2"
  resource_group_name               = "whatever-group-name"
  offer_type                        = "Standard"
  public_network_access_enabled     = true
  ip_range_filter                   = "0.0.0.0,1.0.0.0/8"

  enable_automatic_failover = true

  capabilities {
    name = "EnableAggregationPipeline"
  }

  capabilities {
    name = "mongoEnableDocLevelTTL"
  }


  consistency_policy {
    consistency_level       = "BoundedStaleness"
    max_interval_in_seconds = 300
    max_staleness_prefix    = 100000
  }

  geo_location {
    location          = "eastus2"
    failover_priority = 0
  }

}

Debug Output/Panic Output

╷
│ Error: invalid value for ip_range_filter (Cosmos DB ip_range_filter must be a set of CIDR IP addresses separated by commas with no spaces: '10.0.0.1,10.0.0.2,10.20.0.0/16')
│
│   with module.cosmosdb.azurerm_cosmosdb_account.db,
│   on cosmosdb/main.tf line 57, in resource "azurerm_cosmosdb_account" "db":
│   57:   ip_range_filter                   = "0.0.0.0,1.0.0.0/8"
│
╵

Expected Behaviour

to create the cluster with the filter requested

Actual Behaviour

the error

notes

• azure does not accept private ip ranges there. maybe documentation should be updated
• /8 cidr may be almost unusable - BUT it's a valid cidr and thus supported.
• the problem comes from the regexp used here : cosmosdb_account_resource.go - the capture group for the mask has mandatory TWO digits. it could have the first digit optional (*)

Steps to Reproduce

you need to have an existing whatever-group-name

Important Factoids

No response

References

This reference is only provided as support for the statement "azure does not accept private ip ranges there"
#7946

[bart-vmware]

I'm being blocked by this bug as well. Trying to use: 31.0.0.0/7,106.0.0.0/6, which is rejected inappropriately. Suggested fix is to change:

terraform-provider-azurerm/internal/services/cosmos/cosmosdb_account_resource.go

Line 272 in 00e020c

regexp.MustCompile(`^(\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(/([1-2][0-9]|3[0-2]))?\b[,]?)*$`),

to:

regexp.MustCompile(`^(\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(/([1-2]?[0-9]|3[0-2]))?\b[,]?)*$`),

Would you accept a PR?

[ShreyasRmsft]

We're blocked by this as well

[Sheludchenko]

Same thing for me. I added private endpoints to our instances, which immediately blocked public access. The only way to handle that is to add the following list of IP ranges:
0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/3,96.0.0.0/6,100.0.0.0/10,100.128.0.0/9,101.0.0.0/8,102.0.0.0/7,104.0.0.0/5,112.0.0.0/4,128.0.0.0/3,160.0.0.0/5,168.0.0.0/6,172.0.0.0/12,172.32.0.0/11,172.64.0.0/10,172.128.0.0/9,173.0.0.0/8,174.0.0.0/7,176.0.0.0/4,192.0.0.0/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4,224.0.0.0/3

@bart-vmware I'd suggest replacing the current RegEx with
^(\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(/([1-2][0-9]|3[0-2]|[3-9]))?\b[,]?)*$ instead, since the system won't accept any of /2 or /1 anyway.

[Sheludchenko]

Added PR for the issue #24306