Identität und Zugriff vorbereiten¶

Diese Seite behandelt die Entra-ID- und Azure-Objekte, die vor dem ersten Deployment existieren müssen: die Gruppen des Plattform-Teams, die Administrative Unit, den PIM-Flow, die RBAC-Rollen, die management group und die Deployment-Identitäten mit ihren service connections. Das Modell dahinter steht im Identitäts- und Zugriffsmodell.

In vielen Implementierungen erstellt der Kunde den ersten Teil (Gruppen, Administrative Unit, management group, PIM) auf eine schriftliche Anfrage hin, und das Plattform-Team prüft ihn mit den Voraussetzungs-Checks. Im Eigenbetrieb erledigt das meist dein eigenes Identity-Team. Die Schritte sind in beiden Fällen dieselben.

Was du erstellst¶

Objekt	Zweck	Erstellt von
Gruppe Platform engineers	Alle Personen, die an der Plattform arbeiten. Nicht role-assignable.	Identity-Team des Kunden
Gruppe Platform maintainers	Die Gruppe, die die dauerhaften Rollenzuweisungen hält. Sie hat keine aktiven Mitglieder: Der Zugriff kommt aus PIM. Role-assignable.	Identity-Team des Kunden
Administrative Unit	Grenzt die Entra-ID-Gruppen ab, die die spoke-pipeline erstellt	Identity-Team des Kunden
Platform management group	Root der Plattform-Hierarchie	Kunde oder Plattform-Team
PIM-Konfiguration	Macht die Engineers-Gruppe zu einem eligible Mitglied der Maintainers-Gruppe, mit Genehmigung	Identity-Team des Kunden
RBAC- und Verzeichnisrollen	Geben der Maintainers-Gruppe die Rechte zum Deployen	Identity-Team des Kunden
Deployment service principals	Die Identitäten, die die pipelines verwenden, pro Plattformumgebung	Plattform-Team
Service connections oder Federated Credentials	Lassen Azure DevOps oder GitHub sich als diese service principals anmelden	Plattform-Team

Beispielnamen

Die Namen unten folgen der Konvention einer Implementierung (Präfix ASG_ für Azure-Sicherheitsgruppen, eine Administrative Unit, die nach der Plattform benannt ist). Es sind Beispiele. Verwende den Namensstandard des Kunden.

1. Gruppen¶

Erstelle zwei Sicherheitsgruppen in Microsoft Entra ID (Groups, New group):

Gruppe	Beispielname	Mitgliedschaftstyp	Microsoft Entra roles can be assigned to the group	Mitglieder
Platform engineers	`ASG_Platform_Engineers`	Assigned	Nein	Die Personen des Plattform-Teams
Platform maintainers	`ASG_CloudPlatform_Maintainers`	Assigned	Ja (bestätige das Pop-up)	Keine. Die Mitgliedschaft kommt aus PIM.

Die Einstellung Microsoft Entra roles can be assigned to the group kann nur beim Erstellen der Gruppe gewählt werden.

2. Management group¶

Wenn der Kunde sie nicht erstellt hat, erstelle die Platform management group (Management groups, Create):

Feld	Wert
Management group ID	Eine kurze ID ohne Leerzeichen, zum Beispiel `<customer>-platform`. Kann später nicht geändert werden.
Display name	Ein lesbarer Name

Diese ID wird zu management_group_organization_id (Mapping). Lege die Plattform- subscriptions darunter ab (Voraussetzungen).

3. Administrative Unit¶

Erstelle eine Administrative Unit (Microsoft Entra ID, Administrative units, Add):

Feld	Wert
Name	Zum Beispiel `AU_CloudPlatform`
Description	Wofür sie verwendet wird
Restricted management administrative unit	Nein

Kopiere ihre Object ID. Sie wird zu SpokeCommon.tenantinfo.AdministrativeUnitId in mcp.json. Die spoke-pipeline erstellt die spoke-Gruppen in dieser Unit (Neuer Spoke).

4. RBAC- und Verzeichnisrollen für die Maintainers-Gruppe¶

Weise diese der Maintainers-Gruppe zu, damit niemand sie dauerhaft hält.

Auf der Platform management group¶

