Gateway Ingress Security: TLS Bridging vs TLS Termination
When deploying a reverse proxy API Gateway, systems select between two security patterns:
1. TLS Termination (Offloading)
The client establishes a TLS connection to the reverse proxy. The proxy decrypts the packets, inspects the HTTP headers, and forwards *unencrypted* plain HTTP traffic to private backend servers inside the secure VPC.
**Advantage**: Minimal CPU load on internal application servers, simple header lookups.
2. TLS Bridging (End-to-End Encryption)
The reverse proxy decrypts client packets, inspects them, and immediately *re-encrypts* them to establish a secondary TLS connection to the backend server nodes (using internal CA certificates).
**Advantage**: Zero plaintext leakage, strict corporate compliance (e.g. PCI-DSS), preventing packet interception on internal service networks.
API Gateway Responsibilities (Beyond TLS)
In microservice interviews, "reverse proxy" often means a full API gateway — Kong, Envoy, AWS API Gateway, or NGINX with plugins. Core duties beyond TLS termination:
- Authentication & authorization: Validate JWT/OAuth tokens once at the edge; forward trusted identity headers to internal services.
- Rate limiting & quotas: Per API key, per IP, per tenant — return 429 with Retry-After before traffic hits fragile backends.
- Request routing & versioning: Route
/v1/* to legacy cluster, /v2/* to new deployment; A/B traffic splits by header or percentage. - Protocol translation: Terminate public REST/JSON and fan in to internal gRPC — browsers cannot speak gRPC natively without gRPC-Web.
- Observability injection: Attach trace IDs, emit access logs, and aggregate latency metrics at the edge.
Keep business logic out of the gateway — it should enforce cross-cutting policies, not implement domain rules. See API Contract & Integration Design for error and versioning conventions the gateway exposes.