Decouple deploy runner authority from VM lifecycle

[dotnetpower]

Issue #280 cannot safely complete blue/green replacement while the deploy principal is the current VM's system-assigned identity and platform/scenario Terraform grants roles to the active deployer object. Cloning all 15 current assignments propagates authority drift; cloning only bootstrap baseline breaks plan/apply capabilities.

Exit criteria

• Bootstrap provisions one user-assigned deploy identity with an explicit stable role manifest and attaches it to the active and candidate runner VMs during transition.
• Every protected fdai-deploy workflow authenticates with the configured deploy identity client ID and verifies the expected tenant, subscription, and principal before privileged work.
• Existing platform, bootstrap, and scenario state-owned role assignments migrate to the stable deploy identity through reviewed zero-unrelated-destroy plans; temporary grants retain bounded grant/revoke behavior.
• A Standard_D4ds_v5 candidate with Local ResourceDisk ephemeral OS registers five candidate-only slots and passes protected-source checkout, managed-identity login, private state access, and plan-only preflight.
• Cutover changes the five canonical fdai-deploy slots only after candidate verification, then removes the old registrations, VM, NIC, and managed OS disk with rollback evidence.
• Scheduled infra-drift reports zero runner storage/identity drift and issue Resize and restore the FDAI deploy runner #280 exit criteria are all checked.

Note: No candidate VM or role was created in the current session because required CI is not green and the authority migration has not been reviewed.

[dotnetpower]

Initial design

The initial design proposed creating an ephemeral Standard_D4ds_v5 candidate VM, copying all existing role assignments from the active VM system-assigned identity to the new VM system-assigned identity, registering candidate runner slots, running tests, and then executing the cutover.

Critique

• Implicit Login without Client ID: Seven workflows run on fdai-deploy and call az login --identity without selecting a client ID: deploy-dev, destroy-env, infra-drift, model-lifecycle-reconcile, model-settings-projection, service-deploy, and sre-demo-lab. This makes authentication ambiguous when multiple identities are attached.
• Dynamic Role Authority: Platform and scenario Terraform use data.azurerm_client_config.current.object_id for state-owned deployer roles, which means authority dynamically follows whichever VM system identity ran the last apply.
• Role Copying Trade-offs: The current VM has 15 direct assignments. Copying all of them propagates stale or state-owned authority drift, whereas copying only the bootstrap baseline roles breaks current platform and scenario deployment capabilities.
• Deployment Ordering: Candidate creation before required CI is green violates the protected deployment ordering.

Revised design

1. Identity phase

Bootstrap creates a stable User-Assigned Managed Identity (UAMI), attaches it alongside the current system identity on the runner VM, assigns only the bootstrap-owned roles, and outputs the client and principal ID handles. The repository variable supplies the client ID, ensuring no secret is exposed.

2. Workflow phase

All seven workflows (deploy-dev, destroy-env, infra-drift, model-lifecycle-reconcile, model-settings-projection, service-deploy, and sre-demo-lab) call az login --identity --client-id <configured> and verify that the active tenant, subscription, and token oid equal the configured deploy principal before execution of any privileged work. Any missing or mismatched values fail closed.

3. State migration phase

Protected zero-unrelated-destroy plans migrate the platform/scenario deployer and temporary grant ownership to the UAMI. Each state application verifies effective roles and revokes superseded system-identity assignments that it owns.

4. Candidate phase

Create a separate ephemeral Standard_D4ds_v5 candidate NIC/VM with the UAMI attached, register five candidate-only slots, and run protected checkout, managed-identity login, private state access, and plan-only preflight tests.

5. Cutover phase

Move the canonical fdai-deploy registration only after all validation evidence passes. Retain the old VM for rollback until at least one scheduled drift pass succeeds, then remove old registrations, VM, NIC, OS disk, and stale roles.

Falsifying checks

The transition and cutover will be immediately aborted under any of the following conditions:

• Any plan contains an unrelated network or storage deletion.
• Any token oid mismatch is detected.
• Any required role from the manifest is missing.
• Any extra direct assignment outside the defined manifest is found.
• The runner storage posture is not configured as Local/ResourceDisk.
• Fewer than five online idle slots are available.
• Any plan-only preflight test fails.

[dotnetpower]

Verdict: partial.

The issue contains a revised stable-UAMI design, but no committed identity/workflow migration or reviewed state-owned role transition is complete. This scope overlaps the active deploy-runner and subscription-genesis session.

Residual work: implement the stable role manifest and explicit client-ID authentication locally, validate protected workflow preflight, then perform the separately authorized blue/green cutover and cleanup.