Istio, Security, Service Mesh

Service Mesh Deployment Best Practices for Security and High Availability

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.

Read More
FIPS Certification, Istio, Tetrate, Zero Trust

How Tetrate Istio Distro Became the First FIPS-Compliant Istio Distribution

Federal information systems need FedRAMP approval for authority to operate.  To get that approval, they must comply with the Federal Information Processing Standards (FIPS). For cryptography, this means that if you’re a U.S. government agency or a vendor or contractor supplying the government, you must use FIPS 140-2 compliant modules wherever encryption is required. If you want to use Istio or Envoy in those systems, you can’t use the stock community builds of Istio and Envoy, since they don’t use FIPS-compliant cryptography modules and are thus not suitable for a FedRAMP environment.

Tetrate enables government organizations to meet this requirement by supplying Istio users with the first FIPS-verified open source distribution of Istio and Envoy as part of Tetrate’s hardened and performant Tetrate Istio Distro

In this article we will lay out the basics of FIPS compliance, what it means for Istio and Envoy, and the surest way to get to production with Istio in a FIPS-regulated environment.

TL;DR

  • Software used by federal information systems must be FIPS compliant.
  • Stock builds of Istio and Envoy are not FIPS compliant.
  • Tetrate offers the first FIPS-certified builds of Istio and Envoy with its open source Istio distribution, Tetrate Istio Distro, plus enterprise support with Tetrate Istio Subscription.

To find out more about FIPS and Istio, download our free Primer on Zero Trust and FIPS for Cloud Native Applications.

Read More
Top 10 Blog Post
API Gateway, Envoy Proxy & GetEnvoy, Istio, Kubernetes, Service Mesh, Tetrate, Wasm

Top 10 Blog Posts of 2022

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. 

Read More
ABAC, Istio, Security, Service Mesh, Tetrate, Zero Trust

Top 5 Kubernetes Security Best Practices for Authentication and Authorization

Background

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.

Read More
mTLS Traffic Encryption
Istio, mTLS, Service Mesh, Zero Trust

How Istio’s mTLS Traffic Encryption Works as Part of a Zero Trust Security Posture

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:

  • An overview of TLS, mTLS, and TLS termination
  • An introduction to howTLS encryption works in Istio
  • How to use Istio to implement mTLS in Kubernetes
  • A discussion of when you do and don’t need mTLS
Read More
L7 Traffic
Istio, Service Mesh

L7 Traffic Path in Ambient Mesh

In my last blog, I introduced transparent traffic intercepting and L4 routing in Ambient mode. In this blog, I will show you how L7 traffic is routed.

The figure below shows the L7 network traffic path in ambient mode.

Figure 1: L7 network traffic in ambient mesh
Note: The Waypoint proxy can be located on the same node as the application, and even all of the service and the Waypoint proxy can be on the same node. I draw them on three nodes for display purposes, but it has no significant impact on the actual traffic path, except that it is no longer sent to another node via eth0.

In the following section, we will explore the process in Figure 1 from a hands-on perspective.

Read More
Gateway API Is the Unified Future of Ingress
API Gateway, Istio, Kubernetes, Service Mesh

Why the Gateway API Is the Unified Future of Ingress for Kubernetes and Service Mesh

In this blog, you will learn about the Kubernetes Ingress Gateway, the Gateway API, and the emerging Gateway API trend, which enables the convergence of Kubernetes and service mesh.

Takeaways

  • Ingress, the original gateway for Kubernetes, has a resource model that is too simple to fit into today’s programmable networks.
  • The Gateway API, the latest addition to the Kubernetes portal gateway, separates concerns through role delineation and provides cross-namespace support to make it more adaptable to multi-cloud environments. Most API gateways already support it.
  • The Gateway API provides a new reference model for the convergence of ingress gateways (north-south) and service mesh (east-west, cross-cluster routing), where there is a partial functional overlap.
Read More
Istio Ambient Mesh
Istio, Service Mesh

Transparent Traffic Intercepting and Routing in the L4 Network of Istio Ambient Mesh

Ambient mesh is an experimental new deployment model recently introduced to Istio. It splits the duties currently performed by the Envoy sidecar into two separate components: a node-level component for encryption (called “ztunnel”) and an L7 Envoy instance deployed per service for all other processing (called “waypoint”). The ambient mesh model is an attempt to gain some efficiencies in potentially improved lifecycle and resource management. You can learn more about what ambient mesh is and how it differs from the Sidecar pattern here.

Read More
Tetrate Istio Distro Deployment through EKS add-ons
AWS, Istio, Istio Distro, Service Mesh

Announcing Tetrate Istio Distro Deployment through EKS add-ons: Simplifying Istio on EKS

Today, we are excited to announce that Tetrate Istio Distro (TID) is deployable as an add-on for Amazon EKS. Istio is the de facto standard for running service mesh on top of Kubernetes, and AWS EKS is one of the most popular ways to run Kubernetes. Tetrate’s TID is the first Istio distro deployable using EKS add-on commands, and this new capability makes it super simple to run Tetrate’s hardened, FIPS-compliant, and fully upstream Istio distribution everywhere EKS is available. By making TID available as an add-on, we are making it easier for organizations to productionize Istio, reduce operational complexity, and ultimately achieve application security and modernization goals faster. In this blog, I will show you how to get started with this new EKS add-on.

Read More
Future of Istio
Istio, Zero Trust

The Future of Istio: the Path to Zero Trust Security

In September 2022, Istio became a CNCF incubation project and launched the new Ambient Mesh. With CNCF’s strong community and marketing resources, and Ambient Mesh further lowering the barrier to trying Istio, the five year old open source project has been revitalized.

If you don’t know about service mesh and Istio, or are curious about the future of Istio, this eBook—The Current State and Future of the Istio Service Mesh will give you the answers. The following is an excerpt from the book. In my view, the future of Istio lies in being the infrastructure for zero-trust network and hybrid cloud.

Read More