Subscription-Provisioning¶

Jeder spoke braucht eine saubere subscription. Diese Seite hält die Entscheidung fest, wie eine Plattform diese subscription bekommt: nicht aus einem Pool, sondern erstellt oder vorbereitet, wenn der spoke deployt wird. Sie erklärt das Problem, die Optionen, die betrachtet wurden, die Konsequenzen und was das für die MCP-Konfiguration bedeutet.

Entscheidungsdokument

Das ist eine Designentscheidung, geschrieben aus einem Architecture Decision Record des spoke canvas. Sie ist ein Leitfaden: Dein Vertrag, deine Azure-Vereinbarung und deine Policies bestimmen, was du tun kannst. Siehe Design-Leitfäden.

Das Problem¶

Jede spoke-Umgebung braucht eine saubere subscription, in der ihre Ressourcen und ihr RBAC eingerichtet werden. Ein Pool vorab erstellter subscriptions wirkt attraktiv: Ein Skript beansprucht eine, wenn ein spoke deployt wird. In der Praxis ist das riskant, weil spokes parallel deployt werden. Zwei spoke-Deployments können dieselbe subscription beanspruchen.

Provisioning bei Bedarf löst außerdem mehr als das Problem der Beanspruchung:

Es ist kein manueller Prozess nötig, um einen Pool aufzufüllen,
es existiert keine subscription ohne Zweck,
Provisioning ist mehr als das Erstellen der subscription. Es umfasst auch:
- die subscription nach Konvention benennen, wenn die spoke-Datei keinen Namen angibt,
- die tags aus der spoke-Datei setzen,
- die subscription in die management group aus der spoke-Datei verschieben.

Optionen¶

Option	Idee	Warum nicht, oder warum
Aus einem Pool beanspruchen	Ein Pool freier subscriptions steht bereit. Das Deployment beansprucht eine	Parallele Deployments können dieselbe subscription beanspruchen. Subscriptions im Pool brauchen eine Importlösung. Eine zweite Lösung muss den Pool überwachen und auffüllen
Ein Provisioning-Schritt im spoke-Deployment (gewählt)	Das Deployment erkennt pro spoke-Umgebung, ob eine subscription nötig ist. Falls ja, erstellt es sie und gibt das Ergebnis weiter. Terraform setzt dann auch Name, management group und tags	Vollständig automatisiert. Kompatibel mit bestehenden spokes

Entscheidung¶

Füge dem spoke-Deployment einen separaten Provisioning-Schritt hinzu, der eine subscription erstellt, wenn nötig, und lass dasselbe Terraform den Namen, die Zuordnung zur management group und die tags setzen.

Konsequenzen¶

Funktionalität kommt hinzu, ohne bestehende Deployments zu ändern. Für die Nutzung ist eine neue Einstellung in den allgemeinen spoke-Einstellungen nötig.
Es muss kein Pool aufgefüllt, überwacht oder bereinigt werden.
Der Schritt braucht eine Billing-Beziehung, über die subscriptions erstellt werden können. Das hängt von deiner Azure-Vereinbarung ab; siehe unten.

Wie es sich auf MCP abbildet¶

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"]

Der spoke-Lauf hat zwei Terraform-layers mit getrenntem state (Provisioning). Der subscription-layer läuft zuerst und schreibt die subscription-ID in eine kleine Output-Datei. Der spoke-canvas-layer liest diese Datei (Modulreferenz des Spoke canvas), verschiebt die subscription in die management group, benennt sie um und setzt die tags.

Situation	Was passiert
`azureSubscriptionId` ist in der spoke-Datei gesetzt	Die subscription wird unverändert verwendet. So werden die pipelines heute genutzt
`azureSubscriptionId` ist leer und die CSP-Billing-Werte werden geliefert	Der subscription-layer kann die subscription erstellen

Das Erstellen von subscriptions braucht einen Billing-Weg

Eine subscription aus Code zu erstellen, braucht einen Billing Account und einen Service Principal mit den nötigen Rechten (die xmscsp_*-Inputs). Die pipelines übergeben diese Inputs als leere Strings. In einem Standard-Setup erstellst du die subscription zuerst mit deinem eigenen EA-, MCA- oder CSP-Prozess und trägst ihre ID in die spoke-Datei ein (Neuer spoke). Lege in deinem Governance-Prozess fest, wer subscriptions erstellt.

Wenn die pipeline in deiner Umgebung keine subscriptions erstellen kann, gilt die Entscheidung in einem Punkt trotzdem: Baue keinen Pool. Erstelle pro spoke-Anfrage eine subscription und lass das spoke-Deployment ihr Namen, tags und management group geben.