☁️ Azure IoT Central Application Network Rule Set Terraform Module

Manages the IP allow-list for an IoT Central Application — a singleton per application that governs which addresses devices may connect from, to the IoT Hub and Device Provisioning Service behind it (azurerm_iotcentral_application_network_rule_set). Targets hashicorp/azurerm ~> 4.0.

• 🛡️ The IP allow-list for an IoT Central Application — which addresses devices may connect from, to the IoT Hub and Device Provisioning Service behind it.
• 🔴 It governs DEVICE traffic and nothing else. The underlying Azure object has a second flag for the IoT Central web portal and REST APIs, and the provider hardcodes it to false on every write. This module is never evidence that operator or API access is restricted.
• 🔴 A singleton per application, whose Resource ID is the application's ID. There is no rule-set name, so two configurations managing it overwrite each other with no collision to warn anyone.
• 🔴 Deny with an empty ip_rule list denies every device, while apply_to_device is true. Azure reports no error. This module flags it rather than forbidding it, because the provider documents no minimum and a deny-all set is a legitimate posture.
• 🔴 And apply_to_device = false switches the allow-list OFF rather than narrowing it. Both apply-to flags are then false and the whole rule set applies to nothing — emitted as rule_set_is_inert.
• 🔴 A terraform destroy WIDENS access. There is no delete call; the provider clears the rule set out of the application, which reverts to accepting device connections from anywhere.
• ✅ Secure defaults, matching the provider's own: default_action = "Deny" makes ip_rule an allow-list, and apply_to_device = true is the only setting under which the allow-list is evaluated.
• ⚠️ ip_mask takes a single IPv4 address OR a CIDR block — the prefix is optional. IPv4 only. Rule names carry a charset and a 128-character cap this module mirrors, and must be unique case-insensitively.
• ⚠️ The service caps the list at 100 rules and the schema does not know it, so a 101-entry configuration plans clean and fails at apply. Reported, not enforced.
• ✅ Everything except the application reference updates in place, which makes revising an allow-list cheap.
• ℹ️ No tags. The resource exposes none; tag the application.

💡 Why it matters: This is a small resource with three outsized failure modes, and none of them produces an error. One configuration too many and the policy silently becomes whichever pipeline ran last. One range too few and every device in the fleet stops reporting — showing a bare 401 Unauthorized that reads as a credential problem. And one boolean the wrong way and the whole allow-list is carried in state, shown in every plan, and applied to nothing at all.

If this module saves you time, please consider supporting its continued development:

• ⭐ Star the repository on GitHub.
• 🤝 Connect on LinkedIn: linkedin.com/in/microsoftexpert
• ☕ Buy me a coffee: buymeacoffee.com/microsoftexpert

flowchart TB
  rg["terraform-azurerm-resource-group"]
  app["terraform-azurerm-iotcentral-application, which also owns public_network_access_enabled and defaults it to false"]
  rules["terraform-azurerm-iotcentral-application-network-rule-set"]
  org["terraform-azurerm-iotcentral-organization: consumes the SAME application id but governs a permissions hierarchy, not network access"]
  devices["DEVICES connecting to the IoT Hub and Device Provisioning Service behind the application. The ONLY surface this rule set can govern, and only while apply_to_device is true, which is the default."]
  ops["THE IoT CENTRAL WEB PORTAL AND REST API. NEVER governed by this rule set. The provider hardcodes the portal-and-API flag to false on every write, so restricting operator access is an identity and Conditional Access question."]
  singleton["ONE RULE SET PER APPLICATION, addressed by the application's own Resource ID. There is no rule-set name, so two configurations managing it overwrite each other with no collision to warn anyone."]

  rg -->|"name, location"| app
  app -->|"id, as iotcentral_application_id"| rules
  app -->|"id, for a different purpose"| org
  rules -.->|"CANNOT reach, at any setting"| ops
  rules -->|"allow-list governs, while apply_to_device is true"| devices
  singleton -->|"applies to"| rules
  app -->|"its own public network access is a SEPARATE layer neither module can see"| rules

  classDef mine fill:#0078D4,stroke:#004578,color:#fff;
  classDef keystone fill:#004578,stroke:#001f3f,color:#fff;
  classDef sib fill:#eef2f7,stroke:#b8c4d0,color:#1b1b1b;
  class rules mine;
  class app,singleton keystone;
  class rg,org,devices,ops sib;

