fix(iac/azure): cleanup-function and AKS grant Key Vault access the RBAC-enabled vault ignores #1621

Reviewed commit: be11bdcb5. Note: origin/main moved to 3e9660d06 during the review; re-verify against current main before changing code, since a finding may have been fixed or moved.

Blast radius: our own hosted infrastructure. Failure is a runtime outage on the Azure deployment path, not customer exposure.

Where

• terraform/modules/compute/azure/cleanup-function/main.tf:31-40 (azurerm_key_vault_access_policy)
• terraform/modules/compute/azure/aks/main.tf:105-114 (azurerm_key_vault_access_policy)
• terraform/modules/secrets/azure/main.tf:39 (enable_rbac_authorization = true on the vault these target)
• Consumers that do it correctly: terraform/modules/compute/azure/container-apps/main.tf:309, container-apps/scheduled-tasks.tf:439-461, terraform/modules/secrets/azure/main.tf:295-301

What

The vault this project provisions sets enable_rbac_authorization = true (secrets/azure/main.tf:39). An RBAC-enabled Key Vault ignores access policies entirely: data-plane authorization comes from Azure RBAC role assignments only, and the accessPolicies array on the vault is not consulted.

The Azure cleanup function and the AKS workload identity both grant themselves access with azurerm_key_vault_access_policy. Terraform applies these resources successfully because the control plane accepts the write; the data plane does not honour it. Every other consumer in this repo already uses azurerm_role_assignment, so the correct pattern exists in-tree and simply was not applied to these two.

Failure scenario

terraform apply reports success with no warning. Then:

• The Azure cleanup function 403s on every attempt to read db-password at runtime, so expired sessions and stuck executions are never cleaned up. Nothing alarms, because the cleanup job's failure is not itself monitored.
• The AKS workload identity likewise cannot read any secret from the vault, so any pod depending on it fails at startup or at first secret fetch.

The whole failure mode is invisible at plan and apply time and only surfaces as runtime 403s, which is the worst possible place to discover it.

Fix direction

Replace both azurerm_key_vault_access_policy resources with:

resource "azurerm_role_assignment" "..." {
  scope                = var.key_vault_id
  role_definition_name = "Key Vault Secrets User"
  principal_id         = <identity principal id>
}

Then add a repo guard: grep for azurerm_key_vault_access_policy in CI and fail, since the project's vault is RBAC-enabled by design and no correct use of an access policy exists here. Note that role assignments need propagation time; see the related depends_on finding.

Related

• The grouped medium/low issue from this review carries the adjacent finding that azurerm_key_vault_secret writes in terraform/modules/secrets/azure/main.tf:71-83 depend on a role assignment without waiting for RBAC propagation (project memory feedback_tf_depends_on_rbac). Fixing this issue by switching to role assignments makes that propagation concern apply to these two modules as well.
• sec(iac): onboarding paths drift - shell/CFN/ARM templates lack the guards their Terraform siblings enforce cloud-commitments-platform#91 (sec(iac): onboarding paths drift) is the same "one path was hardened, its siblings were not" shape on a different axis.