Review van een pull request voor firewallregels¶

Reviewer-runbook voor pull requests die firewallregels of IP-groepen wijzigen. Gebruik het samen met de algemene controles van Pull request review. Het geeft de volgorde van de controles. De redenen erachter staan in Richtlijnen voor firewallregels en IP-groepen.

1. Open de pull request¶

Open het ticket en volg de link naar de pull request in de beschrijving. Zorg dat je bent ingelogd met het account dat bij de juiste omgeving en tenant hoort.

2. Controleer de status (metadata)¶

Doe deze controles voordat je de bestanden leest. Mislukt er een, stuur de pull request dan terug (zo stuur je hem terug) en stop.

Controle	Actie als die mislukt
De pull request is geen draft	Vraag de auteur hem af te maken.
De vereiste checks (validatiepipeline) zijn geslaagd	Zet de pipeline opnieuw in de queue als het resultaat is verlopen. Is hij mislukt, stuur de pull request dan terug met de fout.
Er zijn geen merge conflicts	De auteur lost ze op.
Alle comments zijn afgehandeld	De auteur handelt ze af.
Er is een ticket gekoppeld	Koppel het. Heeft het platform het niet nodig, maak de controle dan optioneel.

3. Review de bestanden¶

Doe dit voor elk bestand in de pull request. Open de weergave Files.

3.1 Canary en prod¶

Een firewallwijziging vraagt om een identieke wijziging in de map canary en in de map prod, zodat de wijziging eerst op canary kan worden getest. Ontbreekt een van de twee, stuur hem dan terug en geef aan welk bestand ontbreekt. De uitzondering is een regel die voor slechts één omgeving bedoeld is. Dan staat dat in de beschrijving.

3.2 Prioriteiten (alleen als een prioriteit is gewijzigd)¶

Kijk naar de drie collectietypen in de groep:

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

De NAT-collecties hebben een lager getal (een hogere prioriteit) dan de network-collecties.
De network-collecties hebben een lager getal dan de application-collecties.
De prioriteit van de groep zelf is uniek en valt binnen het bereik van de eigenaar (Prioriteiten).

3.3 IP-groepen¶

Als source_ip_groups of destination_ip_groups een waarde heeft, moet de groep bestaan. Controleer dat:

er al een bestand met de naam van de groep in de map ip_groups van de platformomgeving staat (environments/<env>/ip_groups of environments/<env>/<region>/ip_groups), of
de pull request dat bestand toevoegt, in dezelfde map, voor zowel canary als prod.

Zo niet, vraag de auteur dan de definitie toe te voegen.

3.4 Eén brontype en één doeltype¶

Een regel heeft maar één van source_addresses en source_ip_groups.
Een regel heeft maar één van destination_addresses, destination_ip_groups en destination_fqdns.
Een application rule heeft maar één van destination_fqdns en destination_fqdn_tags.

Is er meer dan één ingevuld, vraag dan om een correctie. De config tests vinden de meeste hiervan, maar de controle op de bestemmingen van application rules niet (Bekende problemen), dus kijk er zelf naar.

3.5 Inhoud¶

Het juiste team is eigenaar van het bestand en de regel staat op de juiste plek (globaal of regionaal).
Het regeltype past: een application rule voor internet-FQDN's, een network rule voor de rest.
De bestemming is zo specifiek mogelijk en de poorten zijn exact. Geen * en geen Any zonder schriftelijke reden.
Internetbestemmingen zijn FQDN's, geen IP-adressen.
Geen regels tussen productie en niet-productie, en geen regel die meer opent dan de aanvraag vraagt.
De regel overlapt niet met een andere regel en verbergt er geen.
Als de regel een andere vervangt, wordt de oude regel niet in dezelfde pull request verwijderd.
De beschrijving vermeldt welk verkeer wordt toegestaan: van waar, naar waar, welke poort.

Controleer de goedkeuringen die jouw organisatie voor dit soort regel vereist (bijvoorbeeld van de eigenaar van de bestemming en van security: Wat de review gewoonlijk controleert).

4. Eindreview¶

Alle controles zijn in orde: keur de pull request goed.
Er klopt iets niet: geef duidelijke feedback, zet het ticket terug op New en wijs het toe aan de auteur.
Na goedkeuren en mergen rol je uit: Uitrol van firewallregels.