flowchart TB
  appid["iotcentral_application_id: REQUIRED, and the ONLY force-new field. Everything else updates in place, which makes revising an allow-list cheap."]
  same["THE RULE SET'S OWN ID IS THE APPLICATION'S ID. There is no rule-set name, so the ID check is anchored with a dollar terminator and terraform import takes the application id."]
  da["default_action: Deny by default, which makes ip_rule an ALLOW-LIST. Setting Allow permits unmatched traffic and turns the whole resource into a no-op."]
  atd["apply_to_device: true by default, and the ONLY setting under which this rule set does anything. It governs device connectivity to the IoT Hub and Device Provisioning Service, which is the sole surface reachable from here."]
  inert["apply_to_device false SWITCHES THE ALLOW-LIST OFF rather than narrowing it. Both apply-to flags are then false, so default_action and every ip_rule entry are stored and applied to NOTHING. Emitted as rule_set_is_inert."]
  rules["ip_rule: named entries, empty by default. ip_mask takes a single IPv4 ADDRESS or a CIDR block, the prefix being OPTIONAL, and IPv4 only. Names carry a mirrored charset and a 128 character cap, and must be unique case-insensitively."]
  denyall["DENY PLUS AN EMPTY LIST DENIES EVERY DEVICE while apply_to_device is true, and Azure reports no error. Deliberately NOT validated, because the provider documents no minimum and a deny-all set is a legitimate commissioning or incident posture. Emitted as denies_all_access instead."]
  cap["THE SERVICE CAPS THE LIST AT 100 RULES and the schema carries no maximum, so a 101 entry configuration plans clean and fails at apply. Raisable by support request, so REPORTED and not enforced."]
  destroy["A DESTROY WIDENS ACCESS. There is no delete call: the provider clears the rule set out of the application and PUTs the application back without it. Emitted as destroy_removes_the_restriction."]
  notags["NO tags attribute exists, confirmed against the schema. Tag the application."]
  this["azurerm_iotcentral_application_network_rule_set.this"]
  outputs["id, default_action_is_deny, applies_to_device_connectivity, governs_device_traffic_only, rule_set_is_inert, permitted_cidrs, permitted_rule_count, ip_rule_count_within_service_limit, denies_all_access, permits_entire_internet, every_rule_is_an_allow_rule, destroy_removes_the_restriction, is_singleton_per_application"]

  appid -->|"parent"| same
  same -->|"validated"| this
  da -->|"secure default"| this
  atd -->|"secure default"| this
  rules -->|"allow-list"| this
  atd -->|"set false"| inert
  inert -->|"flagged, not forbidden"| outputs
  da -->|"combined with an empty list"| denyall
  rules -->|"combined with Deny"| denyall
  rules -->|"counted against"| cap
  cap -->|"reported, not enforced"| outputs
  denyall -->|"flagged, not forbidden"| outputs
  notags -->|"universal tail omitted"| this
  this -->|"exports"| outputs
  this -->|"destroyed"| destroy

  classDef mine fill:#0078D4,stroke:#004578,color:#fff;
  classDef keystone fill:#004578,stroke:#001f3f,color:#fff;
  classDef sib fill:#eef2f7,stroke:#b8c4d0,color:#1b1b1b;
  class this mine;
  class da,atd mine;
  class denyall,same,inert,destroy keystone;
  class appid,rules,notags,outputs,cap sib;

Resource inventory

Schema notes that bite — argument facts confirmed against the live provider schema; the behavioural facts below it cannot carry are confirmed against the provider source, and the service limits against Microsoft's documentation:

