Technische Architekturnotizen: layers und Validierung von Firewallregeln¶

Zwei Design-Notizen, die erklären, warum Teile der Plattform so gebaut sind, wie sie sind: wie das hub-Deployment in layers aufgeteilt ist und wie Änderungen an Firewallregeln in einem pull request validiert werden. Was die layers heute enthalten und in welcher Reihenfolge sie laufen, steht unter Deployment-layers.

Warum der hub in layers aufgeteilt ist¶

Das Deployment wurde nach einem layer assessment in layers umstrukturiert. Das Prinzip: den hub in Teile aufteilen, die jeweils einen Zweck haben, damit die Komplexität sinkt und jeder Teil verwaltet und geändert werden kann, ohne die anderen anzufassen.

Das Assessment bewertete jeden layer nach drei Punkten: seinem Zweck, den Komponenten, die zu ihm gehören, und der Begründung, warum er getrennt bleibt. Die Begründung lief jedes Mal auf dieselben Gründe hinaus:

Grund	Bedeutung
Abhängigkeit	Manches muss existieren, bevor anderes darauf aufbauen kann (management groups und Policies vor assignments, ein hub vor spokes)
Isolation	Eine Änderung an einem layer darf die Komponenten eines anderen nicht beeinflussen
Geschwindigkeit	Teile, die sich oft ändern (Firewallregeln, Policies, Monitoring), deployen schneller, wenn sie einen eigenen, kleineren state haben
Zuständigkeit	Komponenten, die zu einem Thema gehören (Konnektivität, Management, Identität), lassen sich gemeinsam leichter verwalten und prüfen

Layer für layer¶

Layer	Zweck	Warum getrennt
`foundation`	Die Baseline für die Plattform, pro Region. Regionsweite Komponenten, auf denen die anderen layers aufbauen: action groups, der DDoS-Schutzplan, management groups (einmal pro tenant), policy definitions und initiatives	Er wird in einer Region als Erstes deployt, und andere nutzen, was er anlegt
`connectivity`	Alles für die Konnektivität innerhalb von Azure, zwischen Regionen und zu on-premises: Virtual WAN und hub, Gateways, ExpressRoute, DNS Resolver, Bastion, Application Gateway und WAF, Azure Firewall und ihre Policy, IP groups, route tables, network security groups	Ein Ort, um alle Netzwerkkomponenten zu konfigurieren und zu prüfen
`management`	Die Komponenten, die die Umgebung verwalten und überwachen: Log Analytics, Azure Monitor und Alerts, Automation, Storage, Key Vault, Sentinel	Monitoring- und Management-Komponenten deployen schnell und lassen sich allein leichter stabil betreiben
`identity`	Das Netzwerk für Legacy-Identitätsdienste wie Active-Directory-Domain-Controller: ein virtuelles Netzwerk mit network security groups und route tables	Identitätskomponenten bleiben von Änderungen an anderen Komponenten isoliert, und Domain Controller bekommen ein eigenes Subnet mit den passenden Regeln
`postdeployment`	Konfiguration, nachdem die Umgebung existiert: policy assignments und exemptions, diagnostic settings, Defender for Cloud	Die Umgebung lässt sich leichter an die Anforderungen der Organisation anpassen, und das lässt sich wiederholen, ohne Infrastruktur neu zu deployen
`firewall`	Die rule collection groups, rule collections und Regeln der Firewall (Netzwerk, Anwendung und NAT)	Regeln ändern sich oft. Ein eigener layer macht es einfacher, sie korrekt anzuwenden, und eine Regeländerung deutlich schneller

Die Abhängigkeiten zwischen den layers bestimmen die Reihenfolge: zuerst foundation, dann connectivity, dann management, identity und firewall, dann postdeployment (Deployment-layers).

Der Code hat sich seit dem Assessment weiterentwickelt

