Networking / Security / Service Mesh

Tetrate: A Service Mesh Can Be the Security Kernel for Distributed Systems

10 Feb 2021 6:00am, by

If you are going to use a service mesh to manage a set of microservices, you might as well start thinking of the service mesh as the “security kernel” for these distributed systems, suggested Tetrate Senior Engineer Zack Butcher, during a virtual conference on Zero Trust Security held by the U.S. National Institute of Standards and Technology (NIST) and Tetrate, a purveyor of an Istio-based premium service mesh.

“The service mesh itself can be a security kernel, a tightly controlled element in our system that we can audit, and can inspect more closely to assert that it is safe,” he told the virtual NIST audience during the event held last month.

In addition to monitoring, routing and discovery for a microservices system, a service mesh also centralizes a lot of security functions. It offloads all the dreaded authentication and authorization chores from the applications themselves. Ideally, each application’s sidecar can act an enforcement point that can not be bypassed.

Of course, with all this power to control a system, sidecars themselves will be an attacker magnet, Butcher admits. But this is a feature, not a bug, “because we know that the attacks are likely to be focused, rather than having to spread out across all the application code of the entire organization,” he said.

The service mesh would be beneficial to running a DevSecOps shop, Butcher said. A service mesh could provide policy enforcement on a continuous basis. a huge requirement for many highly-regulated industries.

A Service Mesh Framework

Butcher worked with NIST to formulate a plan of a service mesh-based security system for microservices, resulting in the NIST Special Publication “Building Secure Microservices-based Applications Using Service-Mesh Architecture” (NIST SP 800-204A for the NIST buffs). This document promises “to provide deployment guidance for proxy-based Service Mesh components that collectively form a robust security infrastructure for supporting microservices-based applications.”

Such a framework would support multiple authorization and authentication services, at both the end-user and service levels. Ideally, it would support those authorization/authentication systems already in use in the enterprise, explained NIST computer scientist Ramaswamy Chandramouli during his own talk.

The framework suggests use of the OASIS standard, the Extensible Access Control Markup Language (XACML), as well as NIST’s own Next Generation Access Control (NGAC) architecture, as described by INCITS 565-2020, which provides a standard API for managing authorization/authentication components. The service mesh pushes all the configuration data to the sidecars attached to each application, and to the data plane proxies handling traffic, to ensure policies are being enforced. End-users’ credentials generated externally can be exchanged at the ingress for an internal credential that represents the permissions of the user.

In this approach, “the service mesh provides a number of different operational assurances: encryption in transit, an authenticated service identity, these proxies that can as act as a multi-enforcement point,” further explained Butcher. “Using those, we can secure applications in the mesh, and we can use it to deploy and secure our actual authentication system itself.”

All the talks from this event can be viewed on the NIST website.

Feature image by Markus Spiske on Unsplash.