IP groups (hinzufügen, ändern, entfernen)¶

Standardänderung: Eine IP group erstellen oder ändern in der Hub-Firewall-Konfiguration.

Auswirkung: Eine IP group (azurerm_ip_group) wird in der connectivity-Resource-Group jeder Region, die die Datei deployt, erstellt, aktualisiert oder gelöscht. Regeln, die auf die Gruppe verweisen, folgen automatisch. Nur der firewall layer ändert sich.

IP groups sind die Bausteine der Firewallregeln. Zu den Design-Hinweisen (wann eine Gruppe sinnvoll ist, Benennung, Umbenennen in zwei Schritten) siehe Richtlinien für Firewallregeln und IP groups. Zu den Regeldateien, die die Gruppen verwenden, siehe Firewallregeln. Um die Dateien mit Vorschlägen und Validierung zu bearbeiten, siehe Die JSON-Dateien mit Schema-Unterstützung bearbeiten.

Anfragefelder¶

Anfragefeld	Wo es hingehört	Hinweise
Name	`ip_group.name` und der Dateiname	Siehe Benennung. Eindeutig in der Plattformumgebung.
Zweck	pull-request-Beschreibung	Was die Gruppe darstellt und welcher workload sie besitzt.
Adressen	`ip_group.cidrs`	CIDR-Bereiche oder einzelne IPv4-Adressen.
Verwendet von	pull-request-Beschreibung	Welche Regeln die Gruppe verwenden oder verwenden werden.
Umgebung	Plattformumgebung und Region-Ordner	Erstelle die Datei in jeder Plattformumgebung, die sie braucht (`canary` und `prod`).
Begründung	pull request / Change-Eintrag

Wo die Dateien liegen¶

IP-group-Dateien sind JSON-Dateien in einem ip_groups-Ordner. Der Ort wird in <env-folder>/<region>/firewall.auto.tfvars festgelegt (siehe Firewallregeln):

Globale Gruppen in <env-folder>/ip_groups/, in jeder Region deployt.
Regionale Gruppen in <env-folder>/<region>/ip_groups/. Eine regionale Datei mit demselben Dateinamen wie eine globale Datei ersetzt diese in der betreffenden Region.

Behalte den Ordnernamen ip_groups bei: Die Konfigurationstests finden die Gruppen darüber. Eine Datei enthält eine IP group. Unterordner pro workload sind erlaubt.

Manche Plattformen halten alle IP groups nur im globalen Ordner, weil die Gruppen in jeder Region gleich sind. Wähle einen Ansatz und dokumentiere ihn. Jede Plattformumgebung hat einen eigenen Ordner, die Datei muss also in canary und in prod existieren.

IP-group-JSON¶

{
  "ip_group": {
    "name": "ipgrp-azure-app1-prod-web",
    "cidrs": [
      "10.20.4.0/26",
      "10.20.5.16/32"
    ]
  }
}

Property	Pflicht	Regeln
`ip_group`	ja	Die einzige Property auf oberster Ebene.
`name`	ja	Eindeutig. Er ist der Azure-Name und der Name, mit dem Regeln auf die Gruppe verweisen.
`cidrs`	ja	Eine Liste von Strings. Jeder String ist eine IPv4-Adresse, optional mit Präfixlänge (`/0` bis `/32`). Ein einzelner Host kann mit oder ohne `/32` geschrieben werden. Verwende durchgängig einen Stil.

Weitere Properties sind nicht erlaubt.

Benennung¶

Verwende ein Muster, das dem Leser sagt, was die Gruppe enthält. Zwei Muster sind im Einsatz. Wähle eines für deine Plattform:

Muster	Beispiel	Verwendung
`ipgrp-<description>` für Plattform-Gruppen, `ipgrp-<workload>-<description>-<environment>` für workload-Gruppen	`ipgrp-hub`, `ipgrp-app1-web-prod`	Kurz. Verwendet in den Richtlinien.
`ipgrp-<onprem or azure>-<workload>-<environment>-<use>`	`ipgrp-azure-app1-prod-web`, `ipgrp-onprem-dns`	Zeigt, wo die Adressen liegen. Wähle `azure`, wenn beides zutrifft. Lass workload oder Umgebung weg, wenn sie nicht zutreffen.