Öffne Management groups, die Platform management group, Access control (IAM).
Add, Add role assignment. Wähle die Rolle Owner (unter Privileged administrator roles).
Wähle als Mitglied die Maintainers-Gruppe.
Wähle auf dem Tab Conditions die Option Allow user to assign all roles (highly privileged). Das Deployment erstellt Rollen- zuweisungen, Owner ohne diese Bedingung reicht also nicht.
Review + assign.

Auf der Administrative Unit¶

Öffne die Administrative Unit, Roles and administrators. Weise der Maintainers-Gruppe jede dieser Rollen zu:

Groups Administrator
User Administrator

Jeweils: Zuweisungstyp Active, permanent, und eine Begründung, die sagt, dass die Gruppe keine aktiven Mitglieder hat und dass die Mitgliedschaft über PIM-Flows für Just-in-time- und Just-enough-Zugriff vergeben wird.

Im Verzeichnis¶

Öffne Microsoft Entra ID, Roles and administrators, Application Developer, und weise sie der Maintainers-Gruppe auf dieselbe Weise zu (active, permanent, dieselbe Begründung). Sie erlaubt dem Team, die Deployment service principals zu erstellen.

5. PIM-Flow¶

Die Engineers-Gruppe wird ein eligible Mitglied der Maintainers-Gruppe. Engineers aktivieren die Mitgliedschaft, wenn sie arbeiten müssen.

Öffne Microsoft Entra Privileged Identity Management, Groups, Discover groups.
Suche die Maintainers-Gruppe, wähle sie aus und wähle Manage groups. Bestätige das Pop-up und warte, bis es fertig ist.
Öffne die Maintainers-Gruppe, Assignments, Add assignments. Rolle: Member. Mitglied: die Engineers-Gruppe. Behalte die Standardeinstellungen, die die Zuweisung für ein Jahr eligible machen. Erneuere sie, bevor sie abläuft.
Öffne Settings, die Rolle Member, Edit. Wähle Require approval to activate und lege die Genehmiger fest. Wähle Genehmiger, die zum Betriebsmodell passen:
- Im Managed-Modell sind die Genehmiger meist Mitglieder des Plattform-Teams selbst (ein zweiter Engineer genehmigt) oder eine Kundengruppe, wie im Vertrag vereinbart.
- Im Eigenbetrieb verwendest du eine Gruppe aus den Security- oder Cloud-Platform-Ownern des Kunden oder einen zweiten Engineer des Teams.

Engineers aktivieren die Gruppenzuweisung dann in PIM (My roles, Groups, Activate), bevor sie arbeiten. Das ist auch der erste Check in den Voraussetzungs-Checks.

6. Deployment service principals¶

Erstelle pro Plattformumgebung (canary und prod) einen service principal. Die pipelines verwenden ihn, um sich bei Azure anzumelden. mcp.json verweist darauf als Azure.TerraformState.Hub.ServicePrincipalId (und .Spoke. für spokes). Du kannst einen service principal für hub und spokes verwenden oder getrennte. Mit getrennten kannst du der spoke-Identität ihre Verzeichnis- berechtigungen geben, ohne sie der hub-Identität zu geben.

Aktiviere zuerst PIM

Zum Erstellen von service principals und Rollenzuweisungen brauchst du die Rechte der Maintainers-Gruppe. Aktiviere deine PIM- Zuweisung, bevor du beginnst.

Melde dich im Tenant des Kunden an, erstelle dann die service principals und gib ihnen Owner auf der Platform management group:

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.
}

Das Namensmuster SPN_<short-name>_LZ_<ENV> ist ein Beispiel aus früheren Runbooks; verwende deinen eigenen Standard.

Bewahre das Secret sicher auf

az ad sp create-for-rbac erstellt ein Client Secret und gibt es einmal aus. Lege es in dem Secret Store ab, den dein Team verwendet (als Secret-Wert, nie im Klartext, im Chat oder im Repository). Besser: Verwende Federated Credentials und verzichte auf das Secret (GitHub-Variante und Workload Identity Federation für Azure-DevOps- service connections). Die update-spn-pipeline im Code-Repository speichert und rotiert ein Deployment-Secret im hub Key Vault (Verantwortlichkeiten).

