Skip to content

Firewall Rule Pull Request Review

Reviewer runbook for pull requests that change firewall rules or IP groups. Use it with the general checks of Pull request review. It gives the order of the checks. The reasons behind them are in Firewall rule and IP group guidelines.

1. Open the pull request

Open the ticket, and follow the link to the pull request in the description. Make sure you are signed in with the account that belongs to the right environment and tenant.

2. Check the state (metadata)

Do these checks before you read the files. If one fails, send the pull request back (how to send it back) and stop.

Check Action when it fails
The pull request is not a draft Ask the author to finish it.
The required checks (validation pipeline) passed Queue the pipeline again if the result expired. If it failed, send it back with the error.
There are no merge conflicts The author resolves them.
All comments are resolved The author resolves them.
A ticket is linked Link it. If the platform does not need it, make the check optional.

3. Review the files

Do this for every file in the pull request. Open the Files view.

3.1 Canary and prod

A firewall change needs an identical change in the canary folder and in the prod folder, so that the change can be tested on canary first. If one of the two is missing, send it back and say which file is missing. The exception is a rule that is meant for one environment only. Then the description says so.

3.2 Priorities (only when a priority changed)

Look at the three collection types in the group:

{
  "rule_collection_group": {
    "nat_rule_collections":         { "NATRules":         { "priority": 100 } },
    "network_rule_collections":     { "NetworkRules":     { "priority": 105 } },
    "application_rule_collections": { "ApplicationRules": { "priority": 110 } }
  }
}
  • The NAT collections have a lower number (a higher priority) than the network collections.
  • The network collections have a lower number than the application collections.
  • The priority of the group itself is unique, and inside the range of the owner (Priorities).

3.3 IP groups

When source_ip_groups or destination_ip_groups has a value, the group must exist. Check that either:

  • a file with the name of the group is already in the ip_groups folder of the platform environment (environments/<env>/ip_groups or environments/<env>/<region>/ip_groups), or
  • the pull request adds that file, in the same folder, for both canary and prod.

If not, ask the author to add the definition.

3.4 One source type and one destination type

  • A rule has only one of source_addresses and source_ip_groups.
  • A rule has only one of destination_addresses, destination_ip_groups and destination_fqdns.
  • An application rule has only one of destination_fqdns and destination_fqdn_tags.

If more than one is filled in, ask for a correction. The config tests find most of these, but the check of the application rule destinations does not (Known issues), so look at it yourself.

3.5 Content

  • The right team owns the file, and the rule is in the right place (global or regional).
  • The rule type fits: application rule for internet FQDNs, network rule for the rest.
  • The destination is as specific as possible, and the ports are exact. No * and no Any without a written reason.
  • Internet destinations are FQDNs, not IP addresses.
  • No rules between production and non-production, and no rule that opens more than the request asks for.
  • The rule does not overlap with, or hide, another rule.
  • When the rule replaces another, the old rule is not removed in the same pull request.
  • The description tells which traffic is allowed: from where, to where, which port.

Check the approvals that your organisation requires for this kind of rule (for example the owner of the destination and security: What the review usually checks).

4. Final review

  • All checks are in order: approve the pull request.
  • Something is wrong: give clear feedback, put the ticket back to New and assign it to the author.
  • After you approve and merge, deploy: Firewall rule deployment.