spoke ändern¶

Standardänderung: Änderungen am spoke canvas. Das umfasst den RBAC-Owner, Informationen zum Service Principal, Netzwerk und so weiter.

Auswirkung: Terraform gleicht den bestehenden spoke mit seiner bearbeiteten JSON-Datei ab. Es werden nur die Unterschiede angewendet.

Anfragefelder¶

Wie bei Neuer spoke: Name, Begründung, Umgebung, Nutzungsart, Exposition zum öffentlichen Internet, IP-Bereich/-Größe, Subnetzname/-größe/Delegierungen/Service Endpoints, welches Team Zugriff benötigt, und Kommentare. Fülle nur die Felder aus, die sich ändern.

Wie es funktioniert¶

Es gibt keine separate „Update“-Pipeline. Du bearbeitest die JSON-Datei des spokes und führst spoke für diese Datei aus. Der spoke behält seine Identität über seinen Terraform-state-Key spoke_<workloadShortName>_<environment>.tfstate. Daher gilt:

Ändere niemals workloadShortName oder environment eines bestehenden spokes. Jede dieser Änderungen erzeugt einen neuen state key und einen vollständigen zweiten spoke, während der alte unverändert bleibt. Die Datei umzubenennen oder in einen anderen Ordner zu verschieben ist unbedenklich: Der Dateiname wird nur für Job- und Artefaktnamen verwendet.

Was du ändern kannst und was passiert¶

Änderung	JSON-Feld	Was der Plan zeigen sollte
Subnetz hinzufügen	an `network[].subnets[]` anhängen	Subnetz erstellt + NSG-Zuordnung (+ Zuordnung der Route Table)
Subnetz-Delegierungen oder Service Endpoints ändern	`subnets[].delegations` / `.serviceEndpoints`	Subnetz aktualisiert
Adressbereich eines Subnetzes oder VNets ändern	`subnets[].addressPrefix`, `network[].addressPrefix`	Update oder Ersetzung. Azure verweigert die Größenänderung eines Subnetzes, in dem sich Ressourcen befinden. Wenn der Plan must be replaced anzeigt, stoppe und plane eine Migration.
NSG-Regeln hinzufügen oder ändern	`networksecuritygroups[].rules[]`	Regeln erstellt oder aktualisiert. Ändere nicht die `priority` einer bestehenden Regel: Die Regel wird neu erstellt, und das kann fehlschlagen und die NSG inkonsistent hinterlassen. Füge eine neue Regel mit neuem Namen und neuer Priorität hinzu und entferne die alte Regel in einer späteren Änderung.
Route Table / Routen hinzufügen	`routetables[]` und `subnets[].linkedroutetablename`	Route Table + Zuordnung
Einem weiteren Team Zugriff gewähren	an `adInfo.ProductTeamGroupNames` anhängen	PIM-Eligibility oder aktive Mitgliedschaft für die neue Gruppe
PIM-Verhalten ändern	`adInfo.PIMGroupConfig.{Readers,Contributors,Owners}`	PIM-Einstellungen aktualisiert
Ändern, wer eine Data-plane-Rolle nutzen darf (Key Vault, Storage, weitere)	`adInfo.PIMAssignments`	Rollenzuweisungen und PIM-Eligibility auf subscription-Ebene. Siehe RBAC und PIM.
Ein Azure-DevOps-Repository und eine service connection hinzufügen	`azdo`	Neues Repo und neue service connection. Vorher vorbereiten: Spoke-Integrationen.
Ein GitHub-Repository mit Federated Credentials hinzufügen	`extensions.github`	Neues Repo, Federated Credentials, Actions-Secrets. Siehe Spoke-Integrationen.
Den GitHub-Federated-Credentials eine Umgebung hinzufügen	`extensions.github.environments`	Ein weiteres Federated Credential
Eine service connection auf Federated Credentials umstellen	`azdo.useFederatedCredentials`	Die service connection nutzt Workload Identity Federation. Es wird kein Secret erzeugt. Lies den Plan, um zu sehen, was sich ändert.
Ein per IPAM zugewiesenes Netzwerk in der Größe ändern	`numberOfIpAddresses`	Behandle es wie eine Änderung des Adressbereichs: Lies den Plan und stoppe bei jeder Ersetzung.
Tags ändern (vom Team verantwortet)	`tags`	Tags von subscription und Ressourcen aktualisiert
subscription in eine andere management group verschieben	`managementGroupId`	Zuordnung zur management group
subscription umbenennen	`azureSubscriptionName`	subscription umbenannt
Internet-Routing über den Hub aktivieren oder deaktivieren	`network[].InternetSecurityEnabled`	Hub-Verbindung aktualisiert
Region hinzufügen	`targetRegions.additional` + ein `network[]`-Eintrag mit dieser `region`	resource group, VNet, LAW, KV, Storage pro Region