Berechtigungen der spoke-Identität¶

Die Identität, die spokes deployt, braucht mehr als Azure RBAC, weil das spoke canvas Entra-ID-Gruppen, service principals und PIM-Einstellungen erstellt. In den Runbooks der GitHub-Variante waren das:

Wo	Berechtigung
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
Platform management group	Genug, um subscriptions zu verschieben und Rollenzuweisungen zu erstellen. Die Owner-Zuweisung der Deployment-Identität deckt das ab.

Wenn du spokes mit zwei Spoke-Identitäten deployst (canary und Produktion), gib jeder die Rolle Owner auf der landing-zone- management-group ihrer eigenen Umgebung und die Rolle Groups Administrator auf der Administrative Unit. Mehr dazu in Die spoke-pipeline vorbereiten.

Das Erteilen der Graph-Berechtigungen braucht den Admin Consent von jemandem mit der passenden Verzeichnisrolle. Frage den Administrator des Kunden oder nutze deine per PIM aktivierte Rolle, falls du sie hast. Die maßgebliche Liste für deine Version steht in der Dokumentation des spoke canvas im Code-Repository, das du fixiert hast (How to use spoke deployment, Abschnitt Prerequisites, Pipeline, Service principal). Gleiche die Liste damit ab, bevor du den Consent anfragst.

7. Service connections (Azure DevOps)¶

Erstelle für jeden Deployment service principal eine Azure Resource Manager service connection im Azure-DevOps-Projekt (Project settings, Service connections, New service connection):

Feld	Wert
Identity type	App registration or managed identity (manual)
Credential	Secret oder Workload Identity Federation, wenn du Federated Credentials eingerichtet hast
Scope level	Subscription: die management-subscription dieser Plattformumgebung
Subscription ID and name	Die management-subscription von canary oder von prod
Application (client) ID	Die Client ID des service principal
Directory (tenant) ID	Die Tenant ID des Kunden
Client secret	Das Secret, wenn du eines verwendest
Service connection name	Der Name, den `pipelines/variables.yaml` erwartet, zum Beispiel `<env>.serviceConnectionNameHub` (Pipelines)

Wähle Verify, dann Save. Verwende getrennte service connections für canary und prod. Das ist Teil der Security-Baseline.

Service connections auf management-group-Ebene, wie sie die separate spoke-canvas-pipeline nutzt, sind in Die spoke-pipeline vorbereiten beschrieben.

Wenn das Code-Repository auf einem anderen Host liegt als das Azure DevOps des Kunden (zum Beispiel im Managed-Modell, wo es von einer GitHub-Enterprise-Instanz synchronisiert wird), brauchst du außerdem eine service connection dieses Hosts für die Repository-Ressource mcp-code. Siehe Repositorys.

Für den Agent Pool braucht die service connection der infrastructure-pipeline Contributor oder Owner auf der subscription, die die Job runners hält, und der Pool-Service braucht Rechte in Azure DevOps. Siehe Pipelines und Agents.

Checkliste¶

[ ] Zwei Gruppen existieren; die Maintainers-Gruppe ist role-assignable und hat keine Mitglieder
[ ] Platform management group existiert; subscriptions sind darunter abgelegt
[ ] Administrative Unit existiert; ihre Object ID ist notiert
[ ] Maintainers-Gruppe: Owner (mit All-roles-Bedingung) auf der management group; Groups Administrator und User Administrator auf der Administrative Unit; Application Developer im Verzeichnis
[ ] PIM: Engineers-Gruppe ist eligible für die Maintainers-Gruppe, mit Genehmigung
[ ] Deployment service principals existieren pro Plattformumgebung, mit gespeicherten Secrets oder eingerichteten Federated Credentials
[ ] Spoke-Identität: Graph-Berechtigungen mit Admin Consent, Rolle auf der Administrative Unit, Rolle auf dem State Storage
[ ] Service connections existieren, verifiziert, getrennt für canary und prod
[ ] Wenn spokes Azure-DevOps- oder GitHub-Ressourcen erstellen: Spoke-Integrationen vorbereiten ist erledigt