Google — BeyondProd zero trust
This is a real, named company's own account of its internal security architecture, and it sticks to what Google has published itself — the BeyondProd whitepaper, the BeyondCorp series of USENIX ;login: papers, and the book Building Secure and Reliable Systems, written by Google's own security engineers. The story runs in two acts, years apart. First, described publicly starting in 2014, Google built BeyondCorp: it decided a corporate network connection should never be the reason a person's laptop gets trusted, and replaced VPN-based access with per-request verification of the user and the device. Second — covered in far less industry conversation, but arguably the more consequential engineering bet — Google turned that identical argument on itself, applying it not to people reaching services but to services reaching each other, inside Google's own production datacenters. That second act is BeyondProd: no microservice trusts another microservice just because a request arrived from inside the same network, the same datacenter, or even the same physical rack. Every call authenticates the caller's identity, every time, regardless of where it came from.
Imagine an office building that finally stops trusting a badge just because someone's already inside the lobby — every door inside the building, all the way down to the supply closet, checks the badge again, every single time, even for someone who badged into the lobby two minutes ago. That's roughly what a company does when it decides the front door isn't the only door worth locking. Now imagine that same company also refuses to let anything move through its own internal mail system unless the package can prove exactly which sealed factory line packed it — no unmarked box gets sorted, no matter who's carrying it. Google did the badge version first, for people walking into buildings. Years later it did the sealed-package version for its own software talking to other software, inside its own datacenters — and the sealed-package version is what this page is actually about.
Before BeyondProd: BeyondCorp removes the trusted network — for people, first
☺ Like you're 10: Google didn't start by rewiring its datacenters — it started by throwing out the idea that a laptop plugged into the office network should be trusted just for that.
BeyondCorp is documented across a series of papers Google engineers published in USENIX's ;login: magazine, beginning with "BeyondCorp: A New Approach to Enterprise Security" by Rory Ward and Betsy Beyer in the Winter 2014 issue, followed by several more detailed papers over the next few years filling in the architecture — the Access Proxy that terminates every connection to an internal application, a device inventory service that tracks every machine Google issues, and a "trust inferer" that computes a dynamic trust tier for a request from signals like the device's patch level and certificate state, rather than trusting it merely for arriving on Google's own office network.
The headline change BeyondCorp made was removing the corporate VPN as a meaningful security boundary. Before BeyondCorp, connecting to Google's internal network — over VPN, from a Google office, whatever the mechanism — was itself treated as a credential: you were "inside," so internal applications extended you more trust than an outside request got. BeyondCorp inverted that. Every request to an internal application, VPN or no VPN, office network or coffee-shop wifi, goes through the identical per-request check of who's asking and from what device, and gets the identical answer either way. A Google engineer working from an airport gets the same trust evaluation as one sitting at a desk in Mountain View.
That's a genuinely large architectural bet, and it's worth naming precisely what BeyondCorp does not cover, because it's the exact gap the rest of this page exists to close: BeyondCorp verifies a human, at a device, reaching an internal application. It has nothing to say about how that application, once the request reaches it, talks to the dozen or more other internal services it depends on to actually answer. Service-to-service traffic — the overwhelming majority of requests inside any datacenter — sat entirely outside BeyondCorp's scope.
The gap left behind: production still ran on the old model
☺ Like you're 10: Even after Google stopped trusting people just for being on the office network, its own programs were still trusting each other just for being on the same production network — the identical mistake, one layer deeper.
Once a BeyondCorp-verified request passed the Access Proxy and reached a backend, most of what happened next still ran on the traditional model this course calls castle-and-moat: a service calling another service inside Google's production network was trusted because of where it was running, not because it had proven who it was. That's the same shape of failure this course's own Capital One case study walks through at a much smaller scale — an IAM role trusted with sweeping access because it sat inside the right AWS account, not because anything checked what it actually needed. A compromised or merely misconfigured service inside Google's perimeter could, in principle, reach further than it should, for the same underlying reason: the network boundary was doing the job that identity verification should have been doing all along.
Google's answer, documented publicly years later in the BeyondProd whitepaper and in the book Building Secure and Reliable Systems (O'Reilly, 2020, co-authored by a group of Google security engineers including Heather Adkins and Betsy Beyer), was to apply BeyondCorp's own insight one layer deeper: stop trusting a network position, start verifying an identity — at every hop, not just at one edge proxy.
| Question | BeyondCorp's answer | BeyondProd's answer |
|---|---|---|
| Who or what is being verified? | A human, at a specific device | A service, calling another service |
| What used to grant trust? | Being connected to the corporate network or VPN | Being inside the production network or datacenter |
| What grants trust instead? | Verified user credentials plus a computed device-trust tier, checked per request at the Access Proxy | A verified, cryptographic service identity, mutually authenticated on every individual RPC |
| Where is trust enforced? | One Access Proxy, at the edge of each internal application | Every service-to-service call, everywhere in the fleet — no single edge is sufficient |
| Public documentation | Ward & Beyer, ;login:, Winter 2014, plus several follow-on papers through roughly 2018 | The BeyondProd whitepaper (2019); Building Secure and Reliable Systems (2020) |
By the time BeyondProd was published, "zero trust" was already becoming a vendor marketing label attached to almost any product with a login screen. Google's own usage is narrower and more mechanical than most of that marketing: a specific claim that network location must never be treated as sufficient proof of identity, backed by mutual authentication that's actually enforced on every call. Read a vendor's "zero trust" claim the way this course asks you to read any vendor claim elsewhere — ask what, specifically, still gets trusted implicitly, because something usually still does.
Six principles, one thread: verify identity, not location
☺ Like you're 10: Google's own materials break the idea into six habits — this table is a plain-language summary, not a verbatim quote of the whitepaper's exact wording.
Google's own BeyondProd materials describe roughly six core principles behind the design. The wording below is this course's own paraphrase, condensed for a DevSecOps reader rather than copied verbatim — read the whitepaper itself for Google's precise phrasing.
| Principle | What it rules out | Google's mechanism | Covered in depth |
|---|---|---|---|
| Mutual authentication, every call | "This request came from inside our network" as a trust basis | ALTS on every RPC, both directions verified | Workload Identity & Pipeline IAM |
| No inherent mutual trust between services | Two services on the same host or rack trusting each other by default | A per-workload identity, tied to the job, not the machine it happens to run on | Zero Trust for Pipelines |
| Trusted machines, known provenance | "It came off our own build system" accepted as sufficient proof, unverified | Binary Authorization for Borg | Zero Trust for Pipelines, Software Bills of Materials |
| Consistent policy enforcement at a few choke points | Every team writing and maintaining its own bespoke authorization logic | A small number of centrally-managed enforcement points, not one-off checks scattered per service | IaC security & policy as code, OPA & Conftest |
| Easy, auditable change | Silent, unreviewed changes to what's actually running in production | Deploys routed through the same verified pipeline that provenance depends on | Compliance & governance |
| Isolation between workloads | One compromised process reaching a co-located workload's memory or files | gVisor sandboxing between containers sharing a host | Container Runtime Security |
Mutual authentication at Google's own scale: ALTS
☺ Like you're 10: Instead of a service just believing the label on an incoming request, it asks for real proof — proof that gets reissued fresh, automatically, rather than a badge that quietly expires and nobody notices.
The mechanism doing the actual verification for internal traffic is ALTS — Application Layer Transport Security — Google's own mutual-authentication and transport-encryption protocol for RPCs between Google-internal services. Google's own description of ALTS dates its production use back to roughly 2007, publicly documented in a whitepaper years later. Conceptually, ALTS does the same job mutual TLS (mTLS) does for the rest of the industry — both ends of a connection present and verify a cryptographic identity before any application traffic flows — but it's purpose-built for Google's internal scale and operational model rather than being a generic TLS deployment: short-lived credentials issued and rotated automatically, tightly integrated with the identity a workload already gets when Google's cluster-management system schedules it, and no dependency on a human remembering to renew a certificate before it expires.
That last point matters more than it sounds. A huge share of real-world mTLS failures in other organizations trace back to an expired certificate nobody rotated in time, or a service that fell back to plaintext when its certificate check failed rather than refusing the connection. Removing the human rotation step doesn't just make ALTS more convenient — it removes the single most common way this class of control silently degrades in practice. Externally, public traffic first lands at Google's own edge — the Google Front End (GFE), which terminates TLS from the public internet — before being handed off to ALTS-secured internal hops; a request's identity and authorization context travel with it from that point on, not just its raw payload.
Trusted machines, known provenance: Binary Authorization for Borg
☺ Like you're 10: Google's own scheduler won't run a program just because it showed up looking right — it wants proof of exactly which factory line built it first.
Mutual authentication answers "which service is calling me." It says nothing about "was the code this service is running ever supposed to exist in the first place." That second question is what Binary Authorization for Borg (BAB) answers, inside Borg, Google's internal cluster-management system (the direct ancestor of the ideas that became Kubernetes). BAB is a deploy-time check: before Borg will schedule a workload, that workload's binary has to carry verifiable proof it was produced by Google's own mandated build process — reviewed source, built by a trusted build system, not hand-assembled or pushed from an engineer's laptop. A binary that can't produce that proof doesn't run, no matter how legitimate the request to deploy it looks.
This is the production-scale precedent behind this course's own Zero Trust for Pipelines: if Google won't let a Borg job run without cryptographic proof of where its binary actually came from, a CI/CD pipeline shouldn't let an artifact reach production on the strength of "it came off our build server" either — that page's own argument for OIDC-federated identity and Sigstore-signed provenance is the same principle, applied outside Google. It isn't a coincidence that the two rhyme this closely: Google's own internal practices, including BAB, are what the company drew on when it published SLSA (Supply-chain Levels for Software Artifacts) in 2021 — a public framework for graduated build-integrity levels that Google later contributed to the Open Source Security Foundation (OpenSSF), where it reached a formalized v1.0 in 2023. Check slsa.dev for the current version rather than treating any level number as fixed. BeyondProd's internal-only provenance check and this course's own Sigstore & cosign page are, in a real sense, the same idea a decade apart.
Carrying the end user's identity through the call chain
☺ Like you're 10: Knowing which coworker just handed you a form isn't the same as knowing which customer originally asked for it — a long chain of hand-offs needs to remember the original request, not just the last person who touched it.
Mutual service-to-service authentication solves "which service is calling me," but a request that started with an actual end user — someone using a Google product — often passes through many internal services before it's fully answered, and a downstream service several hops in still needs to know whose request this ultimately is, not merely which internal service happened to relay it last. Google's own BeyondProd materials describe carrying that information as an end-user context that travels alongside the request through the whole call chain — separate from, and layered on top of, the service identity ALTS already verifies at each hop. The distinction matters for authorization specifically: a service three hops downstream can check both "is the calling service who it claims to be" and "does the original end user actually have permission for what's being requested," instead of blindly inheriting whatever authorization the previous hop decided to extend.
Without that second signal, a compromised or merely buggy intermediate service could, in principle, make requests on behalf of "itself" that should only ever have been possible on behalf of a specific, authorized end user — the exact kind of confused-deputy problem this course covers more generally on threat modeling.
Isolation and the choke points: gVisor and centralized policy enforcement
☺ Like you're 10: Two roommates sharing a kitchen still need their own locked cabinets — being in the same apartment isn't the same as sharing everything in it.
The last principle worth pulling out on its own is isolation: even after a workload's identity and provenance are both verified, two containers scheduled onto the same physical machine still share a kernel by default, and a container-escape vulnerability in that shared kernel could let one compromised workload reach another that happens to be co-located, regardless of how well each individually authenticated. Google's answer, open-sourced in 2018, is gVisor — an application-level kernel that intercepts a container's system calls and handles them in a sandboxed user-space process rather than passing them straight through to the host kernel, adding a real isolation boundary between a container and the machine underneath it without requiring a full, heavyweight virtual machine per workload. gVisor now runs inside several public Google Cloud products, including App Engine's standard environment and Cloud Run, and remains an open-source project any team can adopt independently of Google Cloud.
Isolation only holds together, though, if the policy governing what's allowed to run — and what identity, provenance, and access rules apply — is enforced consistently rather than reinvented per team. BeyondProd's "choke points" principle is the organizational half of this: a small number of centrally-managed enforcement points that every workload passes through, instead of each service owner writing and maintaining its own bespoke authorization logic that inevitably drifts out of sync with everyone else's. This course's own IaC security & policy as code page covers the smaller-scale version of exactly this idea — a small number of centrally-defined policies, like an OPA rule set, enforced consistently rather than trusted to each team's own judgment.
What to steal for your own platform
☺ Like you're 10: You don't need Google's fleet size to copy the habits — check identity instead of location, prove where a binary came from, and keep it simple with one enforcement point instead of a hundred bespoke ones.
- Stop treating "same VPC" or "same Kubernetes namespace" as a trust signal. A service mesh like Istio or Linkerd brings mTLS between workloads to any Kubernetes cluster today — the open-source, general-purpose descendant of the exact idea ALTS proves out internally at Google. See Kubernetes Security Deep Dive.
- Give every workload a cryptographic identity independent of its IP address or hostname. The open SPIFFE/SPIRE standard exists precisely to let heterogeneous infrastructure issue and verify workload identities in this same spirit, without needing Google's own internal tooling. See Workload Identity & Pipeline IAM.
- Require provenance before deploy, not just a scan after the fact. Binary Authorization for Borg's descendant is available as a public product — Binary Authorization on Google Kubernetes Engine — and the same idea is achievable anywhere with cosign signatures verified by an admission controller like Kyverno before a workload is ever allowed to run. See Zero Trust for Pipelines.
- Centralize policy enforcement instead of letting every team hand-roll its own. A handful of consistently-applied OPA policies, checked at a small number of real choke points, beats a hundred slightly-different authorization checks scattered across a hundred services. See IaC security & policy as code.
- Sandbox what you can't fully trust to share a kernel. gVisor and comparable sandboxed runtimes (Kata Containers, among others) are a real option for any multi-tenant workload, not a Google-only capability. See Container Runtime Security.
Honest caveats: what doesn't transfer
☺ Like you're 10: A story about a company that built its own internal protocol for this doesn't mean you should build your own protocol too.
- ALTS itself is not something most organizations should build. It's a bespoke protocol maintained by a company with an enormous, dedicated security-infrastructure team, tightly coupled to Google's own internal identity and cluster-management systems. The transferable idea is "mutually authenticate every internal call, using short-lived, automatically-rotated credentials" — the transferable implementation, for almost everyone else, is a standard mTLS-based service mesh or SPIFFE/SPIRE, not a homegrown protocol.
- Borg is not Kubernetes, even though it heavily influenced it. Binary Authorization for Borg is a Borg-specific mechanism; its public, Kubernetes-native descendant (Binary Authorization on GKE) is the thing worth actually adopting, not an attempt to reconstruct BAB's exact internal design.
- Most of the specifics are Google's own account, not independently audited. The BeyondProd whitepaper and Building Secure and Reliable Systems are genuinely detailed and technically credible, but they're still one company's own description of its own architecture, written for publication. Treat implementation specifics — exact rollout dates, internal team structures — as Google's own reporting, the same caution this course applies to any vendor's or company's self-reported case study.
- None of this replaces the BeyondCorp half. BeyondProd secures service-to-service traffic; it says nothing on its own about how a human first gets authenticated to reach a system at all. A team adopting "zero trust" needs both halves — user-facing identity-aware access, and workload-to-workload mutual authentication — not either one alone.
Pick one service you run in a Kubernetes cluster (or a scratch cluster you can experiment in). Check whether traffic between it and one thing it calls is currently encrypted and mutually authenticated, or whether it's plain HTTP inside the cluster network on the assumption that "it's internal, so it's fine." If you have a service mesh available, look at whether mTLS is actually enforced (not just available) between those two workloads — many meshes default to permissive mode, which allows plaintext alongside mTLS rather than requiring it. That gap between "capable of mTLS" and "actually enforcing it everywhere" is the exact same gap BeyondProd closed at Google's scale.
Timmy the Turtle: So even two services on the same rack, same datacenter, same everything — Google still makes them prove who they are to each other?
Pip the Hummingbird: Every single call. And it's not just "who are you" — before a binary even gets scheduled, Borg wants proof of exactly which build produced it. I don't vouch for a package without knowing its whole chain of custody, and neither does Google's own scheduler.
Rocky the Raccoon: Fine, but say I somehow land a process inside Google's production network. What actually stops me from just calling the next service over and getting an answer?
Timmy: The network never vouches for you, Rocky. Only a verified identity does — being physically close to a service was never on the list of things that count as proof.
Foxy: This sounds a lot like the OIDC-token story from Zero Trust for Pipelines — a build job that has to prove its identity fresh, every single call, instead of holding a standing credential.
Pip: Same idea, earlier arrival. Google was doing "prove it every time, not just because you're inside" for its own datacenter years before anyone wrote OIDC federation into a CI pipeline.
Professor Owl: And that's the whole case file in one line: BeyondCorp said a network connection doesn't make a person trustworthy. BeyondProd said the identical thing about a service. Neither one ever needed the network's permission to ask.
Where this connects in the course
☺ Like you're 10: This one company's story touches several lessons — follow whichever matches what you're building next.
The direct, build-system-flavored descendant of this whole page is Zero Trust for Pipelines — no standing credentials, per-job identity, and an artifact that has to prove its own provenance rather than being trusted for the runner it came off, which is BeyondProd's own "trusted machines, known provenance" principle applied to CI/CD specifically. The workload-identity half of this story is Workload Identity & Pipeline IAM; the isolation half is Container Runtime Security and Kubernetes Security Deep Dive; the provenance and signing half is Sigstore & cosign and Software Bills of Materials. For a very different real-world story about what happens when network position is trusted instead of identity, see this course's own Capital One case study; for how a platform can build detection and provenance tooling directly into itself the way GitHub did, see GitHub — supply chain at platform scale. For the rest of this course's tools and other real-company stories, return to the tooling landscape.
1. What specifically did BeyondCorp remove as a trust signal, and for whom — and what gap did it deliberately leave uncovered? 2. In one sentence, what does BeyondProd apply that same removal to, and where? 3. Name the mechanism BeyondProd uses for mutual authentication between internal services, and explain what makes it different from a human-managed TLS certificate deployment. 4. What does Binary Authorization for Borg check for, and why is it described in this page as the precedent for Zero Trust for Pipelines' own argument? 5. Why does a request sometimes need an "end-user context" carried alongside its service-to-service identity, rather than relying on service identity alone? 6. Name one thing about BeyondProd this page argues you should not try to copy literally, and what you should adopt instead.
Check your answers
- BeyondCorp removed a corporate network or VPN connection as a trust signal for human users reaching internal applications, replacing it with per-request verification of the user's credentials and the device's trust tier. It deliberately left service-to-service traffic — how one internal application talks to the others it depends on — entirely uncovered.
- BeyondProd applies the identical removal of "network location as a trust signal" to service-to-service traffic inside Google's own production datacenters — even two services on the same rack must mutually authenticate every call rather than being trusted for their network position.
- ALTS (Application Layer Transport Security) — Google's own mutual-authentication and transport-encryption protocol for internal RPCs. Unlike a typical human-managed mTLS deployment, ALTS issues and rotates short-lived credentials automatically and ties them to the workload identity a service already receives when it's scheduled, removing the expired-certificate failure mode that affects many manual mTLS rollouts.
- Binary Authorization for Borg (BAB) checks that a workload's binary was actually produced by Google's own mandated, reviewed build process before Borg will schedule it — known provenance, not just a passing scan. It's the precedent for Zero Trust for Pipelines because that page makes the identical argument for CI/CD artifacts: a runner's own claim that "this came from our build" isn't sufficient, and cryptographically verifiable provenance (there, via OIDC-federated identity and Sigstore signing) is what a downstream consumer should require instead.
- Because service identity alone only answers "which internal service is calling me" — it says nothing about which original end user's request this ultimately is. A downstream service several hops into a call chain needs the end-user context to authorize correctly against the original user's actual permissions, rather than inheriting whatever an intermediate service decided to extend on its own.
- Any reasonable answer naming ALTS itself (a bespoke, Google-internal protocol not meant for external adoption) or Borg (Google-specific, not Kubernetes) as the thing not to copy literally — and naming the transferable substitute: a standard mTLS service mesh or SPIFFE/SPIRE for workload identity, and Kubernetes-native Binary Authorization or a cosign-plus-admission-controller setup for provenance enforcement.