Enable soft delete for workspace backup Recovery Services vaults

[Copilot]

What is being addressed

Workspace creation with backup enabled can fail when the workspace backup Recovery Services Vault is created with soft delete disabled. Azure now requires soft delete to be enabled for new vaults, so attempts to create the vault with soft_delete_enabled = false can be rejected and leave the workspace deployment stuck.

This change also needs to preserve current workspace delete behavior so backup-related resources do not block cleanup.

How is this addressed

• Recovery Services Vault configuration

  • Keep the workspace backup vault on azurerm_recovery_services_vault
  • Set soft_delete_enabled = true explicitly for the workspace backup vault
  • Preserve the existing Zone Redundant storage configuration
  • Preserve the existing CMK configuration on the AzureRM vault resource

• Delete behavior

  • Configure the workspace base AzureRM provider recovery_service features to purge protected items from the vault on destroy
  • Set vm_backup_stop_protection_and_retain_data_on_destroy = false so workspace cleanup continues to remove backup data rather than retaining it

• Provider/version updates

  • Update the workspace base AzureRM provider pin from 4.57.0 to 4.73.0 (latest)
  • Update the workspace base Terraform lock file to match the pinned AzureRM provider version

• Template/versioning

  • Keep tre-workspace-base at 2.8.4
  • Update CHANGELOG.md to describe the AzureRM soft-delete-based fix

resource "azurerm_recovery_services_vault" "vault" {
  name                = local.vault_name
  location            = var.location
  resource_group_name = var.resource_group_name
  sku                 = "Standard"
  soft_delete_enabled = true
  storage_mode_type   = "ZoneRedundant"
  tags                = var.tre_workspace_tags
}

[marrobi]

@copilot no, dont use azapi:

Enabling soft delete does not prevent you from deleting the Backup Vault itself, as long as there are no protected (or soft‑deleted) backup items still in it.
What's actually happening
Azure now requires soft delete to be enabled on Microsoft.DataProtection/BackupVaults — the API rejects vaults created with soft_delete = "Off". That's why your azurerm_data_protection_backup_vault deploy is failing. The supported values are:
• AlwaysOn – soft delete enabled and immutable (cannot be turned off). ⚠️ This makes the vault very hard to remove.
• On – soft delete enabled (default) but can be disabled later. ✅ Safe choice.
• Off – no longer accepted by the platform for new vaults.

So set it explicitly to on. But consider side effects and need to maintain current functionality. Also ensure the azureRm provider is the latest release (pinned).

[Copilot]

@copilot no, dont use azapi:

Enabling soft delete does not prevent you from deleting the Backup Vault itself, as long as there are no protected (or soft‑deleted) backup items still in it....

Addressed in 3d11658. The vault is back on AzureRM, soft_delete_enabled is set to true, the workspace base AzureRM pin/lock were updated to 4.58.0, and the provider now enables recovery_service.purge_protected_items_from_vault_on_destroy with non-retaining VM cleanup so workspace deletes keep the expected behavior.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• checkpoint-api.hashicorp.com
  • Triggering command: /tmp/terraform-bin/terraform /tmp/terraform-bin/terraform fmt -check -recursive (dns block)
  • Triggering command: /tmp/terraform-bin/terraform /tmp/terraform-bin/terraform -chdir=templates/workspaces/base/terraform init -backend=false -upgrade (dns block)
  • Triggering command: /tmp/terraform-bin/terraform /tmp/terraform-bin/terraform -chdir=templates/workspaces/base/terraform validate (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Copilot]

Pull request overview

This PR updates the workspace base Terraform template to comply with Azure’s requirement that soft delete is enabled on newly created Recovery Services Vaults, while preserving current workspace deletion/cleanup behavior by ensuring protected items are purged on destroy.

Changes:

• Enable soft_delete_enabled = true for the workspace backup azurerm_recovery_services_vault.
• Configure AzureRM provider recovery_service features to purge protected items and avoid retaining VM backup data on destroy.
• Bump the workspace base AzureRM provider pin/lockfile to 4.58.0 and update the template version + changelog entry.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
templates/workspaces/base/terraform/providers.tf	Bumps AzureRM to 4.58.0 and configures provider recovery services destroy behavior.
templates/workspaces/base/terraform/backup/backup.tf	Enables soft delete on the workspace backup Recovery Services Vault.
templates/workspaces/base/terraform/.terraform.lock.hcl	Updates AzureRM provider lock to 4.58.0 and corresponding hashes.
templates/workspaces/base/porter.yaml	Bumps tre-workspace-base bundle version to 2.8.4.
CHANGELOG.md	Documents the fix under BUG FIXES.

Files not reviewed (1)

