JWT Authentication and Authorization on Egress Gateways

Egress gateways support server-level JWT authentication and authorization on individual HTTP server entries, in the same way as ingress gateways. This lets you validate that requests from mesh workloads carry a trusted JWT token before forwarding traffic to an external service, and apply fine-grained authorization rules based on JWT claims.

OIDC not supported

OIDC authentication is not supported on egress gateway servers. Only JWT authentication (authentication.jwt) is permitted.

Authentication and authorization options for egress

TSB provides two mechanisms for controlling access to external services through an egress gateway:

Mechanism	Field	How it works
Egress authorization	spec.egressAuthorization	Coarse-grained allow/deny by source service account or TSB resource (Tenant, Workspace, Group), applied across the gateway using Envoy filters.
Server-level authorization	spec.http[].authorization	Fine-grained rules per external hostname, based on JWT claims. Implemented as an Istio AuthorizationPolicy.

Both can be used together, subject to the interaction rules described below.

Configure JWT authentication

Add authentication.jwt to an egress HTTP server to require that all requests from mesh workloads carry a valid JWT token. The gateway rejects requests that do not present a valid token.

apiVersion: gateway.tsb.tetrate.io/v2
kind: Gateway
metadata:
  name: shared-egress-gateway
  annotations:
    tsb.tetrate.io/organization: tetrate
    tsb.tetrate.io/tenant: platform
    tsb.tetrate.io/workspace: egress-ws
    tsb.tetrate.io/gatewayGroup: egress-gg
spec:
  workloadSelector:
    namespace: egress
    labels:
      app: egress-gateway
  http:
    - name: httpbin
      hostname: httpbin.org
      trafficMode: EGRESS
      routing:
        rules:
          - route:
              serviceDestination:
                host: egress/httpbin.org
                tls:
                  mode: SIMPLE
                  files:
                    caCertificates: "/etc/ssl/certs/ca-certificates.crt"
      authentication:
        jwt:
          issuer: "https://auth.example.com"
          jwksUri: "https://auth.example.com/.well-known/jwks.json"
          outputPayloadToHeader: x-jwt-payload

Configure server-level authorization

Add authorization to an egress HTTP server to restrict which JWT principals can access the external service, and optionally restrict by HTTP method or path.

The following example allows requests only from clients whose JWT token was issued by https://auth.example.com with the subject payments-service@example.com:

  http:
    - name: payment-api
      hostname: api.payment-provider.com
      trafficMode: EGRESS
      routing:
        rules:
          - route:
              serviceDestination:
                host: egress/api.payment-provider.com
                tls:
                  mode: SIMPLE
                  files:
                    caCertificates: "/etc/ssl/certs/ca-certificates.crt"
      authentication:
        jwt:
          issuer: "https://auth.example.com"
          jwksUri: "https://auth.example.com/.well-known/jwks.json"
          outputPayloadToHeader: x-jwt-payload
      authorization:
        local:
          rules:
            - name: payments-service-only
              from:
                - jwt:
                    iss: "https://auth.example.com"
                    sub: "payments-service@example.com"
              to:
                - methods:
                    - GET
                    - POST
                  paths:
                    - "/v1/payments/*"

Interaction with egressAuthorization

When both egressAuthorization and server-level authorization are configured on the same gateway, the following rules apply:

Scenario	Behaviour
Only egressAuthorization configured for a hostname	EnvoyFilter is created (existing behaviour). No AuthorizationPolicy is created.
Only server-level authorization configured for a hostname	AuthorizationPolicy is created from the server rules. No EnvoyFilter is created.
Both configured for the same hostname	Server-level authorization takes precedence. AuthorizationPolicy is created. No EnvoyFilter is created, to prevent the filter from overriding the policy.
Both configured for different hostnames	Both work independently. EnvoyFilter is created for the egressAuthorization hostname; AuthorizationPolicy is created for the server-level hostname.

tip

If you are migrating from egressAuthorization to server-level authorization for a hostname, remove the egressAuthorization entry for that hostname once the server-level policy is in place, to keep the configuration clear.