• 🔴 THE PORTAL-AND-API FLAG IS HARDCODED OFF. The underlying Azure object carries two apply-to flags, one for device connectivity to the IoT Hub and DPS and one for connectivity via the IoT Central web portal and REST APIs. The provider sets the second to false on every create and every update, never reads it back, and exposes no argument for it. So this resource governs device traffic only, at every setting — it is not evidence that operator or API access is restricted, and it cannot be made so. Invisible in the schema and absent from the registry documentation; confirmed in the provider source, and corroborated by Microsoft's IoT Central security baseline.
• 🔴 apply_to_device = false switches the allow-list OFF, it does not narrow it. Both flags are then false and nothing is evaluated; the provider's own duplicate-import guard treats that combination as an unconfigured rule set.
• 🔴 A terraform destroy WIDENS access. The provider makes no delete call. It clears the rule set out of the application and PUTs the application back without it, reverting the application to accepting device connections from anywhere. No destroy plan says so.
• 🔴 A rule set cleared out of band makes plan FAIL, not re-create. When the application exists but has no rule set, the read returns an error rather than marking the resource gone.
• 🔴 The rule set's Resource ID is identical to the application's. One rule set per application, no rule-set name, so nothing distinguishes them by shape and two owners produce no collision — they write the same object.
• ⚠️ terraform import takes the application's ID, which looks like importing the wrong resource.
• ⚠️ The application ID is parsed CASE-SENSITIVELY. A copied ID that lower-cases /resourcegroups/ or microsoft.iotcentral is refused. This module mirrors that so the failure lands at validate.
• 🔴 default_action = "Deny" plus an empty ip_rule list denies every device, while apply_to_device is true. Valid configuration; no error.
• 🔴 default_action = "Allow" makes the resource a no-op — unmatched traffic is permitted and the rules restrict nothing. The value is case-sensitive; "deny" is refused.
• ⚠️ ip_mask takes a single IPv4 address OR a CIDR block — the prefix group in the provider's validator is optional, and Microsoft documents both forms. IPv4 only: IPv6 has no accepted form here and is not supported on IoT Hub or DPS at all.
• ⚠️ The provider does not bound the octets to 255. 256.0.0.1 satisfies its regex and reaches Azure.
• ⚠️ ip_rule.name carries a charset and a 128-character cap the schema does not show: ASCII letters and digits plus - : . + % _ # * ? ! ( ) , = @ ; '. The validator is borrowed from the IoT Hub service and its message names a non-existent argument called ip_rule_name.
• ⚠️ ip_rule names must be unique, case-insensitively, per Microsoft. The provider performs no de-duplication, so what a duplicate does is undefined rather than documented.
• ⚠️ The service caps the list at 100 rules and the schema carries no maximum. A 101-entry configuration plans clean and fails at apply. Microsoft documents the cap as raisable by support request.
• ⚠️ Every write is a PUT of the whole application, and only create takes a lock. Update and delete perform an unlocked read-modify-write of the entire application model, which is also why all three write timeouts are budgeted at 30 minutes.
• ⚠️ A blocked device sees a bare 401 Unauthorized whose message does not mention the IP rule.
• ⚠️ It interacts with the application's own public_network_access_enabled, which the sibling application module defaults to false. Neither module can see the other's setting.
• ℹ️ There is no per-rule deny. The underlying object has a per-rule action field, the provider does not expose it, and its only defined value is Allow.
• ℹ️ The ARM API version behind this resource is a PREVIEW version, 2021-11-01-preview.
• ✅ Only iotcentral_application_id is force-new. There is no CustomizeDiff on this resource at all, so there is no conditional or one-directional force-new to discover.
• No tags attribute exists.
• lifecycle is not valid inside a module block, so a caller cannot add prevent_destroy. Use a CanNotDelete management lock on the application.

💡 Scope it to the application resource, not its resource group. That is the whole requirement.

⚠️ Understand the blast radius, because it is unusual. A principal who can edit this rule set can cut off every device connected to the application, or open it to the entire internet. Neither destroys data, and both are production incidents — so this is a change-control question rather than a permissions one (example 4).

🔴 There is no sub-application scope to grant, because every write is a PUT of the whole application. The provider reads the application, replaces its network rule set, and writes the entire model back. So the same grant also permits rewriting the application's display name, subdomain, template and public network access. A role that looks tighter than the application does not exist. No published Microsoft role definition is scoped to this property, so the table above is the least-privilege grant that works rather than a citation.

✅ Plan access here is not credential access. The read calls a single Get and populates three non-secret fields; nothing in this resource's API surface lists keys, and no output is sensitive.

• An existing IoT Central Application, passed as an attribute reference (example 2).
• The Microsoft.IoTCentral resource provider registered on the subscription.
• The egress ranges the devices actually connect from — the hard part of using this resource at all (example 5). Microsoft warns specifically to list the address of any proxy the devices connect through rather than the devices' own addresses.

terraform-azurerm-iotcentral-application-network-rule-set/
├── providers.tf   # required_version + the pinned azurerm provider. No provider block.
├── variables.tf   # iotcentral_application_id, default_action, apply_to_device, ip_rule, timeouts
├── main.tf        # the keystone `this` + ip_rule from a canonical map + dynamic timeouts
├── outputs.tf     # id first, then the allow-list, then the derived posture flags
├── README.md      # this document
├── SCOPE.md       # the cross-module contract
├── LICENSE        # MIT
└── .gitignore

provider "azurerm" {
  features {}
}

module "app_network_rules" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-iotcentral-application-network-rule-set.git?ref=v1.0.0"

  # Attribute reference, not a literal (example 2).
  iotcentral_application_id = module.iotcentral_application.id

  # default_action defaults to "Deny" and apply_to_device to true — both kept.
  ip_rule = [
    { name = "hq-egress", ip_mask = "203.0.113.0/24" },
    { name = "plant-uk", ip_mask = "198.51.100.16/28" },
  ]
}

ℹ️ The caller configures the provider, its authentication, and the mandatory features {} block. This module declares none of them.

