Cloud firewall automation: Google Cloud

Reach keeps a VPC firewall rule in your GCP project pointed at your team's gateway IP, so the servers behind it accept traffic from Reach and nothing else. There are no keys to store: you grant Reach's service account one IAM role on your project, and Reach uses its own identity to manage the rule.

What Reach manages

One ingress allow rule on a VPC network of your choice, named by you, with:

  • sourceRanges = your team's gateway IP(s) as /32 entries
  • the protocol and port you set on the target (or all)
  • optional targetTags so the rule only applies to tagged instances
  • description Managed by TYO Reach — do not edit manually

If the rule doesn't exist, Reach creates it. If it does, Reach adds or removes the gateway IPs in sourceRanges and leaves everything else alone. Removing the target strips the gateway IPs; if that would leave the rule with no sources, the rule is deleted rather than left open.

1. Grant Reach access to your project

Run once with a project owner or IAM admin. The service account email is shown on the dashboard's Cloud connections page; it is a TYO-owned identity, not a key you hold.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:REACH_SERVICE_ACCOUNT" \
  --role="roles/compute.securityAdmin"

roles/compute.securityAdmin is the narrowest predefined role that covers the four calls Reach makes: list, get, insert/patch and delete on compute.firewalls. If you prefer a custom role, grant exactly compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update, compute.firewalls.delete and compute.networks.updatePolicy.

2. Connect the project in the dashboard

  1. Open your organisation in the dashboard → Cloud connections → Add connection.
  2. Provider Google Cloud, enter the GCP Project ID, save.
  3. Reach verifies by listing firewall rules. A 403 means the binding hasn't propagated yet or was made on the wrong project; a 404 means the project ID is wrong.

3. Add a firewall target

  1. On the connection, Add target.
  2. Firewall rule name — a new name (Reach creates it) or an existing rule you want Reach to manage sources for. VPC network — defaults to default.
  3. Port and protocol — e.g. 3389 / tcp for RDP, 22 / tcp for SSH, or all.
  4. Save. Reach writes the rule straight away.

Verify with gcloud

gcloud compute firewall-rules describe RULE_NAME --project PROJECT_ID \
  --format="yaml(sourceRanges,allowed,direction,targetTags)"

sourceRanges should list your gateway IP(s) as /32. Compare with the gateway IP shown on the dashboard.

When the gateway IP changes

Reach re-syncs targets when a gateway is added to or removed from your organisation, so new regions appear in sourceRanges without you touching the rule. Don't edit the managed rule by hand — the next sync overwrites the sources.

Revoke

Delete the target (Reach removes its IPs, or the whole rule if it was Reach-created and would otherwise be empty), then remove the IAM binding:

gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:REACH_SERVICE_ACCOUNT" \
  --role="roles/compute.securityAdmin"

Common questions

Can Reach manage a rule on a Shared VPC host project?

Yes, if the binding is made on the host project and the target's VPC network is the shared network's name. The rule is created in the host project.

Does this open my servers to the whole internet?

No — the rule only allows the gateway /32 addresses. Traffic still has to come through Reach, where each member is authenticated with MFA.

Can I keep other source ranges in the same rule?

Yes. Reach only adds or removes its own gateway IPs in sourceRanges; other entries you put there stay. Just don't rely on it for ranges Reach doesn't know about — a manual edit between syncs is fine, but keep them in a separate rule if you want them clearly yours.