sec(iac/azure): ACR admin credentials are used for pulls, leaving the AcrPull grant dead

[cristim]

Summary

The hosted Azure environment sets admin_enabled = true on the container registry, reads admin_username / admin_password off the resource, and hands them to the container-apps module, which materialises the password as a secret block on azurerm_container_app.main and authenticates pulls with it. The same file grants the Container App's managed identity AcrPull, so the workload could pull with no credential at all; that role assignment governs no pull today and could be deleted with no observable change. The result is a long-lived push-capable registry credential sitting in Terraform state (on both the registry resource and the container app) and in the ARM resource definition, readable by anyone with Reader on the resource group. The reusable modules/registry/azure defaults enable_admin_user = false; the environment declares its own registry resource and overrides that. Blast radius is our own hosted infrastructure.

Location

• terraform/environments/azure/registry.tf:10 at 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd (admin_enabled = true)
• terraform/environments/azure/registry.tf:16-21 (the unused AcrPull assignment)
• terraform/environments/azure/compute.tf:101-103 (registry_username / registry_password passed into the module)
• terraform/modules/compute/azure/container-apps/main.tf:88-96 (registry block uses username + password_secret_name, never identity)
• terraform/modules/compute/azure/container-apps/main.tf:224-230 (the password as a container-app secret)

Failure scenario

A principal with Reader on the resource group, or read access to the Terraform state backend, reads the ACR admin password. Because the admin account has push as well as pull, they can replace the image the Container App runs. Separately, revoking the managed identity's AcrPull changes nothing, so an operator auditing access sees a least-privilege grant that is not the one in use.

Evidence

resource "azurerm_container_registry" "main" {
  name                = local.acr_name
  sku                 = "Basic"
  admin_enabled       = true # Enables username/password login for docker push
}

resource "azurerm_role_assignment" "acr_pull" {
  scope                = azurerm_container_registry.main.id
  role_definition_name = "AcrPull"
  principal_id         = module.compute_container_apps[0].managed_identity_principal_id
}

registry_server   = azurerm_container_registry.main.login_server
registry_username = azurerm_container_registry.main.admin_username
registry_password = azurerm_container_registry.main.admin_password

Suggested fix

Set admin_enabled = false, drop the three registry_* inputs at compute.tf:101-103, and give the Container App a registry { server = ..., identity = <UAMI id> } block so the pull runs on the existing AcrPull assignment. Add depends_on = [azurerm_role_assignment.acr_pull] on the container app so the first pull does not race RBAC propagation (LeanerCloud/cloud-commitments-cli#1627 already tracks the same ordering hazard for the sibling assignments, finding A13c-006). If CI still pushes with the admin account, move that push to the deploy SP's own AcrPush assignment first.

Related: #127 notes in passing that registry_login_command carries this same admin credential.

---

Found by the 2026-09-02 codebase audit, finding A13c-005, reported by one reviewer and independently confirmed by a second. Full report: docs/audits/codebase-audit-2026-09-02.md. Finding A13-010 (the dead AcrPull assignment) is the same defect seen from the other side and is folded in here.

[cristim]

Verified against current main (7a541dae919249c6d360d432d1f1cdc6b34cef9e): fully fixed.

• terraform/environments/azure/registry.tf:10: admin_enabled = false (was true).
• The registry_username/registry_password inputs into compute.tf are gone; compute.tf:100-102 passes only registry_server and container_registry_id.
• terraform/modules/compute/azure/container-apps/main.tf:89-91: the registry block on azurerm_container_app.main now authenticates with identity = azurerm_user_assigned_identity.container_app.id, not a password secret.
• The previously-dead AcrPull assignment is no longer dead: main.tf:249-253 grants it to the container app's managed identity and it's the pull path actually in use, with depends_on = [azurerm_role_assignment.acr_pull] on azurerm_container_app.main (main.tf:227) to avoid racing RBAC propagation — exactly the ordering hazard the issue flagged.
• CI's push side also moved off the admin account: terraform/environments/azure/build.tf:24 grants AcrPush to an identity rather than reusing the registry admin password.

Fixed by merged PR #5 (sec(iac/azure): pull and push ACR with Entra identities, disable the admin account, merge commit b3279fd420ca78afd4cde6ccd64df6ecfd4b8ca2).

Closing as completed; no residual work.