BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Google Publishes Its BeyondProd Cloud-Native Security Model

Google Publishes Its BeyondProd Cloud-Native Security Model

Bookmarks

The recently published Google BeyondProd whitepaper provides a model for cloud-native security in a containerized world. Google's model requires moving beyond the traditional perimeter-based security model, and instead leverages code-provenance and service identity as security cornerstones. Google also provided a list of open-source software that can be used to implement its security model.

BeyondProd allows Google to ensure security of the billions of containers it deploys each week, writes Google PM in container security Maya Kaczorowski. Similarly to the Google BeyondCorp security model for enterprise security, BeyondProd's central idea is that organizations should not trust any entities, whether they are within or outside their perimeter, following the principle of "never trust, always verify". In comparison with enterprise security, cloud-native security takes into account the use of containers, explains Kaczorowski:

The first big difference when using containers is due to scheduling. You can’t rely on IP addresses or host names for security. You need service identity

This idea has been gaining ever more traction in the last few years under the moniker of "Zero-Trust" networking. As independent cybersecurity consultant Michael Brunton-Spall says:

Just because you're on the network doesn't mean we trust you in the slightest." In fact, in many cases it probably means we should trust you less, I would argue. Most of the networks I've seen across government have been compromised at some point in the past. Being on the network is not a good indicator of trust.

In zero-trust networking, protection of the network at its outer perimeter remains essential. However, evolving this to full zero-trust networking requires a number of additional provisions. This is by no means easy, given the lack of standard ways to do it, adds Brunton-Spall:

You can understand [it] from people who've done this, custom-built it. If you want to custom build your own, you should follow the same things they do. Go to conferences, learn from people who do it.

Filling this gap, Google's white-paper sets a number of fundamental principles which complement the basic idea of no trust between services. Those include running code of known provenance on trusted machines, creating "choke points" to enforce security policies across services, defining a standard way to roll out changes, and isolating workloads. Most importantly,

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 these principles will require organizations to change their infrastructure and development processes with the aim of building security into their products as early as possible, while not burdening individual developers with security concerns, effectively transitioning from DevOps to a DevSecOps model.

This will not be straightforward or without costs for interested organizations, and Google has been creating internal tools and working on their processes for years. A good starting point is the list of open source software and other tools provided by Google, including Envoy, Traffic Director, Kubernetes admission controllers, and many more.

Rate this Article

Adoption
Style

BT