🔴 An empty ip_rule list here would deny every device. Read example 3 before applying one.

Consumes

Emits

No secret is accepted and none is emitted.

Values these examples reference but do not create are declared inputs:

variable "organization_id" {
  description = "organization id of an existing resource these examples reference."
  type        = string
}

IoT Central Application "iotc-plant-telemetry"
  ├── web portal + REST API      <- NEVER governed by this rule set, at any setting
  └── behind it, managed by Azure: an IoT Hub + a Device Provisioning Service
        └── DEVICES connect here <- the ONLY surface this rule set can govern

network rule set (this module):
  default_action  = "Deny"    -> ip_rule is an allow-list for device connections
  apply_to_device = true      -> the allow-list is evaluated at all
  apply_to_device = false     -> the allow-list is evaluated for NOTHING

application ID:  /subscriptions/.../providers/Microsoft.IoTCentral/iotApps/iotc-plant-telemetry
rule set ID:     /subscriptions/.../providers/Microsoft.IoTCentral/iotApps/iotc-plant-telemetry
                 ^ identical. There is no rule-set name.

default_action  = "Deny"   # the default
apply_to_device = true     # the default
ip_rule         = []       # the default

# Result: no device may connect. Telemetry stops.
# (The web portal and REST API are unaffected — this rule set never governs them.)

output "availability_check" {
  value = module.app_network_rules.denies_all_access # expect false in production
}

Contributor on the APPLICATION  ->  can rewrite the allow-list
                                ->  can set default_action = "Allow"   (open it up)
                                ->  can set ip_rule = []               (close it entirely)

ip_rule = [
  # Sites with stable egress — the easy half:
  { name = "plant-uk", ip_mask = "198.51.100.16/28" },
  { name = "plant-de", ip_mask = "198.51.100.32/28" },

  # A single host needs no prefix — a bare address is legal:
  { name = "jump-host", ip_mask = "203.0.113.5" },

  # ...and /32 says the same thing, if you prefer it explicit:
  { name = "gateway-uk", ip_mask = "198.51.100.7/32" },
]

# Adding a site is an in-place update — no replacement, no downtime:
ip_rule = [
  { name = "hq-egress", ip_mask = "203.0.113.0/24" },
  { name = "plant-uk", ip_mask = "198.51.100.16/28" },
  { name = "plant-fr", ip_mask = "198.51.100.48/28" }, # new
]

azurerm_iotcentral_application_network_rule_set:  no `tags` attribute exists.
azurerm_iotcentral_application:                   `tags` exists — tag the APPLICATION.

terraform import 'module.app_network_rules.azurerm_iotcentral_application_network_rule_set.this' \
  "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-iot-platform/providers/Microsoft.IoTCentral/iotApps/iotc-plant-telemetry"

output "rule_set_review" {
  value = {
    id         = module.app_network_rules.id
    deny_first = module.app_network_rules.default_action_is_deny         # assert true
    devices    = module.app_network_rules.applies_to_device_connectivity # assert true
    inert      = module.app_network_rules.rule_set_is_inert              # 🔴 assert false
    locked_out = module.app_network_rules.denies_all_access              # 🔴 assert false
    wide_open  = module.app_network_rules.permits_entire_internet        # 🔒 assert false
    count      = module.app_network_rules.permitted_rule_count
    in_limit   = module.app_network_rules.ip_rule_count_within_service_limit # ⚠️ assert true
    ranges     = module.app_network_rules.permitted_cidrs
    singleton  = module.app_network_rules.is_singleton_per_application   # always true
    devices_only = module.app_network_rules.governs_device_traffic_only  # always true
  }
}

terraform init -backend=false
terraform validate
terraform fmt -check

terraform destroy on this module:
  issues NO delete call  ->  the provider clears the rule set out of the application
                         ->  and PUTs the whole application back without it
  removes the RULE SET   ->  the application survives
                         ->  the allow-list is gone, so the restriction is gone
                         ->  access reverts to the application's own public_network_access setting

# In the application module (sibling):
public_network_access_enabled = false   # its default — nothing public at all

# Here:
default_action = "Deny"
ip_rule        = [{ name = "hq-egress", ip_mask = "203.0.113.0/24" }]

provider "azurerm" {
  features {}
}

module "rg" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-resource-group.git?ref=v1.0.0"

  name     = "rg-iot-platform"
  location = "eastus"
}

# ── The application. Its own public-access switch is the backstop layer ─────
module "iotcentral_application" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-iotcentral-application.git?ref=v1.0.0"

  name                = "iotc-plant-telemetry"
  resource_group_name = module.rg.name
  location            = module.rg.location
  sub_domain          = "contoso-plant-telemetry"
  display_name        = "Plant telemetry"

  # That module defaults this to false — the backstop of examples 10 and 11.
  # public_network_access_enabled = false

  tags = { owner = "ot-platform" }
}

