Prerequisites

Prerequisites

What must exist before terraform apply can succeed. Everything here is implied by the module code — a missing item shows up as a plan or apply error, not as a warning.

Tools

Tool	Constraint	Why
Terraform	1.7 or later (versions.tf declares >= 1.5)	main.tf contains a removed block, which Terraform 1.7 introduced, and resource preconditions
Azure CLI	any recent version	A null_resource provisioner shells out to az ad app update on every apply (a second one when enable_oidc_api is true), and the CLI login is the default credential source

The azurerm provider is pinned to ~> 4.33, azuread to ~> 2.0, plus random ~> 3.1 and null ~> 3.1. The auth module additionally requires time ~> 0.9 and narrows azuread to ~> 2.47.

Azure identity and permissions

The apply principal needs, at minimum:

• Contributor on the target resource group, to create everything in Resources.
• Rights to create role assignments in that resource group. The identity, containers and key_vault modules all create azurerm_role_assignment resources, which requires User Access Administrator or an equivalent custom role.
• Application Administrator (or equivalent) in Entra ID. The auth module creates an application, a service principal, a client secret, and app role assignments through the azuread provider.
• If you set function_app_external_secret_vault_ids, rights to create role assignments at each of those vault scopes as well — which owning this resource group does not imply.

The azurerm provider takes subscription_id from var.subscription_id, which defaults to null. Left unset, the provider falls back to ARM_SUBSCRIPTION_ID or the CLI's current subscription. Nothing in the module hardcodes a subscription.

Things you create first

The resource group

main.tf reads the resource group with a data source:

data "azurerm_resource_group" "rg" {
  name = var.resource_group_name
}

It is never created and never destroyed by this module. Create it yourself, and note that every module gets its location from this data source — the root location variable is declared but not consumed anywhere in main.tf.

az group create --name rg-reportmate-prod --location canadacentral

The Terraform state backend

versions.tf declares backend "azurerm" {} with no arguments, so init fails without a backend config. See State-and-Backends.

The Entra ID application you sign in with

azure_ad_client_id and azure_ad_tenant_id are required inputs with no defaults. They are the client id and tenant of the app registration the dashboard authenticates against, and they are consumed by the containers and key_vault modules. Note that the auth module also creates an app registration; the two are not automatically the same object. See Troubleshooting.

A container registry, or a registry hostname

Two inputs cover this and both are required:

• container_registry_name — the ACR name. Only used when use_custom_registry = true; otherwise it is still required but inert.
• existing_registry_server — the registry hostname the container apps pull from when use_custom_registry = false.

The images themselves must already be pushed. This module never builds one.

A DevOps/administration group

devops_resource_infrasec_group_object_id is required with no default. It is granted Key Vault Administrator on the vault and stored as a vault secret. Pass the object id of whichever Entra group should administer the vault.

Secrets you supply

Input	Notes
db_password	PostgreSQL administrator password
api_internal_secret	Shared secret the dashboard sends to the API on internal calls
key_vault_name	Globally unique, 3–24 letters, digits and hyphens
allowed_domains	Comma-separated sign-in domains. Required deliberately: an empty value makes the app permit every domain

Keep these in a gitignored terraform.tfvars — *.tfvars is ignored by the repo's .gitignore, and terraform.tfvars.example is committed as a template.

DNS, only if you want a custom domain

Setting enable_custom_domain = true with a custom_domain_name creates a Front Door profile and a managed-certificate custom domain. You then have to create two DNS records in your own zone — a CNAME to the Front Door endpoint and a _dnsauth TXT record carrying the validation token. The networking module sets dns_zone_id = null, so it does not manage the zone for you.