Subscription provisioning¶

Elke spoke heeft een schone subscription nodig. Deze pagina legt de beslissing vast over hoe een platform aan die subscription komt: niet uit een pool, maar aangemaakt of voorbereid op het moment dat de spoke wordt gedeployd. Ze legt het probleem uit, de opties die zijn overwogen, de gevolgen en wat dit betekent voor de MCP-configuratie.

Beslissingsdocument

Dit is een ontwerpbeslissing, geschreven op basis van een architecture decision record van het spoke canvas. Het is richtlijn: je contract, je Azure-overeenkomst en je policies bepalen wat je kunt doen. Zie Ontwerprichtlijnen.

Het probleem¶

Elke spoke-omgeving heeft een schone subscription nodig waarin de resources en RBAC worden ingericht. Een pool van vooraf aangemaakte subscriptions lijkt aantrekkelijk: een script claimt er een als een spoke wordt gedeployd. In de praktijk is dat riskant, omdat spokes parallel worden gedeployd. Twee spoke-deployments kunnen dezelfde subscription claimen.

Provisioning op aanvraag lost ook meer op dan het claimprobleem:

er is geen handmatig proces nodig om een pool aan te vullen,
er bestaat geen subscription zonder doel,
provisioning is meer dan het aanmaken van de subscription. Het omvat ook:
- de subscription volgens conventie een naam geven als het spoke-bestand geen naam geeft,
- de tags uit het spoke-bestand instellen,
- de subscription verplaatsen naar de management group uit het spoke-bestand.

Opties¶

Optie	Idee	Waarom niet, of waarom wel
Claimen uit een pool	Een pool met vrije subscriptions staat klaar. De deployment claimt er een	Parallelle deployments kunnen dezelfde subscription claimen. Subscriptions in de pool hebben een importoplossing nodig. Een tweede oplossing moet de pool bewaken en aanvullen
Een provisioningstap in de spoke-deployment (gekozen)	De deployment bepaalt per spoke-omgeving of er een subscription nodig is. Zo ja, dan maakt hij die aan en geeft het resultaat door. Terraform stelt daarna ook naam, management group en tags in	Volledig geautomatiseerd. Compatibel met bestaande spokes

Beslissing¶

Voeg een aparte provisioningstap toe aan de spoke-deployment die indien nodig een subscription aanmaakt, en laat dezelfde Terraform de naam, de koppeling aan de management group en de tags instellen.

Gevolgen¶

Er wordt functionaliteit toegevoegd zonder bestaande deployments te wijzigen. Eén nieuwe instelling in de algemene spoke-instellingen is nodig om het te gebruiken.
Er hoeft geen pool te worden gevuld, bewaakt of opgeruimd.
De stap heeft een billingrelatie nodig waarmee subscriptions kunnen worden aangemaakt. Dat hangt af van je Azure-overeenkomst; zie hieronder.

Hoe het aansluit op MCP¶

flowchart LR
    spoke["Spoke JSON file"] --> sub["Subscription layer<br/>deploy/subscription"]
    sub -->|"subscriptionId"| canvas["Spoke canvas layer<br/>deploy/spoke"]
    canvas --> r["Name, tags, management group,<br/>network, identity, resources"]

De spoke-run heeft twee Terraform layers met aparte state (Provisioning). De subscription layer draait eerst en schrijft de subscription-ID naar een klein outputbestand. De spoke canvas layer leest dat bestand (Spoke canvas-modulereferentie), verplaatst de subscription naar de management group, hernoemt hem en stelt de tags in.

Situatie	Wat er gebeurt
`azureSubscriptionId` is ingesteld in het spoke-bestand	De subscription wordt gebruikt zoals hij is. Zo worden de pipelines nu gebruikt
`azureSubscriptionId` is leeg en de CSP-billingwaarden zijn aangeleverd	De subscription layer kan de subscription aanmaken

Subscriptions aanmaken vraagt een billingroute

Een subscription vanuit code aanmaken vraagt een billing account en een service principal met de rechten daarvoor (de xmscsp_*-inputs). De pipelines geven die inputs mee als lege strings. In een standaardopzet maak je de subscription eerst aan met je eigen EA-, MCA- of CSP-proces, en zet je de ID ervan in het spoke-bestand (Nieuwe spoke). Bepaal in je governance-proces wie subscriptions aanmaakt.

Kan de pipeline in jouw omgeving geen subscriptions aanmaken, dan geldt de beslissing nog steeds in één opzicht: bouw geen pool. Maak per spoke-aanvraag een subscription aan, en laat de spoke-deployment hem zijn naam, tags en management group geven.