Randvoorwaarden en eisen aan de landing zone¶

Alles op deze pagina moet bestaan, of bij de klant worden aangevraagd, voordat de deployment engineer met de voorbereiding begint. Een ontbrekende randvoorwaarde is de meest voorkomende reden dat een implementatie stilvalt, dus controleer elk onderdeel vroeg.

Azure¶

Subscriptions¶

De hub gebruikt per functie één platformsubscription, en het platform heeft twee platformomgevingen: canary en prod (Woordenlijst). Elke platformomgeving heeft een eigen set nodig.

Subscription	Rol in de hub	Vereist
Management	Log Analytics, Key Vault, Automation, storage. Bevat vaak ook het Terraform state storage account en de job runners (beide worden in `mcp.json` ingesteld).	Ja
Connectivity	Virtual WAN, hub, Azure Firewall, gateways, DNS, Application Gateway	Ja
Identity	Identity virtual network	Optioneel, afhankelijk van of de klant een identity-subscription nodig heeft

Dat zijn minimaal vier subscriptions (management en connectivity, voor canary en voor prod), of zes met de optionele identity-subscriptions. Daarnaast heeft elke spoke een subscription nodig. De pipelines kunnen alleen een subscription aanmaken met een CSP-billingaccount, dus maak spoke-subscriptions eerst aan via je eigen EA-, MCA- of CSP-proces (Nieuwe spoke).

De subscription-ID's komen in scaffold_subscriptions in <env-folder>/global.auto.tfvars (Hub-configuratie).

Management group¶

Maak een management group op het hoogste niveau voor het platform, direct onder de Tenant Root Group. De ID ervan is de waarde van management_group_organization_id. De ID kan na het aanmaken niet meer worden gewijzigd en mag geen spaties bevatten.
Plaats de platformsubscriptions eronder. Elke subscription die de deployment-identity moet beheren, moet onder deze management group staan, omdat de identity zijn rechten via overerving krijgt.
Als de klant het platformteam vraagt de management group aan te maken, heeft de deployende identity rechten nodig op de Tenant Root Group: zie Verhoogde toegang op tenantniveau.

Het platform bouwt de rest van de hiërarchie zelf (Structuur van management groups).

Rechten die het platformteam nodig heeft¶

Waar	Wat	Waarom
Management group van het platform	Owner, met de voorwaarde die het toewijzen van alle rollen toestaat	De deployment maakt roltoewijzingen aan
Microsoft Entra ID	Een directoryrol die app registrations kan aanmaken, bijvoorbeeld Application Developer	Om de service principals voor de deployment aan te maken
Entra ID administrative unit	Groups Administrator en User Administrator op de unit	Zodat het platform de groepen kan beheren die het voor spokes aanmaakt
Tenant Root Group (alleen als het platformteam de management group aanmaakt)	Management Group Contributor	Om een management group onder de root aan te maken

Geef deze rechten aan een groep, niet aan individuele gebruikers, en maak het lidmaatschap van die groep beschikbaar via PIM. Zie Identiteit voorbereiden voor de stappen.

Verlaag de rechten na de installatie waar dat kan

De installatie vraagt hoge rechten. Bekijk ze bij de overdracht en houd alleen over wat de dagelijkse pipelines nodig hebben. De service principals voor de deployment behouden hun rechten, omdat elke pipelinerun ervan afhangt.

Verhoogde toegang op tenantniveau¶

Om rollen op de Tenant Root Group toe te wijzen, moet een Global Administrator eerst Access management for Azure resources inschakelen voor zijn account (Microsoft Entra ID, Properties). Zet het weer uit als de toewijzing klaar is. Verschijnt de Tenant Root Group in de portal niet als aanklikbare management group, dan is dit de reden.

Partnerkoppeling¶

Werkt een implementatiepartner of managed-serviceprovider in de tenant, koppel dan zijn partner-ID aan de tenant, zodat het Azure- gebruik aan de partner wordt toegerekend (Partner Admin Link, PAL). In PowerShell, met de modules Az en Az.ManagementPartner geïnstalleerd:

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

Get-AzManagementPartner moet de partner-ID tonen. Sla deze stap over bij een zelfbeheerde implementatie zonder partner.

Azure DevOps (wanneer de klant Azure DevOps gebruikt)¶

Onderdeel	Detail
Organization	De Azure DevOps-organization van de klant, gekoppeld aan de Entra ID-tenant van de klant
Project	Een privéproject voor het platform, met Git-repositories. Voeg de groep van het platformteam toe als projectbeheerders voor de duur van de implementatie.
Gebruikers	Elk lid van het platformteam heeft een account in de organization met het toegangsniveau Basic
Parallelism	Genoeg parallelle jobs gekocht voor de pipelines en de pool

Als het platformteam in de eigen organization van de klant werkt, moet de klant gebruikers en het project regelen. Gebruik je een aparte organization van het platformteam, dan heb je deze onderdelen niet nodig, maar wel een manier om de pipelines tegen de tenant van de klant te draaien.

GitHub (wanneer de klant GitHub gebruikt)¶

Onderdeel	Detail
Organization	De GitHub-organization van de klant (GitHub.com of GitHub Enterprise)
Rollen voor het platformteam	De vooraf gedefinieerde organization-rollen CI/CD admin (beheert Actions-policies, runners, runner groups, secrets en variables) en App Manager (maakt GitHub Apps aan en bewerkt ze)
Repositories	Het platformteam kan repositories aanmaken
Hosted compute networking	Zichtbaar in de organization-instellingen als je GitHub-hosted runners met privénetwerk wilt gebruiken (oudere aanpak). Zo niet, dan moet de enterprise owner van de klant het inschakelen.
Runner	Minstens één standaardrunner op een actuele Ubuntu-image in de standaard runner group, voor de eerste deployments

Zie GitHub-variant.

Netwerk en planning¶

IP-plan. Adresbereiken voor de hub (per regio), de identity- en managementnetwerken, het netwerk van de job runners (virtual network, agent-subnet, subnet voor private endpoints, subnet voor de Container Apps-omgeving, subnet voor de DNS resolver) en de eerste spokes. Het platform controleert niet op overlap, dus review het plan.
Connectiviteitsgegevens. Als het ontwerp VPN, ExpressRoute of BGP bevat: peer-adressen, ASN's en de on-premises routes, en wie de andere kant configureert.
Naamkeuzes. De korte naam van de klant (maximaal zes tekens, zie de naamgevingsreferentie) en de naamgevingsregels voor workloads.
Azure resource providers. De providers die het platform gebruikt, moeten in elke platformsubscription zijn geregistreerd. De oudere runbooks draaien hiervoor een script uit de coderepository (scripts/register-az-providers.ps1; controleer of het bestaat in de versie die je pint). De infrastructure-run registreert de providers die de job runners nodig hebben. Een provider registreren vereist minstens Contributor op de subscription.
Quota. Controleer of de subscription quota heeft voor de VM-grootte van de job runner in de gekozen regio. Een tekort aan quota laat de eerste infrastructure-run falen.

De informatie die je van de klant nodig hebt¶

Verzamel dit in de planfase, zodat de deployment engineer kan werken zonder vragen te stellen:

Onderdeel	Voorbeeldvorm
Entra ID-tenant-ID	GUID
ID van de management group van het platform	`<customer>-platform`
Subscription-ID's	Management, connectivity (en identity) voor canary en prod
Korte naam van de klant	Maximaal zes tekens
Leden van de groep van het platformteam	Lijst met gebruikers (gasten of interne gebruikers)
Azure DevOps-organization en -project, of GitHub-organization	Namen
Primaire regio en extra regio's	Korte en lange namen
IP-plan	Bereiken per doel
Ontvangers van alerts en de securitycontactpersoon	E-mailadressen of webhook

De randvoorwaarden controleren¶

Zegt de klant dat de randvoorwaarden op orde zijn, dan controleert het platformteam ze voordat het werk begint. Faalt een controle, ga dan terug naar de klant: de voorbereiding is niet de plek om de randvoorwaarden van iemand anders te herstellen.

Azure-controles¶

Log in op de Azure-portal van de klant. Wordt PIM gebruikt, open dan Privileged Identity Management, My roles, Groups, controleer dat er een eligible toewijzing bestaat en activeer die.
Controleer na activatie je Entra ID-directoryrol. Die moet de rol uit de bovenstaande rechtentabel bevatten (bijvoorbeeld Application Developer).
Controleer in Entra ID dat alle leden van het platformteam als gebruiker bestaan en dat de gevraagde groepen bestaan met de juiste leden. Misschien heb je geen rechten om alle gebruikers te zien; vraag de klant het te bevestigen.
Controleer in Management groups dat de management group van het platform bestaat.
Controleer in de Access control (IAM) ervan dat de groep van het platformteam Owner heeft.
Controleer dat de platformsubscriptions onder die management group staan.

Azure DevOps-controles¶

Log in op de organization van de klant. Controleer in Organization settings, Users dat elk lid van het platformteam aanwezig is met het toegangsniveau Basic.
Controleer dat het project bestaat, dat het platformteam projectbeheerder is en dat je Repos en Pipelines ziet.

GitHub-controles¶

Controleer in de organization onder People dat elk teamlid lid is en de hierboven genoemde rollen heeft.
Controleer in Settings dat je GitHub Apps kunt aanmaken en, indien nodig, Hosted compute networking ziet.
Controleer dat je repositories kunt aanmaken.
Open in Settings, Actions, Runner groups de standaardgroep en controleer dat die minstens één runner op een actuele Ubuntu-image heeft. Maak er een aan als die er niet is.

Volgende stap¶

Ga verder met Van discovery-output naar deployment-input, en daarna Identiteit voorbereiden.