# ── This module: the allow-list. EXACTLY ONE config may own it (example 2) ──
module "app_network_rules" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-iotcentral-application-network-rule-set.git?ref=v1.0.0"

  iotcentral_application_id = module.iotcentral_application.id

  # Deny by default, so ip_rule is an allow-list. Stated explicitly for the reader.
  default_action = "Deny"

  # true by default, and the only setting under which the allow-list is evaluated at all.
  # Setting false would switch it off rather than narrow it (example 3).
  apply_to_device = true

  # DEVICE egress ranges only — this rule set never governs the portal or the REST API.
  # List the PROXY address where devices connect through one (example 5).
  ip_rule = [
    { name = "plant-uk", ip_mask = "198.51.100.16/28" },
    { name = "plant-de", ip_mask = "198.51.100.32/28" },
    # A bare address is legal; the CIDR prefix is optional.
    { name = "gateway-uk", ip_mask = "198.51.100.7" },
  ]
}

# ── Organizations: same application, entirely different concern (example 1) ──
module "plant_orgs" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-iotcentral-organization.git?ref=v1.0.0"

  iotcentral_application_id = module.iotcentral_application.id
  organization_id           = "plant-uk"
  display_name              = "Plant UK"
}

output "iot_access_posture" {
  value = {
    # 🔴 The three that matter, and they fail in three different directions (example 9).
    inert      = module.app_network_rules.rule_set_is_inert        # assert false
    locked_out = module.app_network_rules.denies_all_access        # assert false
    wide_open  = module.app_network_rules.permits_entire_internet  # assert false
    deny_first = module.app_network_rules.default_action_is_deny   # assert true
    in_limit   = module.app_network_rules.ip_rule_count_within_service_limit # assert true
    ranges     = module.app_network_rules.permitted_cidrs
  }
}

variable "iotcentral_application_id" {
  type = string
  # Anchored with $ because this rule set's own ID is IDENTICAL to the application's — nothing distinguishes
  # them by shape, so the anchor is what rejects a child path appended to either. CASE-SENSITIVE, because the
  # provider's generated parser compares the literal segments resourceGroups, Microsoft.IoTCentral and iotApps
  # exactly, so a lower-cased ID fails at plan anyway — mirroring that moves the failure to validate. See
  # example 2.
  validation {
    condition     = can(regex("^/subscriptions/[^/]+/resourceGroups/[^/]+/providers/Microsoft[.]IoTCentral/iotApps/[^/]+$", var.iotcentral_application_id))
    error_message = "iotcentral_application_id must be a full IoT Central Application Resource ID ending in /providers/Microsoft.IoTCentral/iotApps/<name> ..."
  }
}

variable "ip_rule" {
  type = list(object({
    name    = string
    ip_mask = string
  }))
  default = []
  # Duplicate NAMES are rejected, case-insensitively, because the vendor documents a rule name as a unique
  # case-insensitive string and the provider performs no de-duplication of its own — so what a duplicate does
  # is undefined rather than documented. But an EMPTY list is NOT rejected even though it denies every device
  # when combined with default_action = "Deny": the provider documents no minimum, ip_rule is genuinely
  # optional, and a deny-all set is a legitimate commissioning or incident posture. Rejecting it would refuse
  # legal input, so the state is emitted as `denies_all_access` instead. See example 3.
  validation {
    condition     = length(distinct([for r in var.ip_rule : lower(trimspace(r.name))])) == length(var.ip_rule)
    error_message = "ip_rule contains two entries with the same name ..."
  }
  # MIRRORS THE PROVIDER'S OWN VALIDATOR: a dotted quad with an OPTIONAL /0-32 prefix, IPv4 only. The prefix is
  # optional in the provider and the vendor documents "a single IPv4 address OR a block in CIDR notation", so a
  # bare address is accepted here. The octets are deliberately NOT range-checked, because the provider does not
  # range-check them either. See example 5.
  validation {
    condition = alltrue([
      for r in var.ip_rule :
      can(regex("^([0-9]{1,3}[.]){3}[0-9]{1,3}(/([0-9]|[1-2][0-9]|3[0-2]))?$", trimspace(r.ip_mask)))
    ])
    error_message = "every ip_rule ip_mask must be an IPv4 address, optionally with a /0-32 CIDR prefix ..."
  }
  # A separate, actionable message for the one wrong shape a caller is likely to reach for: there is no correct
  # IPv6 spelling, because the service does not support IPv6 on IoT Hub or DPS at all.
  validation {
    condition     = alltrue([for r in var.ip_rule : !strcontains(trimspace(r.ip_mask), ":")])
    error_message = "an ip_rule ip_mask contains \":\", which reads as an IPv6 address. IPv6 is not supported ..."
  }
  # MIRRORS THE PROVIDER'S rule-name validator, which is borrowed from the IoT Hub service. A genuine lift, not
  # a duplicate: a provider schema validator does not fire through a module boundary. The message names `name`
  # deliberately — the provider's own message names a non-existent argument called `ip_rule_name`.
  validation {
    condition = alltrue([
      for r in var.ip_rule :
      can(regex("^[0-9a-zA-Z-:.+%_#*?!(),=@;']{1,128}$", r.name))
    ])
    error_message = "every ip_rule name must be 1 to 128 characters of ASCII letters and digits plus - : . + % _ # * ? ! ( ) , = @ ; ' ..."
  }
}

