TL;DR: NIST has just released new draft guidelines for public comment. The guidelines evaluate the security implications of alternate service mesh proxy models like Istio’s ambient mode, Cilium’s eBPF, and gRPC data planes. Infrastructure owners and platform/infrastructure engineers as well as personnel in charge of infrastructure operations should use this guidance to evaluate the applicability of those models for cloud-native applications with different security risk profiles. The upshot is that you should choose a proxy model based on the risk level of your application and there is no one-size-fits-all solution. If you are a Tetrate Istio Subscription customer already, we’re happy to discuss these issues with you in detail. Contact your customer success representative for an architectural review.
New Guidance from NIST on Service Mesh Security
As you may know, for the last few years I’ve been collaborating with NIST to help define security standards for cloud native applications. We’ve published a number of papers providing guidance to practitioners in government and private industry, most notably the Special Publication (SP) 800-207 series on the groundwork for Zero Trust and the SP 800-204 series on security strategies for microservices-based applications. I’m excited to announce the publication today of our latest collaboration, SP 800-233: Guidance on the Use of Service Mesh Proxy Models for Cloud-Native Applications.
This new paper offers guidance on the security implications of alternate service mesh proxy models (sometimes called “sidecarless” service mesh) that have evolved recently to address performance and resource considerations in certain use cases.
Tetrate offers an enterprise-ready, 100% upstream distribution of Istio, Tetrate Istio Subscription (TIS). TIS is the easiest way to get started with Istio for production use cases.
Get access now ›
The Four Service Mesh Proxy Models
The paper examines four service mesh data plane architectures (proxy models) and evaluates them against a set of 10 threat profiles to offer recommendations on which to choose based on an application’s security risk profile. The four proxy models are:
- Sidecar: The first and most common service mesh data plane architecture today, that dedicates a proxy to implement both L4 and L7 functions for each application (service) instance.
- Shared L4, L7 per service: A shared L4 proxy per node, i.e., shared among all service instances that execute on the same physical host, with L7 proxies dedicated per service account. This is also called “ambient mode.”
- Shared L4-L7: L4 and L7 functions implemented on a per node basis, with a shared L7 proxy per node and L4 functions such as traffic routing performed either by a proxy or in-kernel programs (e.g., eBPF programs).
- L4 and L7 in the application: This is a data plane architecture that does not have any proxies. Rather, the service mesh control plane programs L4 and L7 functions into a gRPC library in the service container.
NIST Recommendations
The upshot is that you should choose a proxy model based on the risk level of your application and there is no one-size-fits-all solution.
- For low risk-profile applications: all four proxy models are suitable, but both L7-proxy per service instance and proxyless (gRPC) data planes may expose an unnecessary attack surface.
- For medium risk-profile applications: all four data plane architectures can be used. However, since L7 code is where most exploitable vulnerabilities lie, the shared L4-L7 model is not desirable since the shared L7 component introduces risk for all services that share the same physical host. The shared L4, L7 per service model (“ambient mode”) is likely the best mix of resource utilization and risk. The gRPC proxy-less model with inclusion of libraries for L4 functions and limited L7 functions is also recommended.
- For high risk-profile applications: should any compromise occur, the blast radius should be limited to a single service instance. Highly critical applications should use the sidecar model with a dedicated L4/L7 proxy at each service instance for maximum isolation.
Next Steps
SP 800-233 is now available for public comment, I encourage you to review and submit your comments.
For more information about securing your production service mesh deployment, contact us to talk to an expert. If you are a Tetrate Istio Subscription customer already, contact your customer success representative for an architecture review.
###
If you’re new to service mesh, Tetrate has a bunch of free online courses available at Tetrate Academy that will quickly get you up to speed with Istio and Envoy.
Are you using Kubernetes? Tetrate Enterprise Gateway for Envoy (TEG) is the easiest way to get started with Envoy Gateway for production use cases. Get the power of Envoy Proxy in an easy-to-consume package managed by the Kubernetes Gateway API. Learn more ›
Getting started with Istio? If you’re looking for the surest way to get to production with Istio, check out Tetrate Istio Subscription. Tetrate Istio Subscription has everything you need to run Istio and Envoy in highly regulated and mission-critical production environments. It includes Tetrate Istio Distro, a 100% upstream distribution of Istio and Envoy that is FIPS-verified and FedRAMP ready. For teams requiring open source Istio and Envoy without proprietary vendor dependencies, Tetrate offers the ONLY 100% upstream Istio enterprise support offering.
Get a Demo