Tetrate Enterprise Envoy Gateway (TEG) is composed of four primary components:
- Envoy Gateway, which brings Envoy
- Redis, which is used for rate limiting
- Envoy rate limit service, which is an open source project used in production for years for rate limiting
- Tetrate Enterprise Envoy Gateway (TEG) Manager (TEG Manager), which translates OIDC config and performs periodic update checking
On the Request Path
On the request path — the path that handles user data — Envoy is the primary component. When rate limiting is enabled and configured for a route that matches the current request, Envoy will call Redis for a quota decision. When authentication is enabled and configured for a route that matches the current request, Envoy will call authservice — which calls your OIDC provider, performs the OAuth dance with users, and caches the tokens in Redis. After applying those and any other policy (like redirects, header or URL rewrites, etc.), Envoy forwards the request on to an instance of your application.
Envoy is a load balancer: it receives traffic from many clients, applies some policy (like rate limiting, authentication, and routing) then load balances requests across instances of the destination service.
Rate Limit Service
The rate limit service is a light weight built-for-purpose service responsible for implementing Envoy's rate limit API, caching user quota tokens, and ultimately storing information in Redis. It's been used for years in production at Lyft and at a variety of other organizations.
Redis is a high performance in memory data store. We include Redis for rate limiting. Because of the failure modes related to Redis (see our admin guide), we strongly recommend you bring your own (supported) Redis when using TEG in production. The Redis we package as part of the demo installation is suitable for testing and lower environments, but should not be depended on in production.
Your OIDC Provider
If you're using TEG for application authentication, then your OIDC provider will be on request path to issue and authenticate user tokens.
Management and Control
Outside of the request path, we have the components responsible for managing and controlling the request path systems. The most important of these is Envoy Gateway, which manages and serves Envoy. TEG Manager is responsible for writing authentication configuration to the Kubernetes API server for EG to process, as well as periodically checking for updates.
Envoy Gateway is the open source project by the Envoy community designed to make Envoy easy to use for ingress. It has two primary functions for us:
- It deploys and manages sets of Envoys, based on
Gatewayresources that are defined.
- Configures those Envoys at runtime based on
Routeresources published by application developers. That configuration includes information on how to serve each application and service discovery of application instances for load balancing
Tetrate Enterprise Envoy Gateway (TEG) Manager
TEG Manager is built by Tetrate and is responsible for transforming authentication configuration (as well as configuring authservice), and for phoning home to Tetrate to check for CVE status. On phone home it includes usage data on EG, and receives update and vulnerability information about all components in the deployment. It marks those deployments to notify operators.
Two major roadmap items will depend on TEG Manager in the near future:
- TEG Manager will act as a local service discovery shim for a variety of systems (like Consul) to enable EG to route to applications in those systems, not just services in Kubernetes.
- TEG Manager will offer opt in auto-updates for Envoy Gateway (and therefore Envoy), as well as Redis and the rate limit service, in addition to just marking the presence of CVEs and available updates.
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.