☁️ Azure Backup Resource Guard Terraform Module

Manages one azurerm_data_protection_resource_guard — the object that puts a Backup vault's destructive operations under multi-user authorisation. Targets hashicorp/azurerm ~> 4.0.

• 🎯 Creates one Backup resource guard.
• 🛡️ Requires a second party to approve destructive vault operations — disabling soft delete, reducing retention, deleting backup data.
• 🔻 Its one interesting argument is an exclusion list: every entry removes protection. The default is an empty list, which protects everything.
• 🧊 Three force-new fields, and two of them are invisible to a grep of the provider's resource file.
• 🏷️ Carries real Azure tags — unlike most of the Data Factory resources alongside it in this library.
• ⏱️ timeouts.update is accepted and ignored; create bounds an update.

💡 Why it matters: a resource guard is an organisational control wearing a technical shape. It only means anything when the person who can approve a destructive operation is not the person requesting it — which means putting the guard in a different subscription, under different administrators, from the vaults it protects. Azure does not require that, and nothing here enforces it. Two failure modes are entirely silent: the guard protects nothing until a vault references it, and an entry in the exclusion list is a hole in the control, not an addition to it.

If this module saves you time:

• ⭐ Star the repository
• 💼 Connect on LinkedIn
• ☕ Buy me a coffee

flowchart TB
  RG["azurerm_resource_group, ideally a DIFFERENT subscription"]
  GUARD["data_protection_resource_guard"]
  VAULT["azurerm_data_protection_backup_vault"]
  OPS["critical operations: disable soft delete, reduce retention, delete backup data"]
  EXCL["vault_critical_operation_exclusion_list REMOVES protection"]

  RG -->|"resource_group_name and location, both FORCE-NEW via commonschema"| GUARD
  VAULT -.->|"the VAULT references the guard by id, not the other way round"| GUARD
  GUARD -->|"requires a second approver for"| OPS
  EXCL -.->|"each entry is a HOLE in that protection"| GUARD

  classDef me fill:#0078D4,stroke:#004578,color:#ffffff
  classDef key fill:#004578,stroke:#002b47,color:#ffffff
  classDef ext fill:#F0F3F6,stroke:#9AA5B1,color:#1F2933
  class GUARD me
  class VAULT key
  class RG,OPS,EXCL ext

Note the direction: the vault references the guard, not the other way round. Nothing here records which vaults use it, or whether any do.

flowchart TB
  VN["name, resource_group_name, location -- THREE force-new, two hidden by commonschema"]
  VE["vault_critical_operation_exclusion_list -- an EXCLUSION list"]
  VT["tags -- this resource really has them"]
  R["azurerm_data_protection_resource_guard.this"]
  EMPTY["EMPTY list is the strongest posture"]
  OID["id, name, location"]
  OFLAG["protects_every_critical_operation, excluded_operation_count"]
  OWARN["this_guard_protects_nothing_until_a_vault_references_it"]

  VN --> R
  VE --> R
  VT --> R
  VE -->|"default"| EMPTY
  R --> OID
  R --> OFLAG
  R --> OWARN

  classDef me fill:#0078D4,stroke:#004578,color:#ffffff
  classDef key fill:#004578,stroke:#002b47,color:#ffffff
  classDef ext fill:#F0F3F6,stroke:#9AA5B1,color:#1F2933
  class R key
  class EMPTY me
  class VN,VE,VT,OID,OFLAG,OWARN ext

Schema notes that bite — each verified against the provider source at the pinned line:

• 🔴 timeouts.update is accepted and ignored. The timeouts block declares all four keys, but the create-and-update function asks for ForCreate — so create bounds an update.
• 🔴 Two of the three force-new fields are invisible to a grep. The resource file has exactly one ForceNew: true; resource_group_name and location get theirs from shared commonschema helpers.
• location is normalised — "East US" and "eastus" never diff against each other.
• The name validator checks two things only: non-empty, and at most 260 characters. No pattern, no character set.
• Nothing validates the operation names in the exclusion list beyond non-emptiness — a misspelling excludes nothing, silently, in the safe direction.
• This resource genuinely has tags.
• No CustomizeDiff, no version gate.

🔴 Granting the approver role on the guard to the same identity that administers the vault defeats the control entirely. The apply succeeds, the guard exists, every audit view shows multi-user authorisation enabled, and one person can still do everything. Nothing in Terraform or in Azure warns about this — it is the single most important thing to get right about this resource, and it is not expressible in configuration.

