Zum Inhalt

Spoke canvas: was ein Deployment erstellt

Das spoke canvas ist die Baseline, die die Plattform in einen spoke deployt. Eine spoke-JSON-Datei geht hinein, und heraus kommt eine subscription mit Netzwerk, Identität, Zugriff und einigen gemeinsamen Bausteinen. Diese Seite erklärt, was erstellt wird, wie sich der Service Principal eines Spokes verhält und was die Deployment-Identität braucht. Zu den Einstellungen der JSON-Datei siehe die Spoke-JSON-Referenz. Zu den Inputs und Outputs des Terraform dahinter siehe die Modulreferenz des Spoke canvas.

Die Dokumentation verwendet spoke canvas und workload environment für dieselbe Sache. Diese Seite verwendet spoke canvas oder spoke.

Zweck

Das Deployment ist vollständig automatisiert und wird pro spoke von einer JSON-Datei gesteuert. Das Ergebnis ist ein Fundament mit Konnektivität, Identität und sicheren Standardwerten, auf dem das Workload-Team seine eigene Lösung aufbaut. Das Team hat genug Freiheit, um seine eigenen Ressourcen zu deployen und zu konfigurieren, aber die Basisressourcen bleiben unter der Kontrolle des Plattform-Teams.

Deployment-Ablauf

flowchart LR
    f["Spoke JSON file<br/>+ common settings"] --> p["Prepare<br/>schema + config tests"]
    p --> s["Subscription layer<br/>name, tags, management group"]
    s --> c["Spoke canvas layer<br/>plan"]
    c --> a["Approve<br/>(optional)"]
    a --> x["Apply"]
    x --> r["Spoke ready:<br/>network, groups, PIM,<br/>service principal, Key Vault, storage"]

Die Teile entsprechen den Stufen eines spoke-Laufs, die unter Pipelines und Workflows beschrieben sind. Zwei Terraform-Roots erledigen die Arbeit, mit getrenntem state: der subscription-layer und der spoke-canvas-layer (Provisioning). Die subscription muss existieren, bevor das canvas deployt wird; warum und wie, steht unter Subscription-Provisioning.

Was in Azure erstellt wird

Ressourcen sind dazu da, dem Workload Grundfunktionen und die Freiheit zu geben, sie zu nutzen. Beispiel: Das Key Vault enthält die Zugangsdaten des Service Principals des Spokes, und das Workload-Team kann es auch für eigene Secrets nutzen. Die eigenen Ressourcen des Workloads lassen sich dann neu deployen, ohne diese Secrets zu verlieren.

Ressource Vorgesehene Nutzung Hinweise
Resource Group (pro Region) Enthält die folgenden Ressourcen Network Watcher verwenden eine eigene, dedizierte Resource Group
Log-Analytics-Workspace Das eigene Logging des Workload-Teams, zum Beispiel eine damit verbundene Application-Insights-Instanz Standardmäßig aktiv
Virtual Network Konnektivität zwischen den Ressourcen des Spokes und zu Ressourcen außerhalb des Spokes Traffic von oder nach außerhalb des Spokes läuft über die hub-firewall und braucht Firewallregeln
Subnets Flexible Anzahl pro Virtual Network Jedes Subnet kann eine NSG, eine Route Table, Service Endpoints und Delegierungen haben
Network Security Groups Eine oder mehrere pro Virtual Network. Eine pro Subnet ist gute Praxis, aber nicht erforderlich Ein Subnet ohne NSG bekommt eine Standard-NSG
Route Tables Für die seltenen Fälle, die bestimmte Routen brauchen Aktuelle Plattformversionen brauchen keine zusätzlichen Routen. Verknüpfe eine Route Table in der spoke-Datei mit einem Subnet
Hub-Verbindung Verbindet das Virtual Network mit dem Virtual Hub der Region Standard peerHub: true. Das DNS des Virtual Network zeigt auf den hub-DNS-Server der Region
Key Vault Zugangsdaten des Service Principals des Spokes und Secrets des Workloads Standardmäßig aktiv. RBAC-Modus. Private Endpoint und öffentlicher Zugriff sind konfigurierbar
Storage Account Für den Workload, zum Beispiel für Terraform-state Standardmäßig aktiv. Verschlüsselt mit einem Customer-Managed Key, der im Key Vault liegt. Private Endpoints und öffentlicher Zugriff sind konfigurierbar
Network Watcher Netzwerkdiagnose Optional. Einer pro Region, wenn aktiviert
Service Principal Die Identität, mit der das Workload-Team deployt Wird immer erstellt. Siehe Service Principal und Zugangsdaten
Azure-DevOps-Repository und Service Connection Ein Ort für den Workload-Code und eine Verbindung für seine pipeline Optional, nur wenn der Block azdo existiert. Das Repository wird nur erstellt, wenn es noch nicht existiert
GitHub-Repository und Federated Credentials Dasselbe für GitHub Optional, über die GitHub-Extension
Shared Services Nutzung von Shared API Management, Container Registry, Service Bus oder Event Hub Optional, über extensions

