Zero Trust Hybrid Cloud: Cloud and On-Prem as One Secure Network
Tailscale for the network, Google Workspace for identity, and one default-deny policy spanning cloud, on-prem, and every Windows, Linux, and Mac client. This is the architecture we run and the one we build for clients.
By William Bradshaw | June 3, 2026 | 10 min read
The network perimeter is gone. A modern small or mid-sized organization runs some workloads in the cloud, keeps some systems on-prem, and has people working from home, from client sites, and from coffee shops on a mix of Windows, Linux, and Mac. The old model, a hardened firewall around a trusted internal network, assumed everything important lived in one building. None of that is true anymore.
Zero trust replaces "trust the network" with "verify every connection." No device is trusted because of where it sits. Every request to reach a resource is authenticated against an identity, authorized against an explicit policy, and encrypted end to end. Access is least-privilege by default: if a policy does not grant it, it is denied. For a primer on the principle and why we standardized on Tailscale, start with our Zero-Trust Networking with Tailscale overview.
This article is the deeper reference architecture. It is the stack we actually run at Bullium and deploy for clients: Tailscale as the network fabric, Google Workspace as the identity provider, public cloud nodes and on-prem and local systems as the resources, all joined into a single private network with one policy. The result is a hybrid cloud where cloud and on-prem behave like one secure LAN, nothing is exposed to the public internet, and the same rules apply to every operating system.
The Architecture at a Glance
Three planes work together. Identity (Google Workspace) decides who you are. The network (the Tailscale tailnet) is an encrypted mesh that connects every device and resource directly, with no open inbound ports. Policy (Tailscale ACLs) decides, per identity, exactly which resources you may reach. Cloud nodes and on-prem systems join the same mesh, so the boundary between "cloud" and "local" disappears.
Identity Is the New Perimeter
In a zero-trust network, access decisions start with identity, not an IP address. We use Google Workspace as the single identity provider. Tailscale federates to it over OIDC, so signing in to the network is the same Google sign-in your team already uses for email and documents. There is no separate VPN account to provision, no shared secret to leak, and offboarding is immediate: suspend the Google account and network access ends with it.
Because Google Workspace is the source of truth, the controls you already enforce there apply to the network automatically: mandatory two-factor authentication, hardware security keys, and conditional access on sign-in. Group membership flows through to the network policy. A person in the engineering group can be granted access to development resources by group, so adding a new hire is a directory change, not a firewall change.
This is the first zero-trust tenet in practice: every connection is tied to a verified human identity and an enrolled device. A laptop is not trusted because it is "inside." It is trusted because the person holding it authenticated, the device is enrolled in the tailnet, and policy explicitly allows the connection it is attempting.
The Data Plane: A WireGuard Mesh
Tailscale builds a private network (a "tailnet") on top of WireGuard, a modern, audited encryption protocol. Every device gets a stable private address. Traffic between devices flows over direct, end-to-end encrypted peer-to-peer tunnels established through NAT traversal; an encrypted relay is used only as a fallback when a direct path cannot be formed. The coordination layer distributes keys and policy but never sees your data.
The single most important security property is what is missing: no open inbound ports. Devices dial outward to join the mesh, so there is nothing listening on the public internet to scan, brute-force, or exploit. A service that used to require a port-forward, a public IP, or a traditional VPN concentrator simply binds to its tailnet address and becomes reachable only by authorized identities.
Policy lives in a single, version-controlled ACL file. Devices carry tags (for example tag:server, tag:client, tag:prod), and grants connect identities or groups to the tags they may reach, on the ports they may use. The default is deny: if no grant matches, the connection never forms. This is microsegmentation without VLANs or firewall sprawl, expressed as readable policy you can review in a pull request.
Two features make the hybrid part work. MagicDNS gives every device a stable name, so services are addressed by name rather than brittle IPs. Subnet routers let a single node advertise an entire network (a cloud private subnet, or an on-prem LAN) into the tailnet, so devices that cannot run the client, such as a printer, a switch, or a legacy appliance, are still reachable under the same policy.
Cloud and On-Prem on the Same Private Network
The hybrid cloud is where most architectures get messy: a site-to-site VPN to the cloud here, a bastion host there, a public load balancer with an allowlist somewhere else. The mesh collapses all of that. Our cloud compute runs on public cloud VPS nodes across multiple providers; each node runs the Tailscale client and joins the same tailnet as everything else. Application services bind to the node's tailnet interface, not a public one, so they are private by construction. There is no public web port to harden because there is no public web port.
On the other side, on-prem and local systems, file storage, internal servers, and the lab, join through a subnet router on the local network. From a developer's laptop, a database on a cloud node and a NAS in the office are both just names on the same private network, reachable only if policy allows. The cloud is not "out there" behind a tunnel; it is a peer on the mesh, governed by the same ACLs as the desk down the hall.
This also simplifies failure and change. Moving a workload between a cloud provider and on-prem does not require re-plumbing firewalls or reissuing certificates for new public endpoints. The service keeps its tailnet name and its policy; only where it runs changes. Administrative access (SSH, database consoles, dashboards) is reachable exclusively over the tailnet, which removes the single largest category of internet-facing attack surface.
One Policy, Every Operating System
A real team is not single-platform. The same identity model, the same encrypted mesh, and the same default-deny policy apply identically whether someone is on Windows, Linux, or Mac. Enrollment is the same everywhere: install the client, sign in with Google, and the device appears in the tailnet for an administrator to authorize.
Windows
The desktop client signs in through the same Google Workspace SSO. Laptops reach internal and cloud resources by name with no separate VPN client to launch, and access follows the user, not the location.
Linux
Servers and workstations run the daemon and are tagged as infrastructure. Tagged nodes use non-expiring keys appropriate for unattended systems, while still being bound by the same ACLs and audit logging as everything else.
macOS
The Mac client behaves identically: Google sign-in, MagicDNS names, and the same per-identity grants. A designer and an engineer on different platforms get exactly the access their groups define, no more.
Because policy is identity-based rather than device-specific, cross-platform parity is automatic. There is no Windows-only path or Mac-only exception to maintain. Key expiry on user devices forces periodic reauthentication, so a lost or stolen laptop loses access on schedule even before it is formally deprovisioned.
The Security Model, and How It Maps to NIST
The architecture is a direct expression of the zero-trust tenets in NIST SP 800-207: authenticate and authorize every session, grant the least privilege required, assume the network is hostile, and encrypt everything in transit. It also lines up cleanly with the functions of the NIST Cybersecurity Framework 2.0, which matters for the regulated and public-sector clients we serve.
- Govern Access policy is one version-controlled ACL file, reviewed and changed through the same process as code.
- Identify Every device and user is enrolled and named; the tailnet is a live inventory of what exists and who owns it.
- Protect Identity-bound access, least-privilege grants, WireGuard encryption everywhere, and no public inbound ports.
- Detect Connection and configuration audit logs make unusual access visible and reviewable, and can be exported to a SIEM.
- Respond Revocation is immediate: suspend the Google identity or expire the device key and access is gone within the network.
Zero trust is not a product you buy once. It is an operating model. The value of this particular stack is that the model is enforced by default and stays simple enough for a lean team to run correctly, which is the difference between a security architecture that exists on paper and one that holds up day to day.
How We Build This for Clients
We run this architecture ourselves, which means we deploy it from experience rather than from a slide deck. A typical engagement starts with identity (getting Google Workspace groups and enforcement right), designs the ACL policy around how your teams actually work, stands up the tailnet across your cloud and on-prem footprint with subnet routers, and enrolls every Windows, Linux, and Mac client with sensible key and device policies.
The outcome is a hybrid network with no public attack surface, access that follows people instead of locations, and a policy your team can actually read and maintain. If you are consolidating remote access, retiring a legacy VPN, or building toward a zero-trust posture for compliance, our network design and security consulting services cover the design, the rollout, and the ongoing operation.
Related Reading
Zero-Trust Networking with Tailscale
The overview: why we use Tailscale, how WireGuard-based zero trust works, and where it fits across mobile, desktop, and server environments.
Security / ComplianceSMB Compliance Mapping
How CIS, NIST CSF, PCI-DSS, and SOC 2 controls map to practical SMB security work, including network access and identity.
Case StudyEnterprise Infrastructure at Utility Scale
Four years of data center modernization, disaster recovery, and secure infrastructure delivery at utility scale.
Related Services
Building a Zero-Trust Network for a Hybrid Environment?
We run this stack every day and deploy it for clients: identity-driven access, an encrypted mesh across cloud and on-prem, and one policy for Windows, Linux, and Mac. Let us design and stand up yours.