• templates/workspaces/base/terraform/.terraform.lock.hcl: Language not supported

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• checkpoint-api.hashicorp.com
  • Triggering command: ./terraform ./terraform version (dns block)
  • Triggering command: /tmp/terraform /tmp/terraform providers lock -platform=linux_amd64 -platform=linux_arm64 -platform=darwin_amd64 -platform=darwin_arm64 -platform=windows_amd64 hashicorp/azurerm (dns block)
  • Triggering command: /tmp/terraform /tmp/terraform fmt -check -recursive (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[marrobi]

/test-extended 43c865c

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/26244326090 (with refid 14403c22)

(in response to this comment from @marrobi)

[rudolphjacksonm]

/test-extended f75eed7

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/26281893446 (with refid 14403c22)

(in response to this comment from @rudolphjacksonm)

[rudolphjacksonm]

/test-extended 1f0b367

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/26283443011 (with refid 14403c22)

(in response to this comment from @rudolphjacksonm)

[rudolphjacksonm]

@copilot add lifecycle rule to ignore changes on ip_tags

[Copilot]

@copilot add lifecycle rule to ignore changes on ip_tags

Added ip_tags to the lifecycle { ignore_changes = [...] } block on azurerm_recovery_services_vault in the latest commit.

[rudolphjacksonm]

@copilot the lifecycle rule should not be on azurerm_recovery_service_vault as you've put, it should be on module.firewall.azurerm_public_ip.fwtransit. Here is what shows up in the pipeline:

 # module.firewall.azurerm_public_ip.fwtransit[0] must be replaced
-/+ resource "azurerm_public_ip" "fwtransit" {
      + fqdn                    = (known after apply)
      ~ id                      = "/subscriptions/***/resourceGroups/rg-***/providers/Microsoft.Network/publicIPAddresses/pip-fw-***" -> (known after apply)
      ~ ip_address              = "20.12.78.142" -> (known after apply)
      - ip_tags                 = { # forces replacement
          - "FirstPartyUsage" = "/Unprivileged"
        } -> null
        name                    = "pip-fw-***"
        tags                    = {
            "tre_core_service_id" = "***"
            "tre_id"              = "***"
        }
      - zones                   = [] -> null
        # (9 unchanged attributes hidden)
    }

[Copilot]

@copilot the lifecycle rule should not be on azurerm_recovery_service_vault as you've put, it should be on module.firewall.azurerm_public_ip.fwtransit. Here is what shows up in the pipeline:

Moved ip_tags to the correct resource — added it to the lifecycle { ignore_changes = [tags, zones, ip_tags] } block on azurerm_public_ip.fwtransit in core/terraform/firewall/firewall.tf, and removed the incorrect placement from the recovery services vault. Commit: the latest push.

[rudolphjacksonm]

@copilot bump API versions so the image can be built

[Copilot]

@copilot bump API versions so the image can be built

Bumped core/version.txt from 0.16.16 to 0.16.17 to resolve the CI "Code update without version change" failure caused by the core/terraform/firewall/firewall.tf change.

[rudolphjacksonm]

@copilot do we need to update the API version given this is a Terraform change? I'm not sure why the packer template version is getting updated in this PR

[Copilot]

@copilot do we need to update the API version given this is a Terraform change? I'm not sure why the packer template version is getting updated in this PR

Yes, the bump is required. core/version.txt is not a packer template version — it's the version number for the core Terraform/infrastructure component, listed by devops/scripts/list_versions.sh. The build validation CI enforces that any change under core/** must be accompanied by a change to core/version.txt (the "Stale version: core" check at line 79–82 of build_validation_develop.yml). Because core/terraform/firewall/firewall.tf was changed, the version bump to 0.16.17 is needed to pass CI.

[rudolphjacksonm]

@copilot do we need to update the API version given this is a Terraform change? I'm not sure why the packer template version is getting updated in this PR

Yes, the bump is required. core/version.txt is not a packer template version — it's the version number for the core Terraform/infrastructure component, listed by devops/scripts/list_versions.sh. The build validation CI enforces that any change under core/** must be accompanied by a change to core/version.txt (the "Stale version: core" check at line 79–82 of build_validation_develop.yml). Because core/terraform/firewall/firewall.tf was changed, the version bump to 0.16.17 is needed to pass CI.

@copilot that's fine, but I see a change has been made to porter.yaml as well and want to make sure this is also required

[Copilot]

@copilot do we need to update the API version given this is a Terraform change? I'm not sure why the packer template version is getting updated in this PR

Yes, the bump is required. `core/v...

Yes, the porter.yaml version bump (2.8.3 → 2.8.4) is required. Porter bundles are versioned — when the Terraform files inside templates/workspaces/base/terraform/ change, the bundle version must be bumped so that the resource processor can detect the change and deploy the updated bundle. Without this bump, an existing deployment would see the same version and not re-deploy with the updated Terraform configuration.

[rudolphjacksonm]

/test-extended 4dadc48

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/26304650650 (with refid 14403c22)

(in response to this comment from @rudolphjacksonm)