In the world of cloud-native applications, securing traffic with TLS/SSL is non-negotiable. But deciding where to decrypt that traffic at the ingress controller or at the backend can be tricky. Should you terminate TLS at the edge for rich routing and inspection, or keep encryption end-to-end for maximum security? Spoiler: sometimes you do both.

This post breaks down the essentials of Passthrough vs TLS/SSL Termination, and adds a real-world case scenario where both modes coexist in a single application architecture.

• TLS/SSL Termination: Decrypts traffic at ingress (Layer 7), enabling advanced routing, WAF, and centralized cert management.
• TLS/SSL Passthrough: Forwards encrypted traffic directly to backend (Layer 4), preserving end-to-end encryption.
• Use termination for rich L7 features and centralized certs.
• Use passthrough when backend services require mTLS or custom TLS handling.
• Some applications benefit from both modes simultaneously for different components.

What Are TLS/SSL Termination and Passthrough?

TLS/SSL Termination

This is when the ingress controller (or load balancer) decrypts the incoming TLS/SSL traffic at the edge (layer 7). The controller holds the TLS certificates and keys, terminates the encrypted connection, and then forwards the decrypted HTTP traffic to backend services. This allows the controller to inspect HTTP headers, perform routing based on host/path, apply WAF rules, etc.

TLS/SSL Passthrough

In passthrough mode, the ingress controller does not decrypt the TLS traffic. Instead, it forwards the encrypted traffic directly to the backend service (layer 4). The backend service is responsible for terminating TLS. This means the ingress controller cannot inspect HTTP headers or perform L7 routing decisions on the encrypted traffic.

Real-World Use Cases

When to Use TLS/SSL Termination

• Centralized certificate management.
• Path or host-based routing.
• WAF, rate limiting, header manipulation.
• Detailed HTTP logging and monitoring.

When to Use TLS/SSL Passthrough

• Backend services require mutual TLS (mTLS).
• True end-to-end encryption is mandatory.
• Simple routing based on IP/port or SNI.
• Avoid duplicating certificates on ingress.

Practical Configuration Notes

• Enable passthrough with enableTLSPassthrough: true (or enableSSLPassthrough: true).
• Must enable controller.enableCustomResources: true for CRDs.
• Passthrough usually listens on port 443.
• Certificates live on backend services for passthrough; on ingress for termination.

Verification & Troubleshooting

• Confirm passthrough enabled in ingress controller config.
• Use openssl s_client -connect yourdomain.com:443 to verify cert source.
• Check logs: passthrough shows TCP connections only; termination shows HTTP logs.
• Ensure backend services respond to TCP health checks.
• Verify SNI routing if used.

Pros and Cons

Decision Checklist

• Need path or host-based routing? → Termination
• Require mTLS at backend? → Passthrough
• Want centralized cert management? → Termination
• Need end-to-end encryption without ingress decryption? → Passthrough
• Want WAF, rate limiting, header mods? → Termination
• Is your ingress controller configured with CRDs enabled? → Required for passthrough

Traffic Flow Diagram (Textual)

TLS/SSL Termination:

Client → (Encrypted TLS) → Ingress Controller (Decrypts TLS) → (Plain HTTP) → Backend Service

TLS/SSL Passthrough:

Client → (Encrypted TLS) → Ingress Controller (Forwards encrypted traffic) → Backend Service (Decrypts TLS)

Case Scenario: Hybrid Application Using Both TLS Termination and Passthrough

Application Description

Imagine a financial SaaS platform with two main components:

1. Public API Gateway:
   • Handles user-facing REST API calls.
   • Requires path-based routing, WAF, rate limiting, and centralized certificate management.
   • TLS terminated at ingress for rich L7 features.
2. Internal Payment Processing Service:
   • Handles sensitive payment transactions.
   • Requires strict mutual TLS (mTLS) authentication and end-to-end encryption.
   • TLS passthrough to backend service for backend-managed certs and mTLS.

Why Use Both?

• The API Gateway benefits from ingress TLS termination to apply security policies and route requests efficiently.
• The Payment Service demands end-to-end encryption and mTLS, so passthrough ensures ingress does not decrypt or interfere with sensitive traffic.

Simple Flow

Client
  │
  │ TLS (443)
  ▼
Ingress Controller
  ├─ TLS Termination (port 443) → API Gateway Service (HTTP)
  │      (WAF, routing, certs at ingress)
  │
  └─ TLS Passthrough (port 443) → Payment Processing Service (TLS)
         (mTLS, backend certs, end-to-end encryption)

Sample Configuration Snippets

Ingress Controller Config (values.yaml or similar):

controller:
  enableCustomResources: true
  enableTLSPassthrough: true

Ingress Resource for API Gateway (TLS Termination):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-gateway-ingress
spec:
  tls:
  - hosts:
    - api.oladapo.cloud
    secretName: api-gateway-tls-secret
  rules:
  - host: api.oladapo.cloud
    http:
      paths:
      - path: /v1/
        pathType: Prefix
        backend:
          service:
            name: api-gateway-service
            port:
              number: 80

Ingress Resource for Payment Service (TLS Passthrough):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: payment-service-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  rules:
  - host: payments.oladapo.cloud
    tcp:
      paths:
      - backend:
          serviceName: payment-service
          servicePort: 443

Note: Actual syntax depends on ingress controller (e.g., NGINX, Traefik). The key is enabling passthrough annotation and CRDs.

Security & Operational Rationale

• API Gateway:
  Centralized certs simplify management; ingress can inspect and block malicious traffic early.
• Payment Service:
  Backend controls certs and mTLS policies, ensuring compliance with strict financial regulations.
• Operational:
  Enables separation of concerns security policies at ingress for public API, strict encryption and auth at backend for sensitive data.

Verification Steps

1. Check ingress controller config:
   Confirm enableTLSPassthrough: true and controller.enableCustomResources: true.
2. Test API Gateway TLS termination:
   openssl s_client -connect api.oladapo.cloud:443
   Certificate should be the ingress controller’s cert.
3. Test Payment Service TLS passthrough:
   openssl s_client -connect payments.oladapo.cloud:443
   Certificate should be the backend payment service’s cert.
4. Inspect logs:
   • API Gateway traffic shows HTTP logs, WAF events.
   • Payment Service traffic shows TCP connection logs only at ingress.
5. Health checks:
   Ensure backend payment service responds to TCP health checks.
6. mTLS validation:
   Confirm mutual TLS handshake succeeds between client and payment service.

By understanding the trade-offs and capabilities of TLS/SSL termination and passthrough, architects and engineers can design secure, scalable, and compliant systems that meet diverse operational needs. Whether you are managing a simple microservice or a complex financial platform, mastering these concepts is key to building resilient and secure cloud-native applications.