BeyondProd: Google’s Internal Model to Securing Cloud Native Microservices
Following up on its influential BeyondCorp model for securing enterprise networks, Google has released another idealized security architecture, called BeyondProd, for securing microservices. It is based on the company’s own considerable expertise in wrangling untold numbers of services across millions of containers.
Like BeyondCorp Zero Trust model, BeyondProd assumes no safety zone outside the application itself. “Service trust should depend on code provenance and service identity, not the location in the production network, like IP address,” wrote Maya Kaczorowski, a product manager in security and privacy at Google, in a Tweet thread summarizing the paper.
To make BeyondProd happen you’d need:
- Mutually authenticated service endpoints.
- Transport security.
- Edge termination with global load balancing and denial of service protection.
- End-to-end code provenance.
- Runtime sandboxing.
“The principles in BeyondProd are part of the future of application security,” wrote Aspen Mesh Chief Technology Officer Andrew Jenkins in an email. “Fundamentally, removing the reliance on the perimeter for security is great. We think that a service should be trusted based on what it is (workload identity) and who it is requesting on behalf of (end-user authentication and authorization). That is more important than where you are: inside the ‘trusted perimeter’ or not.”
The paper is a timely one for the emerging microservices community. Surveying 200 tech decision-makers, Networking automation software provider Kong had found, the most cited challenge to deploying microservices-based applications was security.
Beyond the Blue Horizon
The BeyondCorp model assumed firewalls and virtual private networks were useless. Once an attacker breaches this perimeter, getting to the delicious data inside would be trivial. So instead, security needs to be enabled with device-centric authentication and authorization workflow. Likewise, BeyondProd puts no stock in security outside of the microservices themselves, which may be running in a public cloud or on a third-party host of some sort. And because they are in containers, they will probably move around a great deal. Thus it falls to factors such as code provenance and service identity to establish trust.
In this environment, the developer can tightly define which services can communicate with which others, while keeping workloads isolated. “For developers, the best part is that these security controls are built directly into the tools they use — basically, it’s DevSecOps,” Kaczorowski wrote. “You can address security issues earlier, when it’s less costly, and do so in a standardized and consistent way.”
Google also released a separate white paper Tuesday to describe how it does “code provenance.” In this process, an engine called the Binary Authorization for Borg (BAB) does a deployment-time enforcement check to ensure the code meets security requirements before it goes live. Each code change must get entered into the company’s code repository, as well-reviewed by a second engineer, and verification that the binaries were built on dedicated infrastructure.
On the hardware side, another process called Host Integrity (HINT) verifies that the host system software has been securely booted, including the verification of digital signatures on the BIOS, BMC, bootloader and OS kernel.
Even if your own operations aren’t Google-sized, the paper will still be worth studying, in that it will help you get acquainted of the ideas around workload-based/zero-trust security, advised Aspen Mesh’s Jenkins. And not all workloads are directly compatible with this approach. An external database, for instance, might not support mutual TLS based on workload identity. Here is where a service mesh may help, he said.
Liz Rice, who is the vice president of open source engineering with container security specialists Aqua Security, as well as the chair of the Cloud Native Computing Foundation’s Technical Oversight Committee, agreed the model could be useful for smaller organizations as well, though she warned that it is a framework, not a security solution.
“While the approach adheres to the principles of cloud native and shows the way to modern security, its implementation is may not necessarily be easy for organizations that don’t have Google’s development power, despite the availability of open source tools that cover some parts of it,” Rice wrote in an e-mail.
There are also a couple of areas that the whitepaper doesn’t sufficiently address, ones that the Cloud Native-focused Aqua provides for its customers. One is runtime protection. “The sandboxing provided by [Google’s internal] gVisor can certainly limit the blast radius of malicious code in the application, but there are additional tools available for protecting against zero-days,” she wrote.
“Drift prevention” is also worthy of greater attention, Rice advised. “If an executable wasn’t present in a container image when it was scanned, then it’s not allowed to run. This makes remote code injection and execution virtually impossible.”
And being Google, Google doesn’t have to worry about managing security multiple clouds, nor within multitenant environments. Google’s approach should work in these environs, though adoption of BeyondProd means using “security tooling that can handle interactions across clouds,” as well as a managing “one set of common policies that are administered centrally, and additional policies that can be controlled at a business unit or team level,” Rice wrote.
The New Stack Analyst Lawrence Hecht contributed to this post.
Aspen Mesh is a sponsor of The New Stack
Feature image by Marc Vanduffel from Pixabay.