• The Microsoft.DataProtection resource provider registered in the subscription holding the guard.
• An existing resource group.
• A Backup vault that references this guard, created separately. The guard is inert without one.
• Separate administrators. Not a technical prerequisite, but without it the guard provides very little.

terraform-azurerm-data-protection-resource-guard/
├── providers.tf    # required_version + the pinned azurerm; no provider block
├── variables.tf    # 6 typed inputs, 8 validations, the universal tags tail
├── main.tf         # locals + the single keystone resource
├── outputs.tf      # 22 outputs; id first, then name, then the derived facts
├── README.md       # this file
├── SCOPE.md        # the cross-module contract
├── LICENSE         # MIT
└── .gitignore

provider "azurerm" {
  features {}
}

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

  name                = "rg-backup-guard"
  resource_group_name = "rg-backup-guard-eastus"
  location            = "eastus"

  # No exclusions: every critical operation stays protected.
}

🛡️ The empty call is the strongest posture. Leaving vault_critical_operation_exclusion_list unset protects every critical operation — protects_every_critical_operation reports true at plan.

⚠️ The guard does nothing until a Backup vault references its id.

Consumes

Emits

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

  name                = "rg-backup-guard"
  resource_group_name = "rg-backup-guard-eastus"
  location            = "eastus"
}

# The guard is created by a DIFFERENT provider alias, pointed at a
# subscription the vault operators do not administer. That separation is what
# makes multi-user authorisation meaningful; putting the guard beside the
# vault is legal, applies cleanly, and protects very little.

provider "azurerm" {
  alias           = "security"
  subscription_id = var.security_subscription_id
  features {}
}

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

  providers = {
    azurerm = azurerm.security
  }

  name                = "rg-backup-guard"
  resource_group_name = "rg-security-eastus"
  location            = "eastus"

  tags = {
    purpose = "backup-mua"
    owner   = "security"
  }
}

module "guard_with_hole" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-protection-resource-guard.git?ref=v1.0.0"

  name                = "rg-backup-guard"
  resource_group_name = "rg-security-eastus"
  location            = "eastus"

  # EVERY ENTRY HERE REMOVES PROTECTION FROM THAT OPERATION.
  vault_critical_operation_exclusion_list = [
    "Microsoft.RecoveryServices/vaults/backupconfig/write",
  ]
}

module "typo" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-protection-resource-guard.git?ref=v1.0.0"

  name                = "rg-backup-guard"
  resource_group_name = "rg-security-eastus"
  location            = "eastus"

  vault_critical_operation_exclusion_list = ["ThisIsNotARealOperation"]
}

module "no_duplicates" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-protection-resource-guard.git?ref=v1.0.0"

  name                = "rg-backup-guard"
  resource_group_name = "rg-security-eastus"
  location            = "eastus"

  # This is REFUSED -- "OpA" and "opa" are the same exclusion.
  # vault_critical_operation_exclusion_list = ["OpA", "opa"]

  vault_critical_operation_exclusion_list = ["OpA"]
}

module "loose_location" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-protection-resource-guard.git?ref=v1.0.0"

  name                = "rg-backup-guard"
  resource_group_name = "rg-security-eastus"
  location            = "East US" # same as "eastus" -- no diff between them
}

module "tagged" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-protection-resource-guard.git?ref=v1.0.0"

  name                = "rg-backup-guard"
  resource_group_name = "rg-security-eastus"
  location            = "eastus"

  tags = {
    purpose     = "backup-mua"
    owner       = "security"
    cost-centre = "1234"
  }
}

module "patient" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-protection-resource-guard.git?ref=v1.0.0"

  name                = "rg-backup-guard"
  resource_group_name = "rg-security-eastus"
  location            = "eastus"

  timeouts = {
    create = "45m" # <-- this bounds an UPDATE as well
    read   = "10m"
    update = "45m" # <-- accepted, stored, never read
    delete = "45m"
  }
}

output "guard_review" {
  value = {
    protects_everything = module.guard.protects_every_critical_operation
    holes               = module.guard.excluded_operations
    hole_count          = module.guard.excluded_operation_count
    replace_on          = module.guard.force_new_fields
    update_bounded_by   = module.guard.the_timeout_that_actually_bounds_an_update
  }
}

check "guard_has_no_holes" {
  assert {
    condition     = module.guard.protects_every_critical_operation
    error_message = "The resource guard excludes one or more critical operations from protection."
  }
}