Owner ändern (RBAC-Owner)¶

Die Entra ID-Gruppen des spokes werden mit owners aus adInfo.ad_OwnersMembers (E-Mail-Adressen) und adInfo.ad_OwnersMembersUPN erstellt. In modules/ad_groups/main.tf stehen owners und members unter lifecycle { ignore_changes = [owners, members] }. Eine Bearbeitung dieser Listen nach dem ersten Deployment hat keine Wirkung.

Ändere den Owner stattdessen auf eine dieser Arten:

Ändere, wer in den Team-Gruppen aus ProductTeamGroupNames (Entra ID) Mitglied ist, oder
füge ProductTeamGroupNames eine andere Team-Gruppe hinzu und entferne die alte, und führe dann die Pipeline aus, oder
ändere die Owner der SG_SPOKE_<wl>_<env>_*-Gruppen direkt in Entra ID. Terraform ignoriert diese, daher wird die Änderung nicht zurückgesetzt, sie ist aber auch nicht in Git dokumentiert. Dokumentiere sie im Change-Ticket.

Informationen zum Service Principal ändern¶

Der Service Principal <SPNNamePrefix><wl>-<env> wird vom spoke canvas verwaltet:

Secret rotieren: Das Secret liegt im Key Vault des spokes, sofern keine federated credentials konfiguriert sind. Es wird von einer time_rotating-Ressource (modules/ad_service_principal/main.tf) mit rotation_days = SpokeCommon.tenantinfo.SPNSecretrotationPeriod neu erzeugt. Das neue Secret wird beim ersten spoke-Lauf nach Ablauf des Zeitraums erstellt. Führe die spoke-Pipeline daher regelmäßig aus, sonst läuft das Secret ab.
Azure DevOps service connection auf workload identity federation umstellen: Setze azdo.useFederatedCredentials auf true.
Graph-Berechtigungen: adInfo.SPNGraphPermissions wird vom Terraform-Code gelesen. Das Schema definiert es nicht, erlaubt es aber, weil adInfo zusätzliche Keys akzeptiert. Prüfe den Plan sorgfältig.

Schritte¶

Bearbeite die spoke-JSON in einem Branch (siehe Änderungen sicher durchführen). Ein einheitlicher Branch-Name hilft, zum Beispiel feature/SpokeUpdate-<request id>-<workload short name>-<environment>. Manche Änderungen sind wegen Einschränkungen von Terraform oder Azure nicht möglich. Zum Beispiel kannst du kein Subnetz ändern, das virtuelle Maschinen nutzen.
Führe spoke aus, mit spokeGlob auf genau diese eine Datei gesetzt. Verwende vorzugsweise den Modus ApproveModifications, damit du den Plan lesen kannst, bevor er angewendet wird. Die Referenz-Entry-Dateien haben mode: Apply fest codiert; siehe Mode und whatIf zur Laufzeit bereitstellen.
Lies den Plan. Erwartet werden nur die Änderungen aus der obigen Tabelle. Stoppe bei jedem destroy / must be replaced, das du nicht beabsichtigt hast. Dazu gehört ein destroy von azurerm_management_group_subscription_association (ein bekanntes Problem, siehe Bekannte Probleme).
Genehmige oder wende an.

Prüfen¶

Prüfe das geänderte Element im Azure portal oder in Entra ID und bitte das anfragende Team um Bestätigung.

Rollback¶

Mache die JSON-Änderung rückgängig und führe spoke erneut für die Datei aus.