AWS firewall request automation GitHub ↗
- Python
- boto3
- AWS
- CloudWatch Logs
- Athena
- Excel
- 3
- Steps: confirm, modify, flowlog
- 4
- Input formats
- 4
- Resource types identified
A CLI that checks whether a firewall request is already open, previews changes only for what is blocked, and verifies the real traffic.
Scale: 3-step CLI · 4 input formats · 4 resource types
Overview
-
Problem
Firewall requests often asked for flows that were already open, which added duplicate rules, and finding the related resources and rules meant searching the console account by account.
-
Approach
netops confirm resolves addresses to AWS resources and evaluates security group rules and routes. Only blocked flows go to modify, which prints a plan first. flowlog searches CloudWatch Logs or Athena for the actual traffic.
-
Result
By default nothing changes. Adding a rule needs --apply and a typed apply, rules can only be added, and a security group without free slots is never chosen.
-
What I learned
In a change tool, the safe action has to be the default that needs no flag. With --dry-run, one forgotten flag means a real change, but when the default run changes nothing and applying needs both --apply and a typed apply, a mistake never becomes a change. Narrowing changes to adding rules only follows the same idea: the less a tool can do, the less harm it can cause when it is wrong. And instead of opening a rule as soon as a request arrives, checking first whether the path is already open, and recording whether a block comes from a rule or a route, stopped duplicate rules from piling up and left only the changes that were really needed.
DESIGN.md — Design and implementation →
notes.md — Related notes →