Das Assessment führt die privaten DNS-Zonen für private link im foundation layer auf. Der aktuelle Code legt die Zonen im connectivity layer an und behält im foundation layer nur die Definitionen der privaten DNS-Policies. Verlass dich für den aktuellen Inhalt auf Deployment-layers und nutze diese Seite für die Begründung.

So nutzt du das, wenn du eine Komponente hinzufügst¶

Wenn du etwas Neues hinzufügst, frage dich, wohin es gehört:

Was muss existieren, bevor es angelegt werden kann? Es gehört in einen späteren layer als dieses.
Ändert es sich oft oder durch ein anderes Team? Gib ihm einen eigenen layer oder ordne es dem layer zu, der sich im gleichen Tempo ändert.
Könnte ein Fehler darin etwas Unbeteiligtes beschädigen? Dann halte es aus diesem layer heraus.
Hat dasselbe Thema bereits einen layer? Leg es dort ab.

Siehe Neue Funktionalität bauen.

Firewallregeln in einem pull request validieren¶

Firewallregeln sind JSON-Dateien im Konfigurations-Repository. Ein Fehler darin fällt erst auf, wenn hub läuft, und ein fehlgeschlagenes firewall-apply kann den Datenverkehr unterbrechen (Bekannte Probleme). Eine Continuous-Integration-(CI-)pipeline auf dem pull request findet die Fehler früh, bevor irgendetwas nach Azure deployt wird, und sagt dem Antragsteller, was er korrigieren muss.

Wie es funktioniert¶

Die CI-pipeline ist eine YAML-pipeline, die im Konfigurations-Repository neben den Firewallregel-Dateien liegt.
Sie führt ein PowerShell-Skript über das gesamte Repository aus. Das Skript wählt die JSON-Dateien mit einem Pfadfilter aus, sodass es nur Firewallregel-Dateien betrachtet und keine anderen Dateien.
Wenn eine Prüfung fehlschlägt, meldet die pipeline einen Fehler, und der pull request kann nicht abgeschlossen werden.

Was sie prüft¶

Prüfung	Warum sie wichtig ist
Die Regelprioritäten liegen innerhalb der Grenzen von Azure	Eine Priorität außerhalb des Bereichs schlägt beim apply fehl
Die Prioritäten sind eindeutig	Zwei rule collections mit derselben Priorität stehen im Konflikt
Referenzierte IP groups existieren	Eine Regel, die auf eine fehlende Gruppe verweist, lässt das apply fehlschlagen

Die Prüfungen stammen aus der Checkliste der Reviewer in Pull-request-Review: Die pipeline automatisiert die Teile, die eine Maschine besser kann als ein Reviewer.

Einrichten¶

Lege die pipeline-Datei im Ordner pipelines/ des Konfigurations-Repositorys ab und das PowerShell-Skript im Stammordner, wo die pipeline es erwartet.
Erstelle im Projekt eine neue pipeline aus dieser YAML-Datei. Benenne sie so um, dass ihr Name Firewall Rule validator enthält.
Füge die pipeline als Build-Validierung zur Branch Policy des main-Branches des Konfigurations-Repositorys hinzu. Die Standardwerte der Parameter passen.

Ab dann führt jeder pull request, der auf main zielt, die Validierung aus. Prüfe das Ergebnis als Teil des Reviews (Eine Änderung sicher durchführen).

Status

Diese Validierung wurde für eine einzelne Plattform entwickelt und getestet. Die Absicht war, pipeline und Skript Teil des Code-Repositorys zu machen, damit jede Plattform sie bekommt. Prüfe, ob deine Version des Code-Repositorys sie enthält; die oben genannten Dateipfade können dann abweichen. Die Config tests des Code-Repositorys führen zu Beginn jedes hub-Laufs eine ähnliche Prüfung aus (Pipelines und Workflows), die dieselben Fehler später abfängt, bevor Terraform startet. Bekannte Grenzen der Validatoren stehen unter Bekannte Probleme.