How Google’s BeyondProd Redefines Cloud‑Native Security

1. Terminology

Microservice : an independent service that performs a specific task; applications are built as collections of microservices rather than a single monolith.

Workload : a specific task an application completes; a workload may consist of one or more microservices.

Job : a single instance of a microservice that runs part of an application.

Service identity : the credential used for authentication between microservices.

Service mesh : an infrastructure layer that controls service‑to‑service traffic, policies, and monitoring.

2. CIO‑level summary

Each workload is deployed as an individual microservice in containers managed by Borg; modern cloud‑native architecture derives from Borg.

Google designs security into the infrastructure from the start, assuming no trust between services.

BeyondProd protects microservice security through mutually authenticated endpoints, transport security, edge termination with GSLB and DoS protection, end‑to‑end code provenance, and runtime sandboxing.

Moving to a cloud‑native security model requires changes in both infrastructure and development processes, using a shared fabric (service mesh) to simplify roll‑outs and enforce consistent security.

3. Motivation

Google migrated to containers and orchestration to improve resource utilization, build highly available applications, and simplify developer workflows while aligning security controls with the architecture.

Perimeter‑based security is insufficient; a breach of the perimeter allows unrestricted internal movement. Google therefore embeds stronger, developer‑friendly security controls early in the lifecycle.

Containerized microservices bring simpler management and better scalability, but require a new security model that matches these benefits.

4. Google’s cloud‑native security

4.1 Containerized microservices

Google builds its data centers with inexpensive servers and a reliability philosophy that tolerates failures without affecting users. This led to the development of containers, microservices, and the Borg scheduler, which now runs billions of containers weekly.

Each workload is immutable, movable, and schedule‑able, deployed as a set of containers managed by Borg, enabling automatic scaling.

4.2 Transition to cloud‑native architecture

Traditional perimeter security and privileged corporate networks no longer meet modern needs. BeyondCorp removed reliance on network location, focusing on device, user credentials, and attributes. Cloud‑native security similarly trusts services, not network boundaries.

4.3 Internal security services

Google Front End (GFE) : terminates TLS and provides a choke point for DoS protection.

Application Layer Transport Security (ALTS) : mutual authentication and encryption for RPC, binding identities to services.

Binary Authorization for Borg (BAB) and Host Integrity (HINT) : enforce code provenance and host integrity at deployment time.

Service Access Policy and End‑User Context (EUC) tickets : control data access and convey user identity to services.

Borg blue‑green tooling : enables zero‑downtime upgrades and secure roll‑outs.

gVisor : a user‑space kernel that sandboxes workloads, reducing the host attack surface.

5. Putting BeyondProd into practice

5.1 Going all‑in on cloud‑native

By building shared security components, developers only need to integrate minimal, standardized controls, while the underlying fabric (service mesh) enforces security consistently.

5.2 Infrastructure changes

Google first built a strong service‑identity platform (ALTS) that underpins Service Access Policies and EUC tickets. ALTS started as a library with a helper daemon and evolved into a widely adopted RPC security library.

5.3 Development‑process changes

A centralized build system enforces code review, automated testing, and binary signing. Deployments use blue‑green strategies, and sandboxing (initially ptrace, later gVisor) isolates untrusted workloads. Early “audit‑only” modes allow teams to identify policy violations before enforcement.

5.4 Benefits

BeyondProd introduces zero‑trust service communication, workload isolation, deploy‑time code provenance, automated vulnerability management, and strong data access controls, shifting security left in the software lifecycle.

6. Example: User‑data request flow

The request passes through GFE, ALTS, End‑User Authentication (producing an EUC ticket), Service Access Policy checks, and Binary Authorization before reaching the backend service.

7. Example: Code‑change flow

Developers submit changes for review, the build system signs the package, Binary Authorization validates the signature at deployment, and blue‑green deployment updates workloads without downtime.

8. Security principles table

Traditional infrastructure security

Cloud‑native security

Security requirements

Perimeter‑based security assumes trust inside the boundary

Zero‑trust; services authenticate each other

Protect network edge; no implicit trust between services

Fixed IPs and hardware

Shared resources, dynamic IPs

Trusted machines run known code

IP‑based identity

Service‑based identity

Same as above

Services run in predictable locations

Services may run anywhere (private/public cloud)

Same as above

Security implemented per application

Shared security stack, centralized policy enforcement

Central choke points applied consistently

Limited observability of security components

Global view of policy enforcement

Same as above

Infrequent, manual releases

Standardized, frequent releases

Automated, consistent change deployment

VM or physical isolation

Container images with isolation mechanisms

Isolation between workloads on shared OS