Skip to main content
logoTetrate Enterprise Gateway for Envoy (TEG)Version: v1.1.x

Architecture

Tetrate Enterprise Gateway for Envoy (TEG) is composed of the following primary components:

  • Envoy Gateway, which manages Envoy Proxies
  • Envoy Proxy, the reverse proxy that handles incoming traffic
  • Coraza WAF, which is deployed as part of TEG with standard WAF configurations for baseline protection

The Tetrate Enterprise Gateway for Envoy (TEG) architecture, with Envoy Gateway (which manages an Envoy), Redis, and Coraza WAF alongside Tetrate Enterprise Gateway for Envoy (TEG) Manager.

These components are supported as part of Tetrate's TEG offering.

Envoy Gateway

The Envoy Gateway is the control plane and the implementation of the Kubernetes Gateway API, which is the component that helps configure and manage the Envoy Proxies via the Gateway API.

Envoy Proxy

The Envoy Proxy is the reverse proxy that handles incoming traffic. It is a modern, dynamically configured reverse proxy designed for handling traffic for large amounts of microservices, making it an appropriate choice for Kubernetes-hosted application systems.

The Envoy Proxies will scale horizontally to handle varying traffic loads. Depending on your configurations, you may have one or more dedicated proxies within your Kubernetes cluster.

Coraza WAF

The Coraza WAF is deployed as part of TEG and enforces WAF rules to protect underlying resources from malicious requests. Learn more about how to use the Coraza WAF in this guide Using the In-Built "Coraza" Web Application Firewall

Your components

To utilize different features from Envoy Gateway, you have other components to configure for your TEG installation.

Metrics Collection for Observability

Envoy Gateway supports exposing metrics for the proxies installed using either:

  • Prometheus metrics endpoint
  • Sending metrics to an OpenTelemetry sink

Learn more about how to Integrate Telemetry in our documentation.

The TEG demo installation comes with Prometheus and Grafana. However, ensure that when you go to production, you utilize a highly available setup of your observability system.

Redis Rate Limit Store for Rate Limiting

To utilize Envoy Gateway's global Rate-Limiting features, you need to hook it up to a Redis data store that acts as a global counter across all proxy instances.

The demo installation of TEG comes with a Redis instance deployed inside your Kubernetes cluster; however, we recommend using a hosted Redis store for production purposes.

Your OIDC Server for User Authentication

To enforce user authentication through OIDC for resources accessed via Envoy Gateway from browser-based applications, you must have an OIDC Provider where your application is registered as an OIDC Client.

Envoy Gateway will engage in an Authorization Code Flow with the OIDC Provider to obtain an ID and Access Token, which will be stored in cookies in the user's browser. The tokens can later be obtained on incoming requests to ensure that only logged-in users can access the resource behind login.

Next Steps

Envoy Gateway configures Envoy using the Gateway APIs. Read about them to learn about how to use TEG to deploy Envoy instances and how to give developers the tools to configure those Envoys to expose their applications.