Review eines pull requests für Firewallregeln¶

Reviewer-Runbook für pull requests, die Firewallregeln oder IP groups ändern. Verwende es zusammen mit den allgemeinen Prüfungen aus dem Pull-Request-Review. Es nennt die Reihenfolge der Prüfungen. Die Gründe dafür stehen in den Richtlinien für Firewallregeln und IP groups.

1. Den pull request öffnen¶

Öffne das Ticket und folge dem Link zum pull request in der Beschreibung. Stelle sicher, dass du mit dem Konto angemeldet bist, das zur richtigen Umgebung und zum richtigen Tenant gehört.

2. Den Status prüfen (Metadaten)¶

Mache diese Prüfungen, bevor du die Dateien liest. Wenn eine fehlschlägt, schicke den pull request zurück (so schickst du ihn zurück) und höre auf.

Prüfung	Aktion, wenn sie fehlschlägt
Der pull request ist kein Draft	Bitte den Autor, ihn fertigzustellen.
Die erforderlichen Checks (Validierungs-pipeline) sind bestanden	Stelle die pipeline erneut in die Queue, wenn das Ergebnis abgelaufen ist. Wenn sie fehlgeschlagen ist, schicke ihn mit dem Fehler zurück.
Es gibt keine Merge-Konflikte	Der Autor löst sie auf.
Alle Kommentare sind aufgelöst	Der Autor löst sie auf.
Ein Ticket ist verknüpft	Verknüpfe es. Wenn die Plattform es nicht braucht, mache die Prüfung optional.

3. Die Dateien prüfen¶

Mache das für jede Datei im pull request. Öffne die Ansicht Files.

3.1 Canary und prod¶

Eine Firewall-Änderung braucht eine identische Änderung im Ordner canary und im Ordner prod, damit die Änderung zuerst auf canary getestet werden kann. Wenn eine von beiden fehlt, schicke ihn zurück und nenne die fehlende Datei. Die Ausnahme ist eine Regel, die nur für eine Umgebung gedacht ist. Dann steht das in der Beschreibung.

3.2 Prioritäten (nur wenn sich eine Priorität geändert hat)¶

Sieh dir die drei Collection-Typen in der Gruppe an:

{
  "rule_collection_group": {
    "nat_rule_collections":         { "NATRules":         { "priority": 100 } },
    "network_rule_collections":     { "NetworkRules":     { "priority": 105 } },
    "application_rule_collections": { "ApplicationRules": { "priority": 110 } }
  }
}

Die NAT-Collections haben eine niedrigere Zahl (eine höhere Priorität) als die Network-Collections.
Die Network-Collections haben eine niedrigere Zahl als die Application-Collections.
Die Priorität der Gruppe selbst ist eindeutig und liegt im Bereich des Owners (Prioritäten).

3.3 IP groups¶

Wenn source_ip_groups oder destination_ip_groups einen Wert hat, muss die Gruppe existieren. Prüfe, dass entweder:

eine Datei mit dem Namen der Gruppe bereits im Ordner ip_groups der Plattform-Umgebung liegt (environments/<env>/ip_groups oder environments/<env>/<region>/ip_groups), oder
der pull request diese Datei im selben Ordner hinzufügt, für canary und prod.

Wenn nicht, bitte den Autor, die Definition hinzuzufügen.

3.4 Ein Source-Typ und ein Destination-Typ¶

Eine Regel hat nur eines von source_addresses und source_ip_groups.
Eine Regel hat nur eines von destination_addresses, destination_ip_groups und destination_fqdns.
Eine Application rule hat nur eines von destination_fqdns und destination_fqdn_tags.

Wenn mehr als eines ausgefüllt ist, bitte um Korrektur. Die Config-Tests finden das meiste davon, aber die Prüfung der Destinations der Application rules nicht (Bekannte Probleme), also sieh sie selbst an.

3.5 Inhalt¶

Das richtige Team besitzt die Datei, und die Regel steht am richtigen Ort (global oder regional).
Der Regeltyp passt: Application rule für Internet-FQDNs, Network rule für den Rest.
Das Ziel ist so spezifisch wie möglich, und die Ports sind exakt. Kein * und kein Any ohne schriftliche Begründung.
Internet-Ziele sind FQDNs, keine IP-Adressen.
Keine Regeln zwischen Produktion und Nicht-Produktion und keine Regel, die mehr öffnet, als die Anfrage verlangt.
Die Regel überschneidet sich nicht mit einer anderen Regel und verdeckt sie nicht.
Wenn die Regel eine andere ersetzt, wird die alte Regel nicht im selben pull request entfernt.
Die Beschreibung nennt, welcher Traffic erlaubt wird: von wo, wohin, welcher Port.

Prüfe die Genehmigungen, die deine Organisation für diese Art von Regel verlangt (zum Beispiel der Owner des Ziels und Security: Was das Review üblicherweise prüft).

4. Abschließendes Review¶

Alle Prüfungen sind in Ordnung: genehmige den pull request.
Etwas stimmt nicht: gib klares Feedback, setze das Ticket zurück auf New und weise es dem Autor zu.
Nach Genehmigung und Merge deployst du: Deployment von Firewallregeln.