• The deny-everything combination is emitted, not validated, and that is a deliberate application of this suite's validation philosophy. default_action = "Deny" with an empty ip_rule list locks out every device, but the provider documents no minimum rule count, ip_rule is genuinely optional, and a deny-all set is a coherent posture while commissioning an application or containing an incident. Enforcing a minimum would reject legal input; denies_all_access makes the state assertable instead. This is the same treatment this library gives every real-in-practice, undocumented-by-the-provider at-least-one-of rule.

• 🔴 The scope of this resource is narrower than its name suggests, and that is the most important note here. The underlying Azure object has two apply-to flags — one for device connectivity to the IoT Hub and DPS, one for connectivity via the IoT Central web portal and REST APIs — and the provider hardcodes the second to false on every create and every update, exposes no argument for it, and never reads it back. So this rule set governs device traffic only, at every setting, and can never be evidence that operator or API access is restricted. Neither the schema nor the registry documentation shows this; it is visible only in the provider source, and Microsoft's IoT Central security baseline states the service-side consequence. It is emitted as the constant governs_device_traffic_only so a reader is told rather than left to infer.

• 🔴 apply_to_device = false is a switch, not a dial. With both flags false the rule set applies to no surface: default_action and every ip_rule entry are stored, returned by the API, shown in every plan, and evaluated against nothing. The provider recognises that exact combination internally as an unconfigured rule set. denies_all_access therefore takes apply_to_device into account — reporting a total lockout in the one state the provider itself treats as unconfigured would be precisely backwards — and rule_set_is_inert names the state so it can be asserted against.

• Duplicate rule names are rejected, and the difference from the above is the point. A duplicate name is not a judgement call: Microsoft documents the name as "a unique, case-insensitive" string, and the provider does no de-duplication of its own, so what a duplicate actually does is undefined rather than documented. That is a detectable mistake with one correct answer, which is exactly what a validation block is for — and the check states the vendor's requirement rather than guessing at the failure mode.

• 🔴 One validation here was narrower than the provider, and widening it was the fix. An earlier revision required an explicit /32 on a single address, reasoning that "rejecting a bare address costs nothing". The provider's validator makes the prefix optional and Microsoft documents "a single IPv4 address or a block in CIDR notation", so the rule refused legal input — and because a failed validation {} blocks terraform destroy as well as apply, it could have left a rule set created in the portal or by CLI both unmanageable and undestroyable through this module. Widening cannot reject anything the old rule accepted, which makes it the safe direction to correct in.

• Two constraints the schema hides are now mirrored, and one deliberately is not. The ip_rule.name charset and 128-character cap, and the IPv4-only ip_mask shape, are both real provider validators — and because a provider schema rule does not fire through a module boundary, mirroring them is a genuine lift from plan to the caller's own offline check rather than a duplicate. The 100-rule service cap is not mirrored: Microsoft documents it as raisable by support request, so enforcing it would refuse a supported configuration. It is reported through ip_rule_count_within_service_limit. A provider bound and a service bound are different things, and only one of them belongs in a validation {}.

• The three failure modes are independent, so they get separate outputs. rule_set_is_inert is "no control at all"; denies_all_access is an availability failure; permits_entire_internet is an exposure failure. A single "posture is wrong" boolean would conflate three different incidents, and no two of the three imply the third.

• permits_entire_internet checks the IPv4 form only, and that is complete rather than partial. The provider's validator has no IPv6 form at all and Microsoft states that IPv6 is not supported on IoT Hub or DPS, so ::/0 cannot reach this resource — a check for it would be dead code advertising a protection that has nothing to protect against.

