Voraussetzungen und Anforderungen an die Landing Zone¶

Alles auf dieser Seite muss vorhanden sein oder beim Kunden angefordert werden, bevor der Deployment Engineer mit der Vorbereitung beginnt. Eine fehlende Voraussetzung ist der häufigste Grund, warum eine Implementierung ins Stocken gerät. Prüfe daher jeden Punkt frühzeitig.

Azure¶

Subscriptions¶

Der hub verwendet pro Funktion eine Plattform-subscription, und die Plattform hat zwei Plattform-Umgebungen: canary und prod (Glossar). Jede Plattform-Umgebung braucht ihren eigenen Satz.

Subscription	Rolle im hub	Erforderlich
Management	Log Analytics, Key Vault, Automation, Storage. Enthält oft auch das Terraform-State-Storage-Account und die Job runners (beide werden in `mcp.json` festgelegt).	Ja
Connectivity	Virtual WAN, hub, Azure Firewall, Gateways, DNS, Application Gateway	Ja
Identity	Identity Virtual Network	Optional, je nachdem, ob der Kunde eine Identity-subscription braucht

Das sind mindestens vier subscriptions (Management und Connectivity, für canary und für prod), oder sechs mit den optionalen Identity-subscriptions. Zusätzlich braucht jeder spoke eine subscription. Die pipelines können nur mit einem CSP-Billing-Account eine subscription erstellen. Lege spoke-subscriptions daher zuerst über deinen eigenen EA-, MCA- oder CSP-Prozess an (Neuer Spoke).

Die subscription-IDs kommen in scaffold_subscriptions in <env-folder>/global.auto.tfvars (Hub-Konfiguration).

Management group¶

Erstelle eine management group auf oberster Ebene für die Plattform, direkt unter der Tenant Root Group. Ihre ID ist der Wert von management_group_organization_id. Die ID kann nach der Erstellung nicht mehr geändert werden und darf keine Leerzeichen enthalten.
Lege die Plattform-subscriptions darunter ab. Jede subscription, die die Deployment-Identität verwalten muss, muss unter dieser management group liegen, weil die Identität ihre Rechte durch Vererbung erhält.
Wenn der Kunde das Plattform-Team bittet, die management group zu erstellen, braucht die deployende Identität Rechte auf der Tenant Root Group: siehe Erhöhter Zugriff auf Tenant-Ebene.

Den Rest der Hierarchie baut die Plattform selbst (Struktur der management groups).

Berechtigungen, die das Plattform-Team braucht¶

Wo	Was	Warum
Management group der Plattform	Owner, mit der Bedingung, die das Zuweisen aller Rollen erlaubt	Das Deployment erstellt Rollenzuweisungen
Microsoft Entra ID	Eine Verzeichnisrolle, die App-Registrierungen erstellen kann, zum Beispiel Application Developer	Um die Deployment-Service-Principals zu erstellen
Administrative Unit in Entra ID	Groups Administrator und User Administrator auf der Unit	Damit die Plattform die Gruppen verwalten kann, die sie für spokes erstellt
Tenant Root Group (nur wenn das Plattform-Team die management group erstellt)	Management Group Contributor	Um eine management group unter der Root zu erstellen

Vergib diese an eine Gruppe, nicht an einzelne Nutzer, und stelle die Mitgliedschaft dieser Gruppe über PIM bereit. Die Schritte stehen unter Identität vorbereiten.

Rechte nach der Installation senken, wo es geht

Die Installation braucht hohe Rechte. Prüfe sie bei der Übergabe und behalte nur, was die täglichen pipelines brauchen. Die Deployment-Service-Principals behalten ihre Rechte, weil jeder pipeline-Lauf von ihnen abhängt.

Erhöhter Zugriff auf Tenant-Ebene¶

Um Rollen auf der Tenant Root Group zuzuweisen, muss ein Global Administrator zuerst Access management for Azure resources für sein Konto aktivieren (Microsoft Entra ID, Properties). Schalte es wieder aus, wenn die Zuweisung erledigt ist. Wenn die Tenant Root Group im portal nicht als anklickbare management group erscheint, ist das der Grund.

Partner-Zuordnung¶

Wenn ein Implementierungspartner oder Managed-Service-Anbieter im Tenant arbeitet, verknüpfe seine Partner-ID mit dem Tenant, damit die Azure- Nutzung dem Partner zugerechnet wird (Partner Admin Link, PAL). In PowerShell, mit installierten Modulen Az und Az.ManagementPartner:

Connect-AzAccount -TenantId <tenant-id>
New-AzManagementPartner -PartnerId <partner-id>
Get-AzManagementPartner

Get-AzManagementPartner muss die Partner-ID anzeigen. Überspringe diesen Schritt bei einer Implementierung im Eigenbetrieb ohne Partner.

Azure DevOps (wenn der Kunde Azure DevOps verwendet)¶

Punkt	Detail
Organisation	Die Azure-DevOps-Organisation des Kunden, gestützt auf den Entra-ID-Tenant des Kunden
Projekt	Ein privates Projekt für die Plattform, mit Git-Repositories. Füge die Gruppe des Plattform-Teams für die Dauer der Implementierung als Projektadministratoren hinzu.
Nutzer	Jedes Mitglied des Plattform-Teams hat ein Konto in der Organisation mit dem Zugriffslevel Basic
Parallelität	Genügend parallele Jobs für die pipelines und den Pool gekauft

Wenn das Plattform-Team in der eigenen Organisation des Kunden arbeitet, muss der Kunde Nutzer und Projekt bereitstellen. Wenn du eine separate Organisation des Plattform-Teams verwendest, brauchst du diese Punkte nicht, aber du brauchst eine Möglichkeit, die pipelines gegen den Tenant des Kunden auszuführen.