# THREE fields are force-new: name, resource_group_name and location.
# Two of them do not appear as ForceNew in the provider's resource file at all
# -- they come from shared commonschema helpers -- so an audit that greps the
# resource will count one and miss two.
#
# Replacing the guard silently removes multi-user authorisation from every
# vault that referenced it, because nothing in Terraform records which vaults
# those are. That is a security control disappearing with no plan-time signal.

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

  name                = "rg-backup-guard"
  resource_group_name = "rg-security-eastus"
  location            = "eastus"
}

provider "azurerm" {
  features {}
}

provider "azurerm" {
  alias           = "security"
  subscription_id = var.security_subscription_id
  features {}
}

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

  providers = {
    azurerm = azurerm.security
  }

  name     = "rg-security-eastus"
  location = "eastus"
}

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

  providers = {
    azurerm = azurerm.security
  }

  name                = "rg-backup-guard"
  resource_group_name = module.security_resource_group.name
  location            = module.security_resource_group.location

  tags = {
    purpose = "backup-mua"
    owner   = "security"
  }
}

output "resource_guard_id" {
  value = module.guard.id
}

Required: name, resource_group_name, location.

Optional: vault_critical_operation_exclusion_list, tags, timeouts.

Nothing is sensitive: this resource carries no credential.

The control is organisational and the resource is only its shape. A resource guard means something when the approver is not the requester. That requires putting it in a different subscription under different administrators — which Azure does not require and this module cannot check. Granting the approver role to the vault's own administrator produces a guard that exists, appears in every audit view as multi-user authorisation enabled, and stops nothing.

The one interesting argument runs backwards. vault_critical_operation_exclusion_list is an exclusion list: each entry removes protection. The module therefore emits protects_every_critical_operation — phrased positively, because this suite states negated security fields positively as a rule and double negatives are where security reviews go wrong — plus a constant output whose only job is to say the direction out loud.

The guard protects nothing until a vault references it. The association is made on the vault side, so nothing here records which vaults use this guard, or whether any do. That asymmetry also makes destruction dangerous: removing the guard, or changing any force-new field, silently strips multi-user authorisation from every vault that pointed at it, with no plan-time signal.

Two of the three force-new fields are invisible to a grep. The resource file contains exactly one ForceNew: true. resource_group_name and location are built from shared commonschema helpers, and it is the helpers that carry it. Anyone auditing this resource by searching it for ForceNew will count one field and miss two — and the same pattern applies across most of this provider, which is why the module names it rather than merely handling it.

timeouts.update is accepted and ignored. The block declares all four keys; the create-and-update function asks for ForCreate. So create bounds an update. This is the third distinct form of this defect found in this library, and the managed private endpoint module is the well-behaved contrast — no update function, no update timeout declared, key rejected outright.

features {} dependence. As with every module in this suite, the caller supplies provider "azurerm" { features {} } — and for the cross-subscription pattern, an aliased provider.

Two rules govern the validations. Never invent a constraint that could reject legal input — a validation {} failure blocks terraform destroy as well as apply, which is why neither operation names nor location spellings are enforced. And enforce a configuration rule, report a service or organisational one — duplicates are refused; the posture, the inertness and the approver-separation question are reported.

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

Pin the module with ?ref=v1.0.0 — never a branch. This module is plan-only; a human applies from CI.

Know which command reaches which check. terraform validate on a configuration that CALLS this module checks types and syntax only: it evaluates none of the module's variable values. The 8 validation {} blocks are reached at terraform plan, and none of them needs credentials, because variable validation runs before the provider is configured. To exercise them without a plan, run the module as the root module and drive it through terraform console -var-file=....

What no Terraform stage exercises: whether an operation name in the exclusion list is real, whether any Backup vault references this guard, and — most importantly — whether the approver and the requester are actually different people. None of those has a Terraform signal at any stage.

$ terraform output
id                                = "/subscriptions/.../resourceGroups/rg-security-eastus/providers/Microsoft.DataProtection/resourceGuards/rg-backup-guard"
name                              = "rg-backup-guard"
resource_group_name               = "rg-security-eastus"
location                          = "eastus"
protects_every_critical_operation = true
excluded_operation_count          = 0
excluded_operations               = []
force_new_fields                  = ["name", "resource_group_name", "location"]
the_timeout_that_actually_bounds_an_update = "create"
tags                              = { "owner" = "security", "purpose" = "backup-mua" }

• azurerm_data_protection_resource_guard
• azurerm_data_protection_backup_vault
• Microsoft Learn — Multi-user authorisation using Resource Guard
• Sibling modules: terraform-azurerm-resource-group, terraform-azurerm-data-factory-managed-private-endpoint
• This module's SCOPE.md

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