Firewall rollout and access revocation
Preview effective allow rules and verify applied policy across changing targets.
Firewall rollout verifies that the intended policy revision reached every target before an access change is considered complete. Saving a policy only records its desired configuration.
Determine the actual allow set
Open Interface → Effective rules and identify every attached policy. Allow rules are combined. Removing SSH from one policy does not revoke SSH if another policy still permits the same source and port.
Include address family in the review. A restricted IPv4 rule can coexist with a broad IPv6 rule. For load-balancer backends, distinguish client ingress from balancer-to-guest traffic so a frontend change does not accidentally permit direct backend access.
Review selector membership
Preview the policy selector and record resolved interface IDs. Check current
labels as well as deployment tooling that can change them. A candidate guest
can acquire the production policy when a rollout changes environment or
service labels.
An empty selector result is not evidence that the service is protected. It can mean the policy references old labels or the wrong project. Compare the resolved set with actual backend membership and interface inventory.
Apply a restrictive revision
Retain a verified guest console or alternative administrative path. Read the current ETag, submit the reviewed rule set, and keep its operation ID. A stale revision is rejected rather than merged with another operator's changes.
The Firewall API reports desired and applied revisions per interface. Wait for required targets, not only the first successful node. An unreachable node can continue with its previous applied rules while the control plane stores the restrictive revision.
If policy must be withdrawn immediately from an unreachable host, follow the organization's isolation or fencing procedure. Repeatedly saving the same rule does not change the host's network reachability.
Existing sessions
The stateful path can retain established connections after a new allow set applies. A rule withdrawal changes new-connection admission; it is not a universal session-termination command.
For credential exposure, revoke application sessions and credentials through their owning systems. For a compromised backend, remove it from service and isolate its network path according to the incident procedure. Do not equate an expired SSH API session with a terminated guest shell.
Verify from the intended source
Test both allowed and rejected paths using the actual source networks, destination ports, and address families. Check return routing and guest firewalls before classifying a rejected connection as a successful managed-policy withdrawal.
Record the policy revision, target IDs, applied observations, and test results. Then remove any temporary broad rules used during recovery. A policy rollback is another revision and needs the same propagation review.
See network peering when access crosses projects and audit streaming for retaining the change record.