feat(agent): Workload Identity for Azure, with Service Principal fallback

[gdrojas]

Summary

Adds opt-in Workload Identity support to nullplatform/agent. Mirrors the WI / SP toggle pattern from PR #361 (cert_manager, external_dns), but defaults to Service Principal so existing Azure callers keep working without any code change.

Behavior

azure_workload_identity_enabled	What's required	What the agent's SA / pod get
false (default — current behavior)	azure_client_secret	No WI annotations or pod labels
true (opt-in)	azure_federated_credential_id (pass module.iam_*.id)	azure.workload.identity/client-id on the SA + azure.workload.identity/use=true on the pod

In WI mode, AZURE_CLIENT_SECRET is dropped from the agent's Helm Secret entirely. The Azure WI webhook injects AZURE_FEDERATED_TOKEN_FILE, AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_AUTHORITY_HOST into the pod at runtime; any future script that uses Azure SDK with DefaultAzureCredential authenticates automatically.

Why opt-in (different from #361)

cert_manager and external_dns (#361) defaulted to WI = true because they were less deeply deployed and the WI annotation is functionally required (those services actually call Azure SDK).

nullplatform/agent has more existing callers and the SP credentials are currently dead weight at runtime: endpoint-exposer uses kubectl only, and the azure-cosmos-db service script that would need Azure auth has the SP block commented out (it expects ARM_* env vars, not AZURE_*). Defaulting WI = true would have broken every existing caller at plan time without unblocking any active code path.

Migration path

To migrate to WI (recommended when you set up a new cluster):

 module "agent" {
   # ...
-  azure_client_secret           = var.azure_client_secret
+  azure_workload_identity_enabled = true
+  azure_federated_credential_id   = module.iam_agent.id
+  azure_client_id                 = module.iam_agent.client_id  # was var.azure_client_id (SP); now UAMI client_id
 }

You also need an infrastructure/azure/iam module instance to create the federated identity credential for the agent's SA:

module "iam_agent" {
  source               = "git::https://github.com/nullplatform/tofu-modules.git//infrastructure/azure/iam?ref=v1.56.1"
  name                 = "agent-${local.cluster_name}"
  resource_group_name  = module.resource_group.resource_group_name
  location             = var.location
  oidc_issuer_url      = module.aks.oidc_issuer_url
  namespace            = "nullplatform-tools"
  service_account_name = "nullplatform-agent"
  role_definition_name = "Reader"   # adjust to whatever Azure perms the agent's services need
  scope                = "/subscriptions/${var.azure_subscription_id}/resourceGroups/${module.resource_group.resource_group_name}"
  depends_on           = [module.aks]
}

[davidf-null]

The agent doesn't have an SDK or CLI, so what would we use the identity workload for?

[gdrojas]

Closing without merging.

Discussion with the team (cred. David Fernandez) clarified that the agent's Azure client_secret requirement is purely vestigial: it was originally consumed by an in-agent curl against the Azure DNS API, but that code path was already moved out to external-dns (which has WI auth via #361). The agent no longer makes any active Azure API call in its current workflows, so there is no runtime consumer for the WI plumbing this PR would add.

Net result: the PR would be infrastructure without a consumer. Closing now to keep main lean; if a future workflow brings Azure auth back into the agent (e.g., active use of nullplatform/services/databases/azure-cosmos-db with azurerm provider configured for WI), a more targeted PR can be opened then with concrete usage in scope.

End-to-end validation done during this work (WI annotation on SA, federated token exchange against Microsoft Entra, ARM API call via the token, opt-in/opt-out toggle) is preserved in this PR's history for reference.

Branch feat/agent-azure-wi-support left intact in case someone wants to resurrect this.