Ressourcennamen, Standardwerte und die optionalen Blöcke stehen in der Spoke-JSON-Referenz und unter Was erstellt wird.

Virtual Network und Adressraum

Ein Virtual Network wird in der spoke-Datei mit seinem Adressraum konfiguriert. Plane die Größe mit Spielraum zum Wachsen: Den Adressraum eines genutzten Netzwerks zu ändern, ist eine störende Änderung. Nutze die Hinweise zur IP-Dimensionierung.

Schalter für Key Vault und Storage Account

Einstellung Wirkung
resourceconfiguration.keyvault.deploy: false Kein Key Vault und kein Private Endpoint für das Key Vault. Es wird kein Secret des Service Principals gespeichert
resourceconfiguration.storageaccount.deploy: false Kein Storage Account und keine Private Endpoints für Storage
Storage Account aktiviert Das Key Vault wird immer deployt, weil der Storage Account es für die Verschlüsselung mit Customer-Managed Key braucht
Beide auf false Keines von beiden wird erstellt

Service Principal und Zugangsdaten

Für den spoke wird immer ein Service Principal erstellt. Das Workload-Team nutzt ihn, um Ressourcen in der subscription zu deployen und zu konfigurieren. Er ist ständiges Mitglied der Gruppe Owners des Spokes und hat damit Owner auf der subscription. Wenn Key Vault und Storage Account existieren, ist er außerdem Key Vault Administrator auf dem Key Vault und Storage Blob Data Owner auf dem Storage Account.

Welche Zugangsdaten der Service Principal bekommt, hängt davon ab, wie der spoke konfiguriert ist:

Spoke-Konfiguration Zugangsdaten
Azure-DevOps-Service-Connection mit useFederatedCredentials: true, oder GitHub-Extension aktiviert Kein Secret. Die Service Connection oder der Workflow nutzt Workload Identity Federation (OIDC)
Azure-DevOps-Service-Connection ohne useFederatedCredentials (Standard) Ein Secret wird erzeugt. Client-ID und Secret werden im Key Vault gespeichert
Kein Azure DevOps und kein GitHub, Key Vault aktiviert Ein Secret wird erzeugt und im Key Vault gespeichert
Kein Azure DevOps und kein GitHub, Key Vault deaktiviert Der Service Principal wird ohne Zugangsdaten erstellt. Das Workload-Team richtet sie außerhalb des spoke-Deployments ein

Bevorzuge Federated Credentials. Sie beseitigen das Secret und damit die Rotationsarbeit und das Ablaufrisiko (Secret Watcher). Die Gültigkeit erzeugter Secrets stammt aus dem Rotationszeitraum für Secrets in den allgemeinen spoke-Einstellungen; wenn du diesen Wert änderst, entstehen neue Secrets für jeden Service Principal, den das spoke-Deployment steuert. Änderungen an required_resource_access des Service Principals werden ignoriert, um unnötige Updates zu vermeiden (Release-Historie).

Identität in Entra ID

Zwei Bereiche brauchen Identitätskonfiguration.

Bereich Was er braucht
Das Deployment-Framework selbst Einen Deployment-Service-Principal, der Gruppen, Service Principals und PIM-Einstellungen erstellen kann, und eine Administrative Unit, die seine Reichweite begrenzt. Für das Framework werden keine zusätzlichen Gruppen erstellt
Jeder spoke Einen Service Principal und vier Gruppen

Die Administrative Unit

Das Deployment kann nur Gruppen verwalten, die in einer Administrative Unit liegen. So bleiben die Berechtigungen der Deployment-Identität klein: Sie ist Groups Administrator auf dieser Administrative Unit, nicht auf dem ganzen Tenant. Die ID der Administrative Unit gehört zu den allgemeinen spoke-Einstellungen (SpokeCommon.tenantinfo.AdministrativeUnitId in mcp.json).

Gruppen pro spoke

Gruppe (Standardmuster) Rolle auf der subscription Zweck
SG_SPOKE_<wl>_<env>_Owners Owner Volle Kontrolle über die subscription und alles darin, einschließlich der Zugriffsverwaltung
SG_SPOKE_<wl>_<env>_Contributors Contributor Volle Kontrolle über die Ressourcen, ohne die Möglichkeit, Berechtigungen zu setzen
SG_SPOKE_<wl>_<env>_Readers Reader Nur Ansicht
SG_SPOKE_<wl>_<env>_Support Keine Keine eigenen Berechtigungen. Dient dazu, dass Support-Mitarbeiter über PIM die Owners-Gruppe erreichen können

