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.
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.
The post BeyondProd: Google’s Internal Model to Securing Cloud Native Microservices appeared first on The New Stack.
