Connecting to your Google Cloud VMs with TYO Reach
Give your team — including external contractors — one-click RDP/SSH access to VMs in your Google Cloud project, through Google's own Identity-Aware Proxy (IAP). No VPN, no public IPs, no bastion host to run or maintain.
Throughout this document, "Reach" refers to TYO Reach.
1. How it works (30-second version)
User's laptop ──(Reach client)──► Google IAP ──► your VM
- The user clicks a machine in the Reach tray and signs in with their Google account.
- Google checks they're allowed (IAM), enforces MFA / your Context-Aware Access policies, and opens the tunnel.
- Reach binds a local port and launches RDP or SSH to it.
Google enforces all access and identity. Reach provides the one-click client and the audit trail. Traffic goes directly from the user to Google IAP to your VM — it never passes through Reach's servers (so it's also outside any Reach data allowance, and there's no third party in your data path).
IAP itself has no per-use fee — you pay only for the VM and network egress you already pay for.
2. What your GCP admin sets up (one-time, per VM)
You need three things in your GCP project. Replace PROJECT, VPC, the email, and the
zone/instance as appropriate.
2.1 Allow IAP to reach the VM's port (firewall)
IAP connects from a fixed Google range. Add an ingress rule for it on the port you serve (3389 for RDP, 22 for SSH):
gcloud compute firewall-rules create allow-iap-rdp \
--project=PROJECT --network=VPC \
--direction=INGRESS --action=ALLOW \
--rules=tcp:3389 \
--source-ranges=35.235.240.0/20
35.235.240.0/20 is Google IAP's range — this is the only source that can reach the
port. (Use tcp:22 for SSH.)
2.2 Grant the user permission to use the IAP tunnel
The person's Google identity needs the IAP-secured Tunnel User role. Grant it on the whole project, or — for least privilege — on a single instance:
# Whole project:
gcloud projects add-iam-policy-binding PROJECT \
--member="user:[email protected]" \
--role="roles/iap.tunnelResourceAccessor"
# Or scope to one VM only (recommended for contractors):
gcloud compute instances add-iam-policy-binding INSTANCE \
--project=PROJECT --zone=ZONE \
--member="user:[email protected]" \
--role="roles/iap.tunnelResourceAccessor"
For a group, use --member="group:[email protected]".
2.3 Give the user a way to log into the OS
IAP controls the tunnel; the VM still checks the login:
- RDP (Windows): a Windows username/password on the VM.
- SSH (Linux): OS Login (recommended) or an SSH key.
These are separate from the IAP grant above.
3. What gets configured in Reach (per VM)
An admin adds a Remote target in the Reach dashboard's Targets tab:
| Field | Value |
|---|---|
| Backend | gcp-iap |
| Project | your GCP project id |
| Zone | the VM's zone (e.g. us-central1-a) |
| Instance | the VM name |
| Interface | nic0 (default — only change for a VM with a non-default NIC) |
| Port | 3389 (RDP) or 22 (SSH) |
| Protocol | rdp / ssh |
Enabled targets sync to every member of your organisation with the desktop client automatically.
4. What the end user does
- Install the Reach desktop client (Windows / macOS / Linux).
- Sign into Reach.
- Open the tray → Remote targets → click the VM.
- First time only: a browser opens to Sign in with Google — use the Google account that was granted IAP access (2.2). Approve.
- Reach opens the tunnel and launches RDP/SSH automatically. Subsequent connects are one click (the Google sign-in is cached).
No keys, no config files, nothing for the end user to set up.
5. Security & governance
- Access is Google's to grant and revoke. Remove the IAM binding (2.2) and the person loses access immediately — nothing lingers on their machine.
- Least privilege: scope the tunnel role to specific instances for contractors.
- MFA / Conditional Access: enforced by your Google identity policies (Workspace / Context-Aware Access). Reach rides on top — it can't bypass them.
- Audit: IAP connections appear in your Google Cloud audit logs; Reach can additionally record a per-connection audit trail on the Reach side.
- Data path: user ↔ Google IAP ↔ VM. Reach is never in the traffic path.
6. Troubleshooting
| Symptom | Cause / fix |
|---|---|
| Google sign-in succeeds, then no connection | The account is missing roles/iap.tunnelResourceAccessor (2.2), or the IAP firewall rule (2.1) is missing / wrong port. |
| "Connection refused" / times out at the VM | Port not listening on the VM, or the firewall rule targets the wrong network/port. |
| RDP/SSH opens but the login is rejected | That's the OS credential (2.3), separate from IAP access. |
| Target doesn't appear in the tray | The user isn't signed into Reach, or your organisation isn't on a Team plan. |
| Wrong machine reached | Check Project / Zone / Instance in the Reach target config (section 3). |