Was auch immer du wählst: Der Name sagt, was die Adressen sind, nicht, welche Regel sie verwendet.

Eine IP group erstellen¶

Sammle die Anfragefelder. Prüfe, dass die Gruppe noch nicht existiert (durchsuche die ip_groups-Ordner nach der Adresse).
Erstelle einen branch (Eine Änderung sicher durchführen).
Erstelle <name>.json im ip_groups-Ordner der Umgebung canary und fülle sie aus.
Validiere die Datei gegen das Schema (Die JSON-Dateien mit Schema-Unterstützung bearbeiten). Prüfe die Schreibweise jeder Adresse.
Kopiere die Datei in den ip_groups-Ordner der Umgebung prod (und in jeden Region-Ordner, der sie braucht).
Führe die Konfigurationstests aus, committe und öffne einen pull request. Reviewer verwenden das Runbook zur IP-group-Änderung.
Nach der Genehmigung deployst du canary, prüfst das Ergebnis und deployst dann prod (Deployment). Der plan zeigt azurerm_ip_group als hinzugefügt und sonst nichts.

Wenn du die Gruppe zusammen mit den Regeln erstellst, die sie verwenden, lege beides in einen pull request. Die Gruppe muss im selben Deployment oder in einem früheren existieren.

Eine IP group ändern¶

Bearbeite die cidrs-Liste in der Datei der Umgebung canary.
Mache dieselbe Änderung in der prod-Datei. Überschreibe sie mit der validierten Datei, wenn beide Umgebungen gleich sein sollen.
Pull request, Review, canary deployen, prüfen, prod deployen.

Wenn du die Adressen einer Gruppe änderst, änderst du jede Regel, die die Gruppe verwendet. Lies die Liste der Regeln, die sie verwenden, bevor du sie änderst, und beschreibe die Auswirkung im pull request.

Eine IP group umbenennen oder entfernen¶

Eine Regel, die auf eine nicht mehr existierende Gruppe verweist, lässt das Deployment fehlschlagen. Gehe in zwei pull requests vor, wie in Eine IP group in zwei Schritten umbenennen oder entfernen beschrieben.

Do und Don't¶

Do	Don't
Verwende einen klaren Namen, der den Zweck widerspiegelt.	Unzusammenhängende Subnets in einer Gruppe mischen.
Validiere die Datei gegen das Schema.	Adressen verwenden, die nicht für den Zweck abgegrenzt oder vereinbart sind.
Nutze den normalen branch- und pull-request-Prozess.	Ohne Review direkt auf `main` committen.
Halte die Namenskonvention über alle Gruppen hinweg einheitlich.	Eine Gruppe für Adressen anlegen, die nur eine Regel verwendet. Setze sie in die Regel.
Teste zuerst in `canary`.	Eine Gruppe in derselben Änderung umbenennen oder löschen, die auch die Regeln anpasst.

Prüfen¶

Azure-Portal → IP Groups in der connectivity-Resource-Group: Die Gruppe existiert und hat die Adressen.
Firewall Policies → die Policy der Region → die Regeln, die die Gruppe verwenden, zeigen den Gruppennamen.

Rollback¶

Reverte den pull request und führe hub erneut aus.

Häufige Probleme¶

Symptom	Ursache
Konfigurationstest `Referenced IP Group '<x>' should exist`	Der Name in der Regel weicht vom Gruppennamen ab, oder die Datei liegt nicht in einem Ordner namens `ip_groups`.
Schemafehler bei `cidrs`	Ein Eintrag ist keine IPv4-Adresse oder kein CIDR, zum Beispiel ein fehlendes Oktett oder ein Präfix über `/32`.
Schemafehler bei der Datei	Eine andere Property als `name` und `cidrs` ist vorhanden, oder `ip_group` fehlt.
Der plan will die Gruppe zerstören und neu erstellen	Der `name` hat sich geändert. Der Name ist die Identität der Gruppe.
Regeln verwenden noch alte Adressen	Die Änderung ist in dieser Plattformumgebung oder Region noch nicht deployt.