Skip to content

Workload Onboarding

This is the end-to-end path for a team bringing a new workload onto the platform. One merge request to subscription vending produces a subscription with everything already connected: identity, state, pipeline, budget, access groups and governance. The team starts writing Terraform, not requesting access.

Status: in place

Workload subscriptions are vended from subscription-vending-workload, through the solution-manage-azure-subscription solution module.

The journey

flowchart LR
    REQ["1. Request<br/>(workload, env, owner, budget)"] --> MR["2. MR to<br/>subscription-vending-workload"]
    MR --> APPLY["3. Platform review<br/>and apply"]
    APPLY --> READY["4. Subscription, SP, state,<br/>GitLab project, groups, budget"]
    READY --> ACCESS["5. Team requests<br/>group access"]
    ACCESS --> BUILD["6. Team deploys through<br/>its own pipeline"]

1. Before you ask

Have these answers ready:

Question Used for
Workload name, environment and region The subscription name: <workload>-<environment>-<region>-<sequence>
Owning team The WorkloadOwner tag and group ownership
Expected monthly cost budget_amount. The default of 10 suits an empty subscription only.
Budget alert recipients budget_alert_emails
Production, non-production or sandbox? Placement under mg-landingzones or mg-sandboxes
Needs private networking? Whether a spoke VNet and address range are needed. See Networking.

2. Request

Add a file to subscription-vending-workload, copied from subscription-template.tf.example, and open an MR. The platform team reviews the plan.

3 and 4. What you get

After apply, the workload has:

  • A subscription placed in the right management group, with every platform policy applied.
  • A pipeline identity, sp-sub-tf-<name>-rw, signing in with OIDC (no secrets). It has Contributor on the subscription.
  • Its own Terraform state container in the management subscription.
  • A GitLab project with the CI variables and starter files (versions.tf, main.tf, .gitlab-ci.yml) already set up.
  • Entra ID groups: grp-<name>-contributor and grp-<name>-role-based-access-administrator (both PIM-eligible), and grp-<name>-reader (standing).
  • A budget with 80% and 100% alerts.
  • A FinOpsId for cost allocation, and a locked platform resource group.

5. Access

Team members request membership of the subscription's groups. Contributor access is PIM-eligible, so it is activated just-in-time rather than held.

6. Build

Add resources to the new project's main.tf. On MR, CI posts the plan. On merge, the apply runs after a manual approval job. This is Lane B: the pipeline identity is scoped to the workload's own subscription.

Ground rules

  • Use the platform modules (terraform-azure-modules and terraform-solutions) rather than raw resources, so tags, security baselines and naming come for free.
  • Everything through the pipeline. Portal changes are reverted on the next apply, and aren't reviewed.
  • Tag everything. Policy reports any resource without the standard tags.
  • Ask before you need Tier 0 or tenant-wide access. App registrations, Graph permissions and directory roles are Lane A requests. See Workload Identity Vending.