This continues the Reach series. The last update brought Reach to iPhone, iPad and Mac. This one is about reaching the other direction — into your own servers on Google Cloud.
You've got a server on Google Cloud — a Windows box your bookkeeper remotes into, a Linux VM your developer manages. The question that never has a tidy answer is how someone gets to it safely from a laptop that could be anywhere. The usual fixes are a jump box with a public IP address, or handing staff the gcloud command line and asking them to open a tunnel to a port on their own machine. One is a standing target on the internet; the other is a support call waiting to happen.
Reach now takes that job. If you run servers on Google Cloud, you can connect straight to them from the Reach app, using Google's Identity-Aware Proxy — and the fiddly parts disappear.
Into a Google Cloud server, straight from the app
Google Identity-Aware Proxy (IAP) is Google's own way of letting a verified person reach a server without that server being exposed to the internet. It's a genuinely good piece of engineering. The catch has always been the front end: to use it, staff install extra tooling, run a command that opens a tunnel, and then point their remote-desktop client at a local port. Fine for an engineer, off-putting for everyone else.
Reach speaks IAP directly, so none of that is needed. You pick the server in the app and click Connect; your remote desktop or SSH session opens as if the machine were on the desk next to you. The server keeps no public IP address and no open ports to the internet — the connection is carried inside Google's proxy, and Reach handles the whole exchange in the background.
Identity, not an IP address
The reason to bother isn't only convenience. It's the difference between trusting a place and trusting a person.
| The old jump box | Reach with Google IAP |
|---|---|
| A bastion with a public IP your firewall has to allow | No public IP and no open ports — the server only answers verified connections |
| Trusts anyone coming from the allowed address | Trusts a signed-in person, checked against your Google identity |
| Staff run a command line and connect to a local port | Pick the server in Reach and click Connect |
| Little record of who actually logged in | Every connection tied to a named person and logged in Google Cloud |
An IP allowlist trusts a network location, which means anyone behind that address is trusted and a leaked jump box is a skeleton key. Identity flips it around: the server accepts a connection only when it carries a verified person, and every session is attributable. For a small business with staff, contractors or an outsourced admin coming and going, that is the security model you actually want — and it's the same one large enterprises pay handsomely for.
One sign-in, and Reach does the rest
You sign in to Reach with your Google account once. From then on, Reach uses that identity to open the IAP connection whenever you click Connect — there's no separate login dance per server, and no tunnel to babysit. Because the access is granted to your Google account rather than to an IP address, revoking someone is a matter of changing their permission in Google, not rewriting a firewall rule.
The bigger win: one app for Google Cloud and everything else
Here's where it goes beyond a single cloud. Google's IAP only covers servers that live on Google Cloud, reached by people who are in your Google organisation. Most real businesses aren't that tidy — there's the Google Cloud VM, but also the server in the office cupboard, the odd machine on AWS or Azure, and the contractor you'd rather not add to your company directory at all.
Reach connects to all of it from the one app. A server is simply something you click Connect on; behind the scenes it might be reached through Google IAP, or through Reach's own secure relay for the machines Google can't see. The plain way to say it: IAP for your Google Cloud box, Reach for everything else — including the on-prem server and the contractor you didn't want in your Google org.
One honest note, because it matters: a connection carried over Google IAP still uses that person's Google identity, so the "give a contractor access without touching your directory" trick applies to servers reached over Reach's own relay, not the IAP-backed ones. For your Google Cloud servers, access stays in Google's hands — which is usually exactly where a Google shop wants it.
What it takes to switch on
If you're already on Google Cloud, the ingredients are modest:
| What you need | Why |
|---|---|
| A server running on Google Cloud | The machine Reach connects you to |
| Your Google account allowed to tunnel in | Access is granted to a person, through Google — not to an IP address |
| The VM's firewall open to Google's IAP range | So the proxy can carry the connection to the server |
| The server added to your Reach targets | So it appears in the app as something to click Connect on |
Set once, it stays set. After that, connecting is the same click your team already knows from the rest of Reach.
This is part of Reach's remote-access features for teams and is available on business plans. If getting your staff into your servers — on Google Cloud or anywhere else — is a problem you're carrying, get in touch through the business page and we'll set you up.
Next: the same idea pointed at a server that isn't on any cloud at all — reaching the machine in your office without opening a single firewall port.
Discussion
Start a conversation