In the previous blog post, I introduced how Istio manages certificates, and in this article, I will guide you on how to use an external certificate authority (CA) to achieve fine-grained certificate management and automatic certificate rotation through the integration of SPIRE and cert-manager.
I mentioned in my last article on understanding mTLS traffic encryption in Istio that the key to traffic encryption is certificate management. We can use the built-in certificate authority (CA) in Istio or a custom CA to manage certificates within the mesh. This blog post will explain how Istio handles certificate management.
Istio’s new “ambient mode” is an experimental, “sidecar-less” deployment model for Istio. Instead of a sidecar proxy in front of every workload, ambient mode uses tproxy and HTTP Based Overlay Network Environment (HBONE) as key technologies for transparent traffic intercepting and routing that we covered in our recent article on transparent traffic intercepting and routing in the L4 network of Istio Ambient Mesh. In this article, we’ll take a closer look at tproxy and how it’s used.
In cloud native applications, a request often needs to be processed through a series of APIs or backend services, some of which are parallel and some serial and located on different platforms or nodes. How do we determine the service paths and nodes a call goes through to help us troubleshoot the problem? This is where distributed tracing comes into play.
This article covers:
- How distributed tracing works
- How to choose distributed tracing software
- How to use distributed tracing in Istio
- How to view distributed tracing data using Bookinfo and SkyWalking as examples
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
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.
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.
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.
- 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.
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.
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.
Istio 1.14 was released in June of this year, and one of the most notable features of this release is support for SPIRE, which is one of the implementations of SPIFFE, a CNCF incubation project. This article explains what SPIRE means for zero-trust architectures and why you would need SPIRE for authentication in Istio.