BeyondProd: How Google moved from perimeter-based to cloud-native security

At Google, our infrastructure runs on containers, using a container orchestration system Borg, the precursor to Kubernetes. Google’s architecture is the inspiration and template for what’s widely known as “cloud-native” today–using microservices and containers to enable workloads to be split into smaller, more manageable units for maintenance and discovery.

Google’s cloud-native architecture was developed prioritizing security as part of every evolution in our architecture. Today, we’re introducing a whitepaper about BeyondProd, which explains the model for how we implement cloud-native security at Google. As many organizations seek to adopt cloud-native architectures, we hope security teams can learn how Google has been securing its own architecture, and simplify their adoption of a similar security model.

BeyondProd: A new approach to cloud-native security

Modern security approaches have moved beyond a traditional perimeter-based security model, where a wall protects the perimeter and any users or services on the inside are fully trusted. In a cloud-native environment, the network perimeter still needs to be protected, but this security model is not enough–if a firewall can’t fully protect a corporate network, it can’t fully protect a production network either. In the same way that users aren’t all in the same physical location or using the same device, developers don’t all deploy code to the same environment.

In 2014, Google introduced BeyondCorp, a network security model for users accessing the corporate network. BeyondCorp applied zero-trust principles to define corporate network access. At the same time, we also applied these principles to how we connect machines, workloads, and services. The result is BeyondProd.

In BeyondProd, we developed and optimized for the following security principles:

• Protection of the network at the edge

• No inherent mutual trust between services

• Trusted machines running code with known provenance

• Choke points for consistent policy enforcement across services, for example, ensuring authorized data access

• Simple, automated, and standardized change rollout, and

• Isolation between workloads

BeyondProd applies concepts like: mutually authenticated service endpoints, transport security, edge termination with global load balancing and denial of service protection, end-to-end code provenance, and runtime sandboxing.

Altogether, these controls mean that containers and the microservices running inside them can be deployed, communicate with one another, and run next to each other, securely, without burdening individual microservice developers with the security and implementation details of the underlying infrastructure.

Applying BeyondProd

Over the years we designed and developed internal tools and services to protect our infrastructure that follows these BeyondProd security principles. That transition to cloud-native security required changes to both our infrastructure and our development process. Our goal is to address security issues as early in the development and deployment lifecycle as possible–when addressing security issues can be less costly–and do so in a way that is standardized and consistent. It was critical to build shared components, so that the burden was not on individual developers to meet common security requirements. Rather, security functionality requires little to no integration into each individual application, and is instead provided as a fabric that envelops and connects all microservices. The end result is that developers spend less time on security while achieving more secure outcomes.

If you’re looking to apply the principles of BeyondProd in your own environment, there are many components, through Google Kubernetes Engine, Anthos, and open source, that you can leverage to achieve a similar architecture:

• Envoy or Traffic Director, for managing TLS termination and policies for incoming traffic

• Mutual TLS, as part of Istio or Istio on GKE, for RPC authentication, integrity, encryption, and service identities

• Kubernetes admission controllers, Kritis, and OPA Gatekeeper, or Binary Authorization, for deploy-time enforcement checks such as code provenance

• Shielded GKE Nodes, for secure boot and integrity verification, and

• gVisor or GKE Sandbox, for workload isolation

• For more information on Anthos’ security model, see Anthos: An Opportunity to Modernize Application Security.

In the same way that BeyondCorp helped us to evolve beyond a perimeter-based security model, BeyondProd represents a similar leap forward in our approach to production security. By applying the security principles in the BeyondProd model to your own cloud-native infrastructure, you can benefit from our experience, strengthen the deployment of your workloads, know how your communications are secured, and how they affect other workloads.

To learn more about BeyondProd, as well as Binary Authorization for Borg, one of the controls we use in the BeyondProd model, head on over to the Google security blog.