Firewall API: Lossless Updates and Protected Default Firewalls
Reading a firewall through the API and writing its rules back now leaves it unchanged, and a VPS's default firewall can no longer be detached, deleted or stripped of its locked rules.
What's changed
- Listing a firewall (GET /api/v1/firewalls or GET /api/v1/firewalls/{id}) now returns each rule's port, an is_locked flag and its source_instance_ids as id and type pairs, so a rule you list and send back in PUT /api/v1/firewalls/{id} is the rule you had. Before, the listing left out the single port and the sources, and a rule written back without them applied to every port and admitted traffic from anywhere
- A rule sent back with its id and without a port, source_ips or source_instance_ids field keeps what it had, while port or source_instance_ids set to null still means every port or no restriction. Rule ids are matched whatever their letter case
- Rules saved before sources carried a type are listed with the type they resolve to among your project's resources; one that matches no resource is listed with a null type and the update asks you to remove it. Writing a listed rule back stores the typed source, and from then on the firewall applies the rule as listed
- Outbound ports 25 and 465 stay blocked on a VPS's default firewall, whatever you send through the API: an update no longer deletes those locked rules, and a rule that would allow them is refused with a 422 that names the rule
- A VPS's default firewall can no longer be detached, deleted or attached to another instance through the API: each answers 422, as in the console