GitHub (wenn der Kunde GitHub verwendet)¶

Punkt	Detail
Organisation	Die GitHub-Organisation des Kunden (GitHub.com oder GitHub Enterprise)
Rollen für das Plattform-Team	Die vordefinierten Organisationsrollen CI/CD admin (Actions-Policies, Runner, Runner-Gruppen, Secrets und Variablen verwalten) und App Manager (GitHub Apps erstellen und bearbeiten)
Repositories	Das Plattform-Team kann Repositories erstellen
Hosted compute networking	In den Organisationseinstellungen sichtbar, wenn du GitHub-gehostete Runner mit privatem Netzwerk verwenden willst (älterer Ansatz). Wenn nicht, muss der Enterprise Owner des Kunden es aktivieren.
Runner	Mindestens ein Standard-Runner mit einem aktuellen Ubuntu-Image in der Default-Runner-Gruppe, für die ersten Deployments

Siehe GitHub-Variante.

Netzwerk und Planung¶

IP-Plan. Adressbereiche für den hub (pro Region), die Identity- und Management-Netzwerke, das Netzwerk der Job runners (Virtual Network, Agent-Subnetz, Private-Endpoint-Subnetz, Subnetz der Container Apps Environment, DNS-Resolver-Subnetz) und die ersten spokes. Die Plattform prüft nicht auf Überschneidungen, also prüfe den Plan selbst.
Konnektivitäts-Eingaben. Wenn das Design VPN, ExpressRoute oder BGP enthält: Peer-Adressen, ASNs und die On-Premises- Routen, und wer die Gegenseite konfiguriert.
Namenswahl. Der Kurzname des Kunden (höchstens sechs Zeichen, siehe die Namensreferenz) und die Namensregeln für workloads.
Azure Resource Provider. Die Provider, die die Plattform verwendet, müssen in jeder Plattform-subscription registriert sein. Die älteren Runbooks führen dafür ein Skript aus dem Code-Repository aus (scripts/register-az-providers.ps1; prüfe, ob es in der Version existiert, die du fixierst). Der Lauf infrastructure registriert die Provider, die die Job runners brauchen. Für die Registrierung eines Providers braucht man mindestens Contributor auf der subscription.
Quota. Prüfe, ob die subscription in der gewählten Region Quota für die VM-Größe der Job runners hat. Fehlende Quota lässt den ersten Lauf von infrastructure fehlschlagen.

Die Informationen, die du vom Kunden brauchst¶

Sammle diese in der Planungsphase, damit der Deployment Engineer ohne Rückfragen arbeiten kann:

Punkt	Beispielform
Tenant-ID von Entra ID	GUID
ID der management group der Plattform	`<customer>-platform`
Subscription-IDs	Management, Connectivity (und Identity) für canary und prod
Kurzname des Kunden	Höchstens sechs Zeichen
Mitglieder der Gruppe des Plattform-Teams	Liste von Nutzern (Gäste oder interne Nutzer)
Azure-DevOps-Organisation und -Projekt, oder GitHub-Organisation	Namen
Primäre Region und weitere Regionen	Kurz- und Langnamen
IP-Plan	Bereiche pro Zweck
Alert-Empfänger und der Security-Kontakt	E-Mail-Adressen oder Webhook

Die Voraussetzungen prüfen¶

Wenn der Kunde sagt, dass die Voraussetzungen erfüllt sind, prüft das Plattform-Team sie, bevor die Arbeit beginnt. Schlägt eine Prüfung fehl, gehe zurück zum Kunden: Die Vorbereitung ist nicht der Ort, um die Voraussetzungen eines anderen zu beheben.

Azure-Prüfungen¶

Melde dich im Azure portal des Kunden an. Wenn PIM verwendet wird, öffne Privileged Identity Management, My roles, Groups, prüfe, dass eine berechtigte (eligible) Zuweisung existiert, und aktiviere sie.
Prüfe nach der Aktivierung deine Entra-ID-Verzeichnisrolle. Sie muss die Rolle aus der obigen Berechtigungstabelle enthalten (zum Beispiel Application Developer).
Prüfe in Entra ID, dass alle Mitglieder des Plattform-Teams als Nutzer existieren und dass die angeforderten Gruppen mit den richtigen Mitgliedern existieren. Eventuell darfst du nicht alle Nutzer sehen; bitte den Kunden um Bestätigung.
Prüfe unter Management groups, dass die management group der Plattform existiert.
Prüfe in ihrer Access control (IAM), dass die Gruppe des Plattform-Teams Owner hat.
Prüfe, dass die Plattform-subscriptions unter dieser management group liegen.

Azure-DevOps-Prüfungen¶

Melde dich in der Organisation des Kunden an. Prüfe unter Organization settings, Users, dass jedes Mitglied des Plattform-Teams mit dem Zugriffslevel Basic vorhanden ist.
Prüfe, dass das Projekt existiert, dass das Plattform-Team Projektadministratoren sind und dass du Repos und Pipelines siehst.

GitHub-Prüfungen¶

Prüfe in der Organisation unter People, dass jedes Teammitglied Mitglied ist und die oben genannten Rollen hat.
Prüfe unter Settings, dass du GitHub Apps erstellen kannst und bei Bedarf Hosted compute networking siehst.
Prüfe, dass du Repositories erstellen kannst.
Öffne unter Settings, Actions, Runner groups die Default-Gruppe und prüfe, dass sie mindestens einen Runner mit einem aktuellen Ubuntu-Image hat. Erstelle einen, falls keiner vorhanden ist.

Nächster Schritt¶

Weiter mit Von der Discovery zur Deployment-Eingabe, danach Identität vorbereiten.