Das Präfix und das genaue Muster stammen aus den Namenseinstellungen der Plattform (Namensgebung und state). Die in ProductTeamGroupNames genannte Team-Gruppe wird Mitglied der Gruppen, aktiv oder PIM-eligible, je nach dem Modus von PIMGroupConfig (nopim, self-approve, approval). Siehe Zugriff, Gruppen und PIM und das Identitäts- und Zugriffsmodell.

Data-Plane-Zugriff über PIM

Reader, Contributor und Owner auf der subscription geben für sich genommen keinen Zugriff auf die Daten in Key Vault und Storage. Das spoke-Deployment weist deshalb Data-Plane-Rollen aus einer eingebauten Rollenzuordnung zu, auf subscription-Ebene. Eine Zuweisung deckt jedes passende Key Vault und jeden passenden Storage Account in der subscription ab, egal ob der spoke sie deployt oder nicht.

Gruppe Standing-Zugriff PIM-eligible Zugriff
Readers Key Vault Reader, Storage Blob Data Reader Keiner
Contributors Key Vault Reader, Storage Blob Data Reader Lese- und Schreibrollen (Key Vault Secrets/Certificates/Crypto User, Storage Blob Data Contributor), selbst genehmigt
Owners Key Vault Reader, Storage Blob Data Reader Rollen mit voller Kontrolle (Key Vault Secrets/Certificates/Crypto Officer, Storage Blob Data Owner), mit Genehmigung

Die Rollenzuordnung, ihre Stufen und ihre PIM-Profile lassen sich überschreiben. Der Override ist über den exakten Azure-Rollennamen adressiert:

Feld Bedeutung
levels Auf welchen Zugriffsstufen die Rolle vergeben wird. levels = [] entfernt die Rolle
pim_profile Welches PIM-Profil gilt (zum Beispiel nopim, self-approve, approval)

Setze ein Feld, um nur dieses Feld zu ändern; ein weggelassenes Feld behält seinen eingebauten Wert. Eine Rolle, die nicht eingebaut ist, muss beide Felder setzen. Jede eingebaute Azure-Rolle kann verwendet werden, zum Beispiel für SQL oder Cosmos DB, ohne Module zu ändern. Ein Override in den allgemeinen spoke-Einstellungen gilt für alle spokes, und adInfo.PIMAssignments in einer spoke-Datei überschreibt ihn für diesen spoke. Ein spoke-Override gewinnt.

"adInfo": {
  "PIMAssignments": {
    "Storage Blob Data Owner": { "pim_profile": "approval" }
  }
}

Was die Deployment-Identität braucht

Ein Deployment-Service-Principal erstellt die spokes. Verwende getrennte Identitäten für die Plattform-Umgebungen canary und Produktion, mit gleichen Berechtigungen. Das Einrichten gehört zu Identität vorbereiten.

Bereich Berechtigung Warum
Azure, die management group der Landing Zones der Plattform-Umgebung (canary oder Produktion) Owner Subscriptions werden darunter platziert. Die Identität konfiguriert Ressourcen und RBAC in den spokes
Entra ID, Administrative Unit Groups Administrator Die spoke-Gruppen erstellen und verwalten
Entra ID, Microsoft-Graph-Anwendungsberechtigungen Siehe unten. Admin Consent ist erforderlich Service Principals und Gruppen erstellen, PIM konfigurieren

Die zwei Quellen dieser Liste unterscheiden sich leicht. Diese Tabelle zeigt, wo sie übereinstimmen und wo nur eine von ihnen einen Eintrag hat. Prüfe sie gegen die Dokumentation der Version, die du betreibst.

Graph-Anwendungsberechtigung In beiden Listen
Application.ReadWrite.All Ja
DelegatedPermissionGrant.ReadWrite.All Ja
Group.Read.All, GroupMember.Read.All, User.Read.All Ja
PrivilegedAccess.ReadWrite.AzureADGroup Ja
PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup Ja
RoleManagement.ReadWrite.Directory Ja
RoleManagementPolicy.ReadWrite.AzureADGroup Ja
RoleManagementPolicy.ReadWrite.Directory Nur eine Liste
AdministrativeUnit.ReadWrite.All Nur eine Liste
RoleManagement.ReadWrite.AzureADGroup, RoleManagementPolicy.Read.AzureADGroup, PrivilegedAccess.Read.AzureADGroup, PrivilegedEligibilitySchedule.Read.AzureADGroup Nur eine Liste (Berechtigungen auf Leseebene)

Die Deployment-Identität braucht außerdem eine Data-Plane-Rolle auf dem Storage Account für den Terraform-state (Deployment-Layer).

Behandle diese Berechtigungen als hoch privilegiert

Diese Graph-Berechtigungen können Service Principals erstellen und PIM-Policies ändern. Beschränke die Deployment-Identität auf die pipeline, die sie braucht, schütze die Service Connection und überwache ihre Nutzung. Im Managed-Service-Modell hält das Plattform-Team diese Identität; im Eigenbetrieb dein eigenes Team.