• A locked-out fleet is hard to diagnose, which is why the availability output exists. Microsoft documents that a connection from an address that is not explicitly allowed receives an unauthorized 401 whose message does not mention the IP rule — so the first instinct is to suspect credentials and rotate keys, which cannot fix it. That is the reason the flag is emitted positively as applies_to_device_connectivity rather than left as a raw boolean.

• ip_rule is rendered from a canonical map keyed on the lowercased rule name, so the emitted block order does not depend on the caller's list order and a reordering produces no diff. Rejecting duplicate names is what makes that key safe — the two decisions depend on each other.

• The singleton nature is emitted as a constant true because it is silent. Azure identifies the rule set by its application, so two configurations managing one application's policy produce no name collision and no plan warning — just a policy that changes depending on which pipeline ran last.

• 🔴 The destroy semantics are documented as a widening, and there is no delete call at all. The provider reads the application, sets its network rule set to nothing, and PUTs the whole application model back — so a destroy is an update to the application wearing a destroy's clothes. Most destroys in this library remove something; this one removes a restriction, so unless the application's own public_network_access_enabled is false, devices may connect from anywhere afterwards. It is emitted as the constant destroy_removes_the_restriction, and it is also the argument for the sibling module's default.

• ⚠️ The whole-application PUT has two further consequences worth knowing. First, there is no rule-set sub-resource to scope an RBAC role to, so the grant that permits editing this allow-list also permits rewriting the application's display name, subdomain, template and public network access. Second, only the create path takes a lock: an update or a delete performs an unlocked read-modify-write of the entire application model, so a composition that edits the application and its rule set concurrently can have one write overwrite the other's fields. The dependency edge from iotcentral_application_id orders create and destroy; it does not order two in-place updates. It is also why all three write timeouts are budgeted at 30 minutes.

• ⚠️ Two adoption behaviours are counter-intuitive. A first apply against a never-configured application raises no "already exists" error and simply takes ownership, because the provider's duplicate-detection guard fires only when the existing rule set is not the allow-all triple — every application ships with a rule set already attached. And a rule set cleared out of band makes plan fail rather than propose a re-create, because the read returns an error instead of marking the resource gone.

• The universal tags tail is omitted, having been checked rather than assumed. The resource exposes no tags; policy attached to an application is not independently ownable.

• The RBAC section frames this as change control rather than access control, because no Azure role distinguishes "add one office range" from "permit the entire internet". The useful gate is a plan review of two named outputs.

• Before adopting: confirm exactly one configuration manages this application's rule set.
• Before applying an empty allow-list: it stops every device, and Azure will not warn you.
• Before setting Allow: the resource stops restricting anything. The fix is usually a missing range.
• Before setting apply_to_device = false: record why. It switches the allow-list off rather than narrowing it.
• Before relying on this to restrict operators or the REST API: it cannot, at any setting.
• Before destroying: this widens access, it does not narrow it.
• Before importing: plan and read it, or the first apply may remove ten live ranges.
• Before passing 100 rules: the service caps the filter there, and nothing offline will stop you.

terraform init -backend=false
terraform validate
terraform fmt -check

• Pin the source to a tag — ?ref=v1.0.0 — never a branch.
• Plan-only from here. A human applies from CI.
• ✅ default_action, apply_to_device and the whole ip_rule list update in place. Revising is cheap.
• 🔴 Only iotcentral_application_id is force-new.
• ⚠️ No propagation time is documented for a rule change — treat the window as unknown and non-zero, and sequence a re-addressing exercise as add-then-remove rather than as an edit.
• 🔴 A destroy widens access and issues no delete call, reverting to the application's own public-access setting. Use a CanNotDelete lock on the application where that matters.
• ⚠️ Import takes the application's ID, then plan before applying. A first apply against a never-configured application takes ownership silently, with no "already exists" error.
• ⚠️ terraform validate from this folder evaluates no variables, so none of the seven validation {} blocks fires here. It proves type-correctness. Use terraform console to exercise the conditions.
• 💡 Print rule_set_is_inert, denies_all_access and permits_entire_internet in the pipeline.

Three commands disagree about which of this module's validation {} blocks fire, so it is worth being precise about which one proves what.

So terraform validate and terraform fmt -check prove type-correctness, HCL validity, that the module declares no provider block, and that no output is sensitive and no secret is accepted. The variable rules are proved with terraform console, driven from a deliberately bad .tfvars. They confirm:

• iotcentral_application_id is an IoT Central Application Resource ID anchored to Microsoft.IoTCentral/iotApps/<name> with $, and correctly cased — a lower-cased /resourcegroups/ is refused, matching the provider's own case-sensitive parser;
• default_action is exactly Allow or Deny, case-sensitively;
• every ip_rule entry has a non-empty name, within the provider's charset and 128-character cap;
• no two ip_rule entries share a name, case-insensitively;
• every ip_mask is an IPv4 address with an optional /0-32 prefix, with an IPv6 value refused by name.

And the cases that must pass, driven as explicitly as the failures — because a widening is only real if the widened value is accepted:

• a bare 203.0.113.5 with no prefix, mixed freely with prefixed entries;
• 0.0.0.0/0, which is legal and reported rather than refused;
• a 128-character name, and a name using every legal special character in the mirrored class;
• 256.0.0.1 — an out-of-range octet the provider does not check either, deliberately left to Azure;
• an empty ip_rule list, which is legal and reported by denies_all_access;
• apply_to_device = false and default_action = "Allow", both legal and both reported;
• Go duration timeouts including 1h30m, 1.5h, 0 and 500ms.

💡 The pass cases matter as much as the failures. A harness of failures alone cannot distinguish a condition that correctly rejects bad input from one that rejects everything — and a boring valid baseline is what catches a condition that raises rather than fails.

What only plan and apply exercise:

• whether the application exists and the caller may modify it;
• the provider's own validators, which do not fire through a module boundary — which is exactly why the charset and shape rules above are mirrored here rather than left to the provider;
• 🔴 the 100-rule service cap and out-of-range octets, both of which Azure rejects at apply and this module deliberately reports rather than refuses.

What no Terraform command checks at any stage:

• 🔴 whether another configuration manages the same application's rule set — the silent overwrite;
• 🔴 whether the allow-list is complete, which is indistinguishable from a device fault when it is not;
• 🔴 whether the application's own public_network_access_enabled is false, which decides whether this allow-list is the primary control or a second layer;
• what the devices' real egress ranges are — the hard part of this resource.

Outputs:

applies_to_device_connectivity      = true
default_action                     = "Deny"
default_action_is_deny             = true
denies_all_access                  = false
destroy_removes_the_restriction    = true
every_rule_is_an_allow_rule        = true
governs_device_traffic_only        = true
id                                 = "/subscriptions/00000000-.../providers/Microsoft.IoTCentral/iotApps/iotc-plant-telemetry"
iotcentral_application_id          = "/subscriptions/00000000-.../providers/Microsoft.IoTCentral/iotApps/iotc-plant-telemetry"
ip_rule_count_within_service_limit = true
is_singleton_per_application       = true
permits_entire_internet            = false
permitted_cidrs                    = [
  "198.51.100.16/28",
  "198.51.100.32/28",
  "198.51.100.7",
]
permitted_cidrs_by_name            = {
  "gateway-uk" = "198.51.100.7"
  "plant-de"   = "198.51.100.32/28"
  "plant-uk"   = "198.51.100.16/28"
}
permitted_rule_count               = 3
rule_set_is_inert                  = false

🔴 rule_set_is_inert, denies_all_access and permits_entire_internet are all false — the three assertions, all healthy, and all three are needed (example 9).

🔴 governs_device_traffic_only = true is a scope statement, not a health check. It is always true, and it says the IoT Central web portal and REST API are not governed here at any setting.

⚠️ id and iotcentral_application_id are identical. That is not a copy-paste error in this document — it is the singleton behaviour of example 2, and the reason is_singleton_per_application is emitted.

✅ permitted_cidrs is sorted, so it diffs cleanly against another environment's output (example 6). Note 198.51.100.7 carries no prefix, which is legal: the CIDR prefix is optional (example 5).

ℹ️ No tags output, because the resource has none (example 7).

• azurerm_iotcentral_application_network_rule_set — provider documentation.
• azurerm_iotcentral_application — the application, and its own public_network_access_enabled of example 11.
• Restrict public access to an IoT Central application — the IoT Central side of this allow-list, including the warning to list the proxy's address where devices connect through one (examples 1 and 5).
• IoT Hub IP filtering — the underlying filter this rule set writes: the address formats, the unordered allow-rule semantics, the 401 a blocked device receives, and the empty-list-blocks-everything default.
• IoT Hub IP address limitations and DPS best practices — the 100-rule cap on each surface, and the statement that IPv6 is not supported on either.
• Azure security baseline for IoT Central — NS-2, which states that restricted connectivity covers device connections to the underlying hubs and DPS while the web UI and APIs continue to work through their public endpoints.
• IoT Central application security guide — where this rule set sits among the other controls, and the user, API-token and Entra controls that govern the surfaces this one cannot.
• Sibling modules: terraform-azurerm-iotcentral-application, terraform-azurerm-iotcentral-organization, terraform-azurerm-resource-group, terraform-azurerm-role-assignments.
• This module's SCOPE.md.

💙 "Infrastructure as Code should be standardized, consistent, and secure."