Security

Overview

Envoy Gateway provides north-south security at the edge of the cluster. It handles TLS termination for incoming client traffic, TLS origination to backend services, JWT authentication, rate limiting, and CORS. Unlike full service meshes, it does not manage east-west mTLS between in-cluster services.

See also: index, architecture, operations

1. TLS Termination

Envoy Gateway terminates TLS at the gateway proxy for incoming client connections. Configuration is done through standard Gateway API resources.

graph LR
    Client["Client<br/>(HTTPS)"] -->|TLS terminated| EG["Envoy Gateway Proxy"]
    EG -->|plaintext or TLS| Backend["Backend Service"]

Configuration

TLS certificates are stored as Kubernetes Secrets and referenced in the Gateway listener configuration:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: eg
spec:
  gatewayClassName: eg
  listeners:
  - name: https
    protocol: HTTPS
    port: 8443
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: example-cert

Key points:

• mode: Terminate -- the gateway decrypts client TLS and forwards plaintext to backends
• mode: Passthrough -- TLS is passed through to the backend; the gateway does not decrypt
• Supports multiple certificates per listener via SNI (Server Name Indication)

2. Backend TLS (Gateway to Backend)

The BackendTLSPolicy resource configures TLS between the gateway and backend services. This enables end-to-end encryption even when the gateway terminates client TLS.

apiVersion: gateway.networking.k8s.io/v1alpha3
kind: BackendTLSPolicy
metadata:
  name: example-backend-tls
spec:
  targetRefs:
  - group: ""
    kind: Service
    name: backend-service
  validation:
    hostname: backend.example.com
    caCertificateRefs:
    - name: backend-ca
      group: ""
      kind: ConfigMap
    subjectAltNames:
    - san.backend.example.com

Validation fields:

Field	Purpose
hostname	SNI hostname the gateway sends when connecting to the backend
caCertificateRefs	References to CA certificates for validating backend certificates
wellKnownCACertificates	Use system CA certificates instead of custom refs
subjectAltNames	SANs that the backend certificate must match

3. Backend mTLS

For backends that require mutual TLS (client certificates from the gateway), Envoy Gateway provides the Backend CRD:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: Backend
metadata:
  name: mtls-backend
spec:
  endpoints:
  - fqdn:
      hostname: secure-backend.default.svc.cluster.local
      port: 443
  tls:
    clientCertificateRef:
      kind: Secret
      name: gateway-client-cert
    caCertificateRefs:
    - group: ""
      kind: ConfigMap
      name: backend-ca

This configures the gateway to present a client certificate and validate the backend's certificate, achieving full mTLS on the gateway-to-backend leg.

4. JWT Authentication

Envoy Gateway supports JWT validation through the SecurityPolicy CRD. This validates JWT tokens in incoming requests before forwarding them to backends.

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: jwt-auth
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: backend
  jwt:
    providers:
    - name: example
      remoteJWKS:
        uri: https://YOUR_DOMAIN/.well-known/jwks.json
      claimToHeaders:
      - claim: sub
        header: x-subject

Features:

• Remote JWKS verification via HTTPS
• Inline JWKS for air-gapped environments
• Claim-to-header extraction for passing identity to backends
• Multiple provider support for different audiences/issuers
• recomputeRoute option for claim-based routing after JWT validation

5. External Authorization (ExtAuth)

For custom authentication logic, Envoy Gateway supports delegating authorization decisions to an external service via gRPC or HTTP. This is configured within the SecurityPolicy CRD:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: ext-auth
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: backend
  extAuth:
    grpc:
      backendRefs:
      - name: auth-service
        port: 9000
        namespace: auth
      backendTLSPolicyRef:
        name: ext-auth-tls

External Authorization Security

The external auth service receives all request headers. Ensure the auth service is trusted and the communication channel is secured with BackendTLSPolicy.

6. Rate Limiting

Rate limiting provides defense against application-layer abuse and DDoS attacks. Envoy Gateway supports two modes:

Local Rate Limiting

Applied per-proxy instance with in-memory counters. No external backend required. Configured via RateLimitFilter in HTTPRoute rule filters.

Global Rate Limiting

Uses a shared Redis backend and the envoyproxy/ratelimit service for distributed rate limiting across all proxy instances:

# EnvoyGateway configuration
rateLimit:
  backend:
    type: Redis
    redis:
      url: redis.redis-system.svc.cluster.local:6379

7. CORS

CORS (Cross-Origin Resource Sharing) is configured on HTTPRoute resources to control which origins, methods, and headers are permitted for browser-based clients. Envoy Gateway translates CORS settings into Envoy CORS filter configuration.

8. Security Policy Summary

Layer	Mechanism	Resource
Client-to-Gateway TLS	TLS termination	Gateway listener with certificateRefs
Gateway-to-Backend TLS	Backend TLS origination	BackendTLSPolicy
Gateway-to-Backend mTLS	Client certificate + CA validation	Backend CRD with tls config
JWT validation	Token verification	SecurityPolicy (jwt section)
Custom auth	External authorization	SecurityPolicy (extAuth section)
Rate limiting	Per-instance or global	RateLimitFilter + EnvoyGateway config
CORS	Origin filtering	HTTPRoute CORS settings

Scope Note

Envoy Gateway handles north-south (ingress) security. For east-west (service-to-service) mTLS within the cluster, use a service mesh like Istio or Linkerd alongside Envoy Gateway. See service-mesh/istio/security or service-mesh/linkerd/security.