Keep up with the latest from us
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.
An Istio Egress gateway is just another envoy instance similar to the Ingress but with the purpose to control outbound traffic. Istio uses ingress and egress gateways to configure load balancers executing at the edge of a service mesh. An ingress gateway allows you to define entry points into the mesh that all incoming traffic flows through. Egress gateway is a symmetrical concept; it defines exit points from the mesh. Egress gateways allow you to apply Istio features, for example, monitoring and route rules, to traffic exiting the mesh.
This is the second installment in a two-part series on NIST standards for zero trust security. The first installment covers NIST Special Publication (SP) 800-207, which lays the groundwork for zero trust principles for the enterprise, but makes no specific implementation recommendations.
The follow-up series is made up of four special publications: SP 800-204, SP 800-204A, 800-204B, and 800-204C. This series is co-authored with NIST by Tetrate founding engineer Zack Butcher and takes up where SP 800-207 leaves off.
This series provides security strategies for microservices applications. It mostly focuses on communications between services and between services and a control plane, as described below, under the header Threat Background. In this article, we’ll present an overview of the most important concepts, best practices, and specific deployment recommendations in each of the four papers of the SP 800-204 series:
In my last blog, I gave you a detailed overview of the traffic in the Istio data plane, but the data plane does not exist in isolation. This article will show you the ports and their usages for each component of both the control plane and data plane in Istio, which will help you understand the relationship between these flows and troubleshoot them.
Today, the Envoy community announced an exciting new project: Envoy Gateway. The project unites industry leaders to streamline the benefits of application gateways powered by Envoy. This approach allows Envoy Gateway to immediately establish a solid foundation for rapid innovation. The project will provide a suite of services to manage an Envoy Proxy fleet, drive adoption through ease of use, and support a multitude of use cases through well-defined extension mechanisms.
Istio uses iptables for traffic hijacking, and there is one rule chain named ISTIO_OUTPUT which contains the following rules.
The purpose of this lab is to explore the current options available to export Istio known observability mechanisms to Azure Monitor, including concerns like:
A Wasm plugin lets you easily extend the functionality of your service mesh by adding custom code to the data path. Plugins can be written in the language of your choice. At present, there are Proxy-Wasm SDKs for AssemblyScript (TypeScript-ish), C++, Rust, Zig, and Go.
In this blog post we describe how to use a Wasm plugin to validate a request payload. This is an important use case for Wasm with Istio and an example of the many ways in which you can extend Istio using Wasm. You may be interested in reading our blog posts on using Wasm with Istio and viewing the recording of our free workshop on using Wasm in Istio and Envoy.
“All problems in computer science can be solved by another level of indirection.” – David Wheeler
Service mesh is an architectural construct designed to ease software development and delivery in a microservices environment. Making service mesh work at scale requires some new thinking and the introduction of a few new abstractions.
Here at Tetrate, we have been working on service mesh – its opportunities and its challenges – as long as anyone around. This work is based on our founders’ and key employees’ existing and ongoing roles as founders and maintainers of the open source projects that are most widely used in service mesh implementations: the Envoy proxy, Istio service mesh software, and the Skywalking observability project.
To complement the open source projects, and to create a complete solution, we created Tetrate Service Bridge (TSB). TSB adds a highly functional management plane to service mesh implementations, collaborating with Istio as the control plane and Envoy as the data proxy.
Today, I am happy to announce that the Istio project is announcing its intention to join the Cloud Native Computing Foundation (CNCF). I am very excited for this next step of the Istio project as it will further Tetrate’s mission, which is also my personal mission, to make Istio the industry standard project for service mesh.
My cofounders and I created Tetrate for this cause, and I have been dedicated to it since we conceived of the idea of Istio five years ago in the corridors at Google. Since a large number of organizations rely on Istio as infrastructure for their cloud native journey, CNCF is a natural home for the project to co-exist alongside other CNCF projects such as Kubernetes, Envoy, gRPC, and more.
