One of the things we’re asked about by our customers adopting a service mesh practice is how Open Policy Agent (OPA) and service mesh fit together and interact in their application infrastructure. In this article, we’d like to weigh in with some thoughts on where service mesh and OPA policy are best suited, respectively, and how they complement each other.
This article is part of a three-part series on Istio’s development, how to optimize Istio performance (this article), and Istio’s open source ecosystem and its future.
After Istio’s architecture stabilized in version 1.5 (March 2020), as mentioned in the previous article, the community’s main focus turned to optimizing performance. In the following sections, we’ll look at the different optimization methods that were considered by Istio and describe which approaches were adopted.
This is the first in a series of three articles that reviews the development of the Istio open-source project (this article), shows how to optimize Istio performance, and describes Istio’s open-source ecosystem and future. I also share my view on the most appropriate use of eBPF with Istio, mostly in the second article.
Service mesh technology is on the rise due to the popularity of Kubernetes container management software, the use of microservices and the DevOps approach in application development and delivery, and the growing use of cloud native architectures. Istio is the leading service mesh software, nearly always implemented with Envoy as a sidecar proxy.
The rise of Kubernetes and programmable data proxies such as Envoy proxy create the foundation for Istio. The future of Istio is to further serve as the foundation for a secure, zero-trust network.
This is the third in a series of service mesh best practices articles excerpted from Tetrate’s forthcoming book, Istio in Production, by Tetrate founding engineer Zack Butcher.
Istio is like a set of Legos: it has many capabilities that can be assembled just about any way you want. The structure that emerges is based on how you assemble the parts. In the previous installment of this blog series, we described an opinionated runtime topology to build a robust, resilient, and reliable infrastructure. In this article, we’ll describe an opinionated set of mesh configurations to help achieve robustness, resiliency, reliability, and security at runtime.
This is the second in a series of service mesh best practices articles excerpted from Tetrate’s forthcoming book, Istio in Production, by Tetrate founding engineer Zack Butcher.
There are a few moving pieces when it comes to a service mesh deployment in a real infrastructure across many clusters. The primary pieces we want to highlight here are how control planes should be deployed near applications, how ingresses should be deployed to facilitate safety and agility, how to facilitate cross-cluster load balancing using Envoy, and what certificates should look like inside the mesh.
Today, we are excited to announce the general availability of Tetrate’s Brooklyn release. This marks a major evolution of Tetrate Service Bridge (TSB), a service mesh powered application connectivity platform that enables global enterprises to modernize applications, migrate one or more clouds, achieve zero-trust security, and automate infrastructure resilience. New TSB capabilities will make deploying Istio and Envoy at scale even easier for platform teams, enforcing global policies effortless for security teams, and troubleshooting service mesh workloads self-service for application teams. We’ve also productized best practices and lessons learned from delivering production service mesh for global financial services and federal institutions, so every security-focused organization can benefit from a service mesh without the overhead. In this blog, I will introduce these new TSB capabilities as well as recap relevant recent innovations in Tetrate Istio Distro (TID) and our contributions to open source projects.
If you are already familiar with TSB and want to dive into the technical details, jump straight into the release notes.
If you are new to Tetrate, read on for a comprehensive introduction, and register for the demo webinar to get a closer look.
The Tetrate blog highlights best practices and educational content on service mesh, open source, and related technologies. Our team is dedicated to providing quality how-tos, thought leadership pieces, and market developments with our commentary to help our readers stay informed and up-to-date on the latest developments in the industry. It is great to see that our readers appreciate these posts. Without further ado, here are the top 10 blog posts our readers scoured this year.
As we’ve written here before, there’s increasing urgency for organizations—especially those operating in a regulatory environment—to adopt a zero trust network architecture. Just what that means and how to do it may not be immediately clear. When it comes to microservices applications, the National Institute of Standards and Technology (NIST) offers guidance for microservices security in the SP 800-204 series, co-written by Tetrate co-founder Zack Butcher (which we’ve also covered on this blog).
NIST’s reference architecture for microservices security is Kubernetes and the Istio service mesh. In this article, we’ll look at NIST’s recommendations for using a service mesh for authentication and authorization in microservices applications.
At the heart of a zero trust posture is the assumption that an attacker is already in your network. All of these policy recommendations will help prevent potential attackers from pivoting to other resources should they breach your network perimeter. If you use a service mesh as described in the NIST reference platform, all of these capabilities are built into a dedicated infrastructure layer that acts as a security kernel for microservices applications. This means security policy can be applied consistently (and provably) across all your apps—and so your product development teams don’t have to be security experts for your apps to run safely.Service mesh allows fine-grained access control to be layered on top of traditional security measures as part of a defense-in-depth strategy. The mesh sits as a powerful middle layer in the infrastructure: above the physical network and L3/L4 controls you implement, but under the application. This allows more brittle and slower-to-change lower layers to be configured more loosely—allowing more agility up the stack—because controls are accounted for at higher layers.
This is the first in a series of service mesh best practices articles excerpted from Tetrate’s forthcoming book, Istio in Production by Tetrate founding engineer Zack Butcher.
One of the biggest questions we get from enterprises implementing the mesh is “which controls do I still need, and which does the mesh provide?” In other words, they’re wondering how the mesh fits into an existing security model. We’ve seen that the mesh is most effective as the inner ring in a concentric set of security controls implemented at each layer from the physical network up to the application itself.
The Istio service mesh offers cloud native deployments a standard way to implement automatic mutual transport layer security (mTLS). This reduces the attack surface of network communication by using strong identities to establish encrypted channels between workloads within the mesh that are both confidential and tamper-resistant. mTLS is a key component for building zero-trust application networks. To understand mTLS traffic encryption in Istio, this article will cover the following:
