Identiteit en toegang voorbereiden¶
Deze pagina behandelt de Entra ID- en Azure-objecten die moeten bestaan vóór de eerste deployment: de groepen van het platformteam, de administrative unit, de PIM-flow, de RBAC-rollen, de management group en de deployment-identiteiten met hun service connections. Het model erachter staat in Identiteits- en toegangsmodel.
In veel implementaties maakt de klant het eerste deel (groepen, administrative unit, management group, PIM) aan op basis van een schriftelijke aanvraag, en controleert het platformteam dat met de controles op de vereisten. In een zelfbeheerde implementatie doet je eigen identiteitsteam het meestal. De stappen zijn in beide gevallen hetzelfde.
Wat je aanmaakt¶
| Object | Doel | Aangemaakt door |
|---|---|---|
| Groep platform engineers | Alle mensen die aan het platform werken. Niet role-assignable. | Identiteitsteam van de klant |
| Groep platform maintainers | De groep die de permanente roltoewijzingen bevat. Ze heeft geen actieve leden: toegang komt via PIM. Role-assignable. | Identiteitsteam van de klant |
| Administrative unit | Begrenst de Entra ID-groepen die de spoke-pipeline aanmaakt | Identiteitsteam van de klant |
| Management group van het platform | Root van de platformhiërarchie | De klant, of het platformteam |
| PIM-configuratie | Maakt de engineersgroep een eligible lid van de maintainersgroep, met goedkeuring | Identiteitsteam van de klant |
| RBAC- en directoryrollen | Geven de maintainersgroep de rechten om te deployen | Identiteitsteam van de klant |
| Deployment service principals | De identiteiten die de pipelines gebruiken, per platformomgeving | Platformteam |
| Service connections of federated credentials | Laten Azure DevOps of GitHub inloggen als die service principals | Platformteam |
Voorbeeldnamen
De namen hieronder volgen de conventie van één implementatie (voorvoegsel ASG_ voor Azure security groups, een
administrative unit die naar het platform is vernoemd). Het zijn voorbeelden. Gebruik de naamstandaard van de klant.
1. Groepen¶
Maak twee security groups aan in Microsoft Entra ID (Groups, New group):
| Groep | Voorbeeldnaam | Lidmaatschapstype | Microsoft Entra-rollen kunnen aan de groep worden toegewezen | Leden |
|---|---|---|---|---|
| Platform engineers | ASG_Platform_Engineers |
Assigned | Nee | De mensen van het platformteam |
| Platform maintainers | ASG_CloudPlatform_Maintainers |
Assigned | Ja (bevestig de pop-up) | Geen. Lidmaatschap komt via PIM. |
De instelling Microsoft Entra roles can be assigned to the group kun je alleen kiezen op het moment dat de groep wordt aangemaakt.
2. Management group¶
Als de klant deze nog niet heeft aangemaakt, maak je de management group van het platform aan (Management groups, Create):
| Veld | Waarde |
|---|---|
| Management group ID | Een korte ID zonder spaties, bijvoorbeeld <customer>-platform. Kan later niet worden gewijzigd. |
| Weergavenaam | Een leesbare naam |
Deze ID wordt management_group_organization_id (mapping). Plaats de
platform-subscriptions eronder (Vereisten).
3. Administrative unit¶
Maak een administrative unit aan (Microsoft Entra ID, Administrative units, Add):
| Veld | Waarde |
|---|---|
| Naam | Bijvoorbeeld AU_CloudPlatform |
| Beschrijving | Waarvoor hij wordt gebruikt |
| Restricted management administrative unit | Nee |
Kopieer de object ID. Die wordt SpokeCommon.tenantinfo.AdministrativeUnitId in mcp.json. De spoke-pipeline maakt de
spoke-groepen in deze unit aan (Nieuwe spoke).
4. RBAC- en directoryrollen voor de maintainersgroep¶
Wijs deze toe aan de maintainersgroep, zodat niemand ze permanent heeft.
Op de management group van het platform¶
- Open Management groups, de management group van het platform, Access control (IAM).
- Add, Add role assignment. Kies de rol Owner (onder Privileged administrator roles).
- Kies als lid de maintainersgroep.
- Kies op het tabblad Conditions de optie Allow user to assign all roles (highly privileged). De deployment maakt roltoewijzingen aan, dus Owner zonder deze voorwaarde is niet genoeg.
- Review + assign.
Op de administrative unit¶
Open de administrative unit, Roles and administrators. Wijs elk van deze rollen toe aan de maintainersgroep:
- Groups Administrator
- User Administrator
Voor elk: toewijzingstype Active, permanent, en een motivatie die aangeeft dat de groep geen actieve leden heeft en dat lidmaatschap wordt gegeven via PIM-flows voor just-in-time en just-enough access.
In de directory¶
Open Microsoft Entra ID, Roles and administrators, Application Developer, en wijs die op dezelfde manier toe aan de maintainersgroep (active, permanent, dezelfde motivatie). Hiermee kan het team de deployment service principals aanmaken.
5. PIM-flow¶
De engineersgroep wordt een eligible lid van de maintainersgroep. Engineers activeren het lidmaatschap wanneer ze moeten werken.
- Open Microsoft Entra Privileged Identity Management, Groups, Discover groups.
- Zoek de maintainersgroep, selecteer die en kies Manage groups. Bevestig de pop-up en wacht tot het klaar is.
- Open de maintainersgroep, Assignments, Add assignments. Rol: Member. Lid: de engineersgroep. Houd de standaardinstellingen aan, waarmee de toewijzing een jaar eligible is. Verleng hem voordat hij verloopt.
- Open Settings, de rol Member, Edit. Selecteer Require approval to activate en kies de goedkeurders.
Kies goedkeurders die passen bij het beheermodel:
- In het managed-model zijn de goedkeurders meestal leden van het platformteam zelf (een tweede engineer keurt goed) of een klantgroep, zoals in het contract is afgesproken.
- In het zelfbeheer-model gebruik je een groep van de security- of cloudplatform-eigenaren van de klant, of een tweede engineer van het team.
Engineers activeren daarna de groepstoewijzing in PIM (My roles, Groups, Activate) voordat ze gaan werken. Dit is ook de eerste controle in de controles op de vereisten.
6. Deployment service principals¶
Maak per platformomgeving (canary en prod) één service principal aan. De pipelines gebruiken die om in te loggen bij
Azure. mcp.json verwijst ernaar als Azure.TerraformState.Hub.ServicePrincipalId (en .Spoke. voor spokes). Je kunt één
service principal voor hub en spokes gebruiken, of aparte. Met aparte kun je de spoke-identiteit haar directoryrechten geven
zonder ze aan de hub-identiteit te geven.
Activeer eerst PIM
Voor het aanmaken van service principals en roltoewijzingen heb je de rechten van de maintainersgroep nodig. Activeer je PIM-toewijzing voordat je begint.
Log in op de tenant van de klant, maak dan de service principals aan en geef ze Owner op de management group van het platform:
az login --tenant <tenant-id>
$customerShortName = "<short-name>" # at most 6 characters
$managementGroupId = "<management-group-id>"
foreach ($env in "CANARY", "PROD") {
$name = "SPN_${customerShortName}_LZ_${env}"
$sp = az ad sp create-for-rbac --name $name | ConvertFrom-Json
az role assignment create --assignee $sp.appId --role "Owner" `
--scope "/providers/Microsoft.Management/managementGroups/$managementGroupId"
"$name client id: $($sp.appId) tenant: $($sp.tenant)"
# $sp.password holds the client secret. Store it in your vault now. It is shown only once.
}
Het naampatroon SPN_<short-name>_LZ_<ENV> is een voorbeeld uit eerdere runbooks; gebruik je eigen standaard.
Bewaar het secret veilig
az ad sp create-for-rbac maakt een client secret aan en toont het één keer. Zet het in de secret store die jouw team
gebruikt (als secret-waarde, nooit in platte tekst, chat of de repository). Beter: gebruik federated credentials en
sla het secret over (GitHub-variant, en workload identity federation voor
Azure DevOps service connections). De update-spn pipeline in de coderepository slaat een deployment-secret op in de
Key Vault van de hub en roteert het (Verantwoordelijkheden).
Rechten van de spoke-identiteit¶
De identiteit die spokes deployt heeft meer nodig dan Azure RBAC, omdat de spoke canvas Entra ID-groepen, service principals en PIM-instellingen aanmaakt. In de runbooks voor de GitHub-variant waren dat:
| Waar | Recht |
|---|---|
| Microsoft Graph, application permissions | AdministrativeUnit.ReadWrite.All, Application.ReadWrite.All, DelegatedPermissionGrant.ReadWrite.All, Group.Read.All, GroupMember.Read.All, PrivilegedAccess.ReadWrite.AzureADGroup, PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup, RoleManagement.ReadWrite.Directory, RoleManagementPolicy.ReadWrite.AzureADGroup, RoleManagementPolicy.ReadWrite.Directory, User.Read.All |
| Administrative unit | Groups Administrator |
| State storage account | Storage Blob Data Contributor |
| Management group van het platform | Genoeg om subscriptions te verplaatsen en roltoewijzingen aan te maken. De Owner-toewijzing van de deployment-identiteit dekt dit. |
Zet je spokes uit met twee spoke-identiteiten (canary en productie), geef dan elk de rol Owner op de landing zone management group van zijn eigen omgeving en de rol Groups Administrator op de administrative unit. Meer in De spoke pipeline voorbereiden.
Voor het toekennen van de Graph-rechten is admin consent nodig van iemand met de juiste directoryrol. Vraag het aan de beheerder van de klant, of gebruik je door PIM geactiveerde rol als je die hebt. De gezaghebbende lijst voor jouw versie staat in de documentatie van de spoke canvas in de coderepository die je pint (How to use spoke deployment, sectie Prerequisites, Pipeline, Service principal). Controleer de lijst daartegen voordat je consent vraagt.
7. Service connections (Azure DevOps)¶
Maak voor elke deployment service principal een Azure Resource Manager service connection aan in het Azure DevOps-project (Project settings, Service connections, New service connection):
| Veld | Waarde |
|---|---|
| Identity type | App registration or managed identity (manual) |
| Credential | Secret, of workload identity federation als je federated credentials hebt ingesteld |
| Scope level | Subscription: de management-subscription van die platformomgeving |
| Subscription ID en naam | De management-subscription van canary, of van prod |
| Application (client) ID | De client ID van de service principal |
| Directory (tenant) ID | De tenant-ID van de klant |
| Client secret | Het secret, als je er een gebruikt |
| Naam van de service connection | De naam die pipelines/variables.yaml verwacht, bijvoorbeeld <env>.serviceConnectionNameHub (Pipelines) |
Kies Verify en daarna Save. Gebruik aparte service connections voor canary en prod. Dit is onderdeel van de security baseline.
Service connections op scope van een management group, zoals gebruikt door de aparte spoke canvas-pipeline, worden beschreven in De spoke pipeline voorbereiden.
Als de coderepository op een andere host staat dan de Azure DevOps van de klant (bijvoorbeeld in het managed-model, waar ze
wordt gesynct vanuit een GitHub Enterprise-instance), heb je ook een service connection van die host nodig voor de
repository resource mcp-code. Zie Repositories.
Voor de agent pool heeft de service connection van de infrastructure pipeline Contributor of Owner nodig op de
subscription die de job runners bevat, en heeft de pool service rechten nodig in Azure DevOps. Zie
Pipelines en agents.
Checklist¶
- [ ] Twee groepen bestaan; de maintainersgroep is role-assignable en heeft geen leden
- [ ] Management group van het platform bestaat; subscriptions zijn eronder geplaatst
- [ ] Administrative unit bestaat; de object ID is genoteerd
- [ ] Maintainersgroep: Owner (met de all-roles-voorwaarde) op de management group; Groups Administrator en User Administrator op de administrative unit; Application Developer in de directory
- [ ] PIM: engineersgroep is eligible voor de maintainersgroep, met goedkeuring
- [ ] Deployment service principals bestaan per platformomgeving, met opgeslagen secrets of ingestelde federated credentials
- [ ] Spoke-identiteit: Graph-rechten met admin consent, rol op de administrative unit, rol op de state storage
- [ ] Service connections bestaan, zijn geverifieerd, en zijn gescheiden voor canary en prod
- [ ] Maken spokes Azure DevOps- of GitHub-resources aan: Spoke-integraties voorbereiden is gedaan