System Design (HLD)TLS and Encryption in Transit

TLS and Encryption in Transit

LevelAdvanced

Duration90 mins

TopicTLS and Encryption in Transit

2 / 5

TLS Termination Points

Where Security Meets Architecture

In the previous page, we established what TLS does and how it works. But a critical architectural question remains: Where in your infrastructure should TLS connections terminate?

This seemingly simple question has profound implications for security, performance, operational complexity, and compliance. The point where encrypted traffic becomes unencrypted—the TLS termination point—is one of the most consequential decisions in system architecture.

Get it wrong, and you might expose sensitive data within your network, create performance bottlenecks, complicate debugging, or violate compliance requirements. Get it right, and you build a system that's secure, performant, and operationally manageable.

This page examines TLS termination strategies in depth: where termination can happen, what each choice implies, and how to make the right decision for your specific context.

What You Will Learn

By the end of this page, you will understand the different TLS termination strategies, their security implications, performance characteristics, and operational considerations. You'll be able to choose the appropriate termination point for different architectures—from simple web applications to complex microservices deployments.

Understanding TLS Termination

TLS termination is the point in your infrastructure where an encrypted TLS connection ends and the underlying plaintext protocol (HTTP, gRPC, database wire protocol) becomes accessible.

The termination point must:

Hold the private key for the server certificate
Perform cryptographic operations (handshake, encryption/decryption)
Have access to plaintext data after decryption

This makes the termination point security-critical. Compromise of this component means:

The private key could be stolen, allowing impersonation
Plaintext traffic could be intercepted
The encrypted session could be hijacked

The fundamental trade-off:

Terminating TLS earlier (closer to the client) simplifies internal architecture but exposes plaintext data to more internal components. Terminating later (closer to the application) keeps data encrypted longer but increases complexity and may impact performance.

Converting Mermaid diagram...

The question marks in the diagram represent the key decision points: Should traffic between each component be encrypted or unencrypted? Each choice creates a different security posture.

Common termination patterns:

Pattern	Termination Point	Encryption Scope
Edge Termination	CDN/Load Balancer	Internet only
Gateway Termination	API Gateway	Edge to gateway
Service Termination	Application Service	Edge to service
End-to-End	Application + Database	Edge to storage

Edge Termination

Edge termination is the most common pattern: TLS terminates at the edge of your network—typically a CDN, WAF, or load balancer—and internal traffic flows unencrypted or with separate encryption.

How it works:

Converting Mermaid diagram...

Advantages

•Simplified Certificate Management — Only edge devices need certificates. Applications don't handle TLS.
•Centralized Security — WAF, DDoS protection, and rate limiting can inspect plaintext traffic at the edge.
•Performance Offloading — Edge devices (often specialized hardware) handle CPU-intensive TLS operations.
•Easier Debugging — Internal traffic is plaintext; easier to capture and analyze.
•Lower Application Complexity — Applications don't need TLS configuration, certificate rotation, etc.

Risks and Limitations

•Internal Traffic Exposure — Anyone with network access sees plaintext: other tenants (in shared environments), compromised internal systems, malicious insiders.
•Compliance Gaps — Many regulations require encryption in transit 'everywhere,' not just internet-facing.
•Lateral Movement Risk — Attackers who breach one system can easily sniff internal traffic.
•Trust Boundary Ambiguity — 'Internal network is trusted' assumption is increasingly invalid.
•Private Key Concentration — All edge devices share the same private key (or keys).

The Death of the Trusted Network

Traditional perimeter security assumed internal networks were safe. Modern attacks (supply chain compromise, stolen credentials, insider threats) and cloud environments (shared infrastructure, ephemeral workloads) have proven this assumption dangerous. Zero trust architecture rejects implicit network trust—which means edge termination alone is often insufficient for sensitive systems.

When edge termination is appropriate:

Low-sensitivity applications where internal exposure risk is acceptable
Legacy systems that cannot support TLS internally
Environments with strong network isolation (dedicated physical networks, not shared cloud)
Performance-critical paths where internal TLS overhead is unacceptable and compensating controls exist

Compensating controls for edge termination:

If you must use edge termination, implement additional protections:

Network Segmentation: Isolate backend services in private subnets with no public access
Encrypted Overlay Networks: Use VPNs or network-level encryption (IPsec, WireGuard) for internal traffic
Access Controls: Strict firewall rules limiting which systems can communicate
Monitoring: Full packet capture capabilities to detect anomalies in internal traffic

Gateway Termination

Gateway termination pushes the termination point deeper into the architecture—to an API gateway or service mesh sidecar. This pattern maintains encryption beyond the edge while still centralizing TLS management.

Re-encryption (TLS Bridging):

A hybrid approach where the edge terminates the client connection but establishes a new TLS connection to internal services:

Converting Mermaid diagram...

TLS passthrough (Layer 4 routing):

Alternatively, the edge can route TLS traffic without terminating it, passing the encrypted connection directly to the destination:

Converting Mermaid diagram...

Gateway Termination Considerations

•Certificate per gateway — Each gateway instance needs certificates. Use automated issuance (e.g., cert-manager with Let's Encrypt or internal CA).
•SNI routing — With passthrough, the load balancer can only route based on SNI (Server Name Indication) since it cannot inspect the encrypted payload.
•Double encryption overhead — TLS bridging means encryption/decryption happens twice. Usually acceptable with modern hardware.
•Different trust levels — Edge-to-gateway can use internal CA certificates with shorter validity and automated rotation.
•Reduced edge inspection — With passthrough, edge cannot perform deep packet inspection or WAF analysis. Move these functions to the gateway.

nginx-tls-passthrough
NGINX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# NGINX configuration for TLS passthrough (Layer 4)
stream {
    # Upstream backend servers (TLS will pass through)
    upstream backend_servers {
        server backend1.internal:443;
        server backend2.internal:443;
    }
    
    # Map SNI to determine routing
    map $ssl_preread_server_name $backend {
        api.example.com     api_backend;
        web.example.com     web_backend;
        default             backend_servers;
    }
    
    server {
        listen 443;
        
        # Enable SNI reading without terminating TLS
        ssl_preread on;
        
        # Pass through to backend (no decryption)
        proxy_pass $backend;
        
        # Preserve client IP (requires PROXY protocol support on backend)
        proxy_protocol on;
    }
}

Client Certificate Forwarding

When using TLS bridging (terminate and re-encrypt), you lose the original client certificate information. If your backend needs client certificate data (for mTLS authentication), you must extract and forward it via headers (e.g., X-Client-Cert, X-Client-DN). Ensure backends validate that these headers come only from trusted proxies.

Service Termination

Service termination keeps TLS encryption all the way to the application service itself. Every service handles its own TLS termination, maintaining encryption throughout the internal network.

End-to-end encryption to services:

Converting Mermaid diagram...

Security Benefits

•True end-to-end encryption — Data is never unencrypted within the network.
•Reduced attack surface — Even internal attackers cannot intercept plaintext traffic.
•Compliance ready — Meets strict encryption-in-transit requirements.
•Service identity — Each service has its own certificate, enabling strong authentication.
•Defense in depth — Additional layer if edge security is bypassed.

Operational Challenges

•Certificate proliferation — Every service needs certificates; management at scale is complex.
•Debugging difficulty — Cannot inspect encrypted inter-service traffic without additional tooling.
•Performance overhead — Every hop includes TLS overhead; adds latency to internal calls.
•Application complexity — Each service must handle TLS configuration, certificate loading, etc.
•Key distribution — Private keys must reach services securely.

Making service termination manageable:

The operational challenges of service termination are real but solvable with proper infrastructure:

1. Service Meshes (Istio, Linkerd, Consul Connect):

Service meshes inject TLS handling into sidecar proxies, removing it from application code entirely. The application communicates over localhost HTTP; the sidecar handles all TLS operations.

┌─────────────────────────────────────────────┐
│                    Pod                       │
│  ┌─────────────────┐    ┌─────────────────┐ │
│  │   Application   │    │  Sidecar Proxy  │ │
│  │  (HTTP only)    │◄──►│  (mTLS handler) │ │
│  └─────────────────┘    └─────────────────┘ │
│           │                      │          │
│       localhost:8080         :15001 (mTLS)  │
└─────────────────────────────────────────────┘
                       ▲
                       │ mTLS to other services
                       ▼

2. Automated Certificate Issuance:

Tools like cert-manager (Kubernetes) or HashiCorp Vault automatically issue short-lived certificates to services, eliminating manual certificate management.

3. Application Libraries:

Libraries like gRPC provide built-in TLS support, letting the application load certificates at startup with minimal code.

The Service Mesh Trade-off

Service meshes solve mTLS complexity but introduce their own: additional sidecars consume resources, add latency (though minimal), and create new failure modes. For smaller deployments, the overhead may not be justified. For large microservices architectures, meshes are often the most practical path to universal encryption.

TLS Termination in Cloud Environments

Cloud providers offer managed load balancers and services with built-in TLS termination. Understanding how these work—and their security implications—is essential for cloud architects.

Cloud Provider TLS Termination Options
Provider	Service	Termination Type	Key Storage
AWS	Application Load Balancer (ALB)	Edge termination	AWS Certificate Manager (ACM)
AWS	Network Load Balancer (NLB)	Passthrough or TLS	ACM or upload custom
AWS	CloudFront	Edge (CDN) termination	ACM (free certs for CF)
GCP	Global HTTP(S) Load Balancer	Edge termination	Google-managed or custom
GCP	SSL Proxy Load Balancer	TLS termination (L4)	Google-managed or custom
Azure	Application Gateway	Edge termination	Key Vault or upload
Azure	Front Door	Edge (CDN) termination	Managed or custom

AWS-specific considerations:

ALB to target encryption: ALB supports re-encrypting traffic to EC2/ECS targets using separate certificates. Configure target groups for HTTPS. ALB validates target certificates unless you disable verification (not recommended).
NLB TLS: Network Load Balancer can terminate TLS (since 2019) or pass through TCP. For passthrough, use TCP listeners; targets see the original TLS connection.
ACM private certificates: ACM can issue private CA certificates for internal services, enabling internal mTLS without managing your own PKI infrastructure.

GCP-specific considerations:

Google-managed certificates: Free, automatically renewed certificates for domains. Use external HTTP(S) load balancer for automatic provisioning.
Cloud Armor integration: WAF inspection happens at the load balancer after TLS termination. Cannot inspect encrypted passthrough traffic.
Internal load balancers: Support TLS termination for service-to-service traffic within VPC.

terraform-aws-alb-https

Terraform (AWS)

# AWS ALB with TLS termination and re-encryption to targets
resource "aws_lb" "main" {
  name               = "secure-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.public_subnets
}
 
# HTTPS listener with ACM certificate
resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.main.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"  # TLS 1.3 preferred
  certificate_arn   = aws_acm_certificate.main.arn
 
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}
 
# Target group with HTTPS to instances (re-encryption)
resource "aws_lb_target_group" "app" {
  name        = "app-targets"
  port        = 443
  protocol    = "HTTPS"  # Re-encrypt to targets
  vpc_id      = var.vpc_id
  target_type = "instance"
 
  health_check {
    port     = 443
    protocol = "HTTPS"
    path     = "/health"
  }
}
 
# ACM certificate (auto-validated via DNS)
resource "aws_acm_certificate" "main" {
  domain_name       = "api.example.com"
  validation_method = "DNS"
 
  lifecycle {
    create_before_destroy = true
  }
}

Private Key Security in Cloud

When using cloud-managed load balancers, your private key resides in the cloud provider's infrastructure. For ACM and Google-managed certificates, you never have access to the private key. For custom certificates, you upload the key to the provider. Assess whether this meets your security requirements, especially for highly regulated workloads.

Kubernetes TLS Termination Patterns

Kubernetes adds layers of abstraction that affect where TLS terminates. Understanding these patterns is essential for securing Kubernetes workloads.

Kubernetes TLS Termination Points

•Cloud Load Balancer — Using type: LoadBalancer services with cloud-specific annotations for TLS. Termination happens outside the cluster.
•Ingress Controller — Most common pattern. NGINX Ingress, Traefik, or others terminate TLS at the ingress layer. Configure via Ingress resources or IngressClass.
•Gateway API — Newer standard (graduated to GA) with explicit TLSRoute and certificate attachment. More flexible than Ingress.
•Service Mesh Ingress — Istio Gateway, Linkerd ingress. TLS terminates at the mesh boundary.
•Pod-level TLS — Application containers handle TLS directly. Most complex but provides true end-to-end encryption.
•mTLS via Service Mesh — Service meshes handle all inter-pod TLS automatically via sidecars.

kubernetes-ingress-tls
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Kubernetes Ingress with TLS termination
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  namespace: production
  annotations:
    # Force HTTPS redirect
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    # HSTS header
    nginx.ingress.kubernetes.io/configuration-snippet: |
      add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls-secret  # Contains tls.crt and tls.key
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80  # Backend is HTTP (ingress handles TLS)
---
# Secret containing TLS certificate (created by cert-manager or manually)
apiVersion: v1
kind: Secret
metadata:
  name: api-tls-secret
  namespace: production
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-certificate>
  tls.key: <base64-encoded-private-key>

Use cert-manager for Automation

cert-manager is the de facto standard for automated certificate management in Kubernetes. It can automatically provision certificates from Let's Encrypt, Vault, or internal CAs, and stores them as Kubernetes Secrets. Combined with Ingress or Gateway API, you get fully automated TLS with automatic renewal.

Choosing the Right Termination Strategy

There's no universal best practice—the right termination strategy depends on your security requirements, architecture, compliance needs, and operational maturity.

Termination Strategy Decision Matrix
Factor	Edge Only	Gateway/Re-encrypt	End-to-End (mTLS)
Security Posture	Basic	Good	Excellent
Compliance Readiness	Limited	Most requirements	All requirements
Operational Complexity	Low	Medium	High (without mesh)
Performance Overhead	Minimal	Low	Moderate
Debugging Ease	Easy	Moderate	Difficult
Certificate Management	Simple	Moderate	Complex
Suitable For	Simple apps, legacy	API gateways, most apps	Microservices, high security

Decision Criteria

•Regulatory Requirements — PCI DSS, HIPAA, FedRAMP may mandate encryption for internal traffic. Check your specific requirements.
•Threat Model — What attacks are you defending against? If insider threats are a concern, encrypt internally. If only external, edge may suffice.
•Architecture Complexity — Monolith with trusted internal network? Edge termination is reasonable. Microservices in shared infrastructure? Consider mTLS.
•Team Capabilities — Do you have expertise to manage internal PKI? A service mesh? Choose what you can operate reliably.
•Performance Sensitivity — Sub-millisecond latency requirements may preclude multiple TLS hops. Benchmark before deciding.
•Multi-tenancy — Shared infrastructure (Kubernetes, cloud) increases internal exposure risk. Lean toward more encryption.

Evolve Over Time

Start with what you can operate reliably. Many organizations begin with edge termination and progressively add internal encryption as they mature. A working, well-understood security model beats a theoretically superior model that's misconfigured.

Summary: TLS Termination Points

We've explored the critical architectural decision of where to terminate TLS in distributed systems. Let's consolidate the key takeaways:

Key Takeaways

•Termination point is a security decision — Where you decrypt traffic determines who can access plaintext data. The termination point holds private keys and sees all traffic.
•Edge termination is simplest but least secure — Appropriate for low-sensitivity workloads or when compensating controls exist. Internal traffic is exposed.
•Gateway/re-encryption balances security and complexity — Maintains encryption deeper into the architecture while keeping management centralized.
•End-to-end encryption provides strongest protection — Essential for zero trust architectures. Service meshes make this operationally practical.
•Cloud and Kubernetes add abstraction layers — Understand where your cloud load balancer or ingress controller terminates TLS and what that means for your security.
•Choose based on your context — Threat model, compliance requirements, operational maturity, and architecture all influence the right choice.

What's next:

With termination strategies understood, the next page examines End-to-End Encryption—going beyond TLS to scenarios where even intermediate systems (like application servers) should not see plaintext data. We'll explore client-side encryption, envelope encryption, and architectures that minimize trust.

Page Complete

You now understand TLS termination strategies, from edge-only to full mTLS. You can evaluate where termination should happen based on security requirements, operational constraints, and architecture patterns. Next, we'll explore end-to-end encryption for scenarios requiring the highest levels of data protection.

2 / 5

Loading learning content...

System Design (HLD)TLS and Encryption in Transit

TLS and Encryption in Transit

LevelAdvanced

Duration90 mins

TopicTLS and Encryption in Transit

2 / 5

TLS Termination Points

Where Security Meets Architecture

In the previous page, we established what TLS does and how it works. But a critical architectural question remains: Where in your infrastructure should TLS connections terminate?

This page examines TLS termination strategies in depth: where termination can happen, what each choice implies, and how to make the right decision for your specific context.

What You Will Learn

Understanding TLS Termination

TLS termination is the point in your infrastructure where an encrypted TLS connection ends and the underlying plaintext protocol (HTTP, gRPC, database wire protocol) becomes accessible.

The termination point must:

Hold the private key for the server certificate
Perform cryptographic operations (handshake, encryption/decryption)
Have access to plaintext data after decryption

This makes the termination point security-critical. Compromise of this component means:

The private key could be stolen, allowing impersonation
Plaintext traffic could be intercepted
The encrypted session could be hijacked

The fundamental trade-off:

Converting Mermaid diagram...

The question marks in the diagram represent the key decision points: Should traffic between each component be encrypted or unencrypted? Each choice creates a different security posture.

Common termination patterns:

Pattern	Termination Point	Encryption Scope
Edge Termination	CDN/Load Balancer	Internet only
Gateway Termination	API Gateway	Edge to gateway
Service Termination	Application Service	Edge to service
End-to-End	Application + Database	Edge to storage

Edge Termination

How it works:

Converting Mermaid diagram...

Advantages

•Simplified Certificate Management — Only edge devices need certificates. Applications don't handle TLS.
•Centralized Security — WAF, DDoS protection, and rate limiting can inspect plaintext traffic at the edge.
•Performance Offloading — Edge devices (often specialized hardware) handle CPU-intensive TLS operations.
•Easier Debugging — Internal traffic is plaintext; easier to capture and analyze.
•Lower Application Complexity — Applications don't need TLS configuration, certificate rotation, etc.

Risks and Limitations

•Internal Traffic Exposure — Anyone with network access sees plaintext: other tenants (in shared environments), compromised internal systems, malicious insiders.
•Compliance Gaps — Many regulations require encryption in transit 'everywhere,' not just internet-facing.
•Lateral Movement Risk — Attackers who breach one system can easily sniff internal traffic.
•Trust Boundary Ambiguity — 'Internal network is trusted' assumption is increasingly invalid.
•Private Key Concentration — All edge devices share the same private key (or keys).

The Death of the Trusted Network

When edge termination is appropriate:

Low-sensitivity applications where internal exposure risk is acceptable
Legacy systems that cannot support TLS internally
Environments with strong network isolation (dedicated physical networks, not shared cloud)
Performance-critical paths where internal TLS overhead is unacceptable and compensating controls exist

Compensating controls for edge termination:

If you must use edge termination, implement additional protections:

Network Segmentation: Isolate backend services in private subnets with no public access
Encrypted Overlay Networks: Use VPNs or network-level encryption (IPsec, WireGuard) for internal traffic
Access Controls: Strict firewall rules limiting which systems can communicate
Monitoring: Full packet capture capabilities to detect anomalies in internal traffic

Gateway Termination

Re-encryption (TLS Bridging):

A hybrid approach where the edge terminates the client connection but establishes a new TLS connection to internal services:

Converting Mermaid diagram...

TLS passthrough (Layer 4 routing):

Alternatively, the edge can route TLS traffic without terminating it, passing the encrypted connection directly to the destination:

Converting Mermaid diagram...

Gateway Termination Considerations

•Certificate per gateway — Each gateway instance needs certificates. Use automated issuance (e.g., cert-manager with Let's Encrypt or internal CA).
•SNI routing — With passthrough, the load balancer can only route based on SNI (Server Name Indication) since it cannot inspect the encrypted payload.
•Double encryption overhead — TLS bridging means encryption/decryption happens twice. Usually acceptable with modern hardware.
•Different trust levels — Edge-to-gateway can use internal CA certificates with shorter validity and automated rotation.
•Reduced edge inspection — With passthrough, edge cannot perform deep packet inspection or WAF analysis. Move these functions to the gateway.

nginx-tls-passthrough
NGINX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# NGINX configuration for TLS passthrough (Layer 4)
stream {
    # Upstream backend servers (TLS will pass through)
    upstream backend_servers {
        server backend1.internal:443;
        server backend2.internal:443;
    }
    
    # Map SNI to determine routing
    map $ssl_preread_server_name $backend {
        api.example.com     api_backend;
        web.example.com     web_backend;
        default             backend_servers;
    }
    
    server {
        listen 443;
        
        # Enable SNI reading without terminating TLS
        ssl_preread on;
        
        # Pass through to backend (no decryption)
        proxy_pass $backend;
        
        # Preserve client IP (requires PROXY protocol support on backend)
        proxy_protocol on;
    }
}

Client Certificate Forwarding

Service Termination

Service termination keeps TLS encryption all the way to the application service itself. Every service handles its own TLS termination, maintaining encryption throughout the internal network.

End-to-end encryption to services:

Converting Mermaid diagram...

Security Benefits

•True end-to-end encryption — Data is never unencrypted within the network.
•Reduced attack surface — Even internal attackers cannot intercept plaintext traffic.
•Compliance ready — Meets strict encryption-in-transit requirements.
•Service identity — Each service has its own certificate, enabling strong authentication.
•Defense in depth — Additional layer if edge security is bypassed.

Operational Challenges

•Certificate proliferation — Every service needs certificates; management at scale is complex.
•Debugging difficulty — Cannot inspect encrypted inter-service traffic without additional tooling.
•Performance overhead — Every hop includes TLS overhead; adds latency to internal calls.
•Application complexity — Each service must handle TLS configuration, certificate loading, etc.
•Key distribution — Private keys must reach services securely.

Making service termination manageable:

The operational challenges of service termination are real but solvable with proper infrastructure:

1. Service Meshes (Istio, Linkerd, Consul Connect):

Service meshes inject TLS handling into sidecar proxies, removing it from application code entirely. The application communicates over localhost HTTP; the sidecar handles all TLS operations.

┌─────────────────────────────────────────────┐
│                    Pod                       │
│  ┌─────────────────┐    ┌─────────────────┐ │
│  │   Application   │    │  Sidecar Proxy  │ │
│  │  (HTTP only)    │◄──►│  (mTLS handler) │ │
│  └─────────────────┘    └─────────────────┘ │
│           │                      │          │
│       localhost:8080         :15001 (mTLS)  │
└─────────────────────────────────────────────┘
                       ▲
                       │ mTLS to other services
                       ▼

2. Automated Certificate Issuance:

Tools like cert-manager (Kubernetes) or HashiCorp Vault automatically issue short-lived certificates to services, eliminating manual certificate management.

3. Application Libraries:

Libraries like gRPC provide built-in TLS support, letting the application load certificates at startup with minimal code.

The Service Mesh Trade-off

TLS Termination in Cloud Environments

Cloud providers offer managed load balancers and services with built-in TLS termination. Understanding how these work—and their security implications—is essential for cloud architects.

Cloud Provider TLS Termination Options
Provider	Service	Termination Type	Key Storage
AWS	Application Load Balancer (ALB)	Edge termination	AWS Certificate Manager (ACM)
AWS	Network Load Balancer (NLB)	Passthrough or TLS	ACM or upload custom
AWS	CloudFront	Edge (CDN) termination	ACM (free certs for CF)
GCP	Global HTTP(S) Load Balancer	Edge termination	Google-managed or custom
GCP	SSL Proxy Load Balancer	TLS termination (L4)	Google-managed or custom
Azure	Application Gateway	Edge termination	Key Vault or upload
Azure	Front Door	Edge (CDN) termination	Managed or custom

AWS-specific considerations:

ALB to target encryption: ALB supports re-encrypting traffic to EC2/ECS targets using separate certificates. Configure target groups for HTTPS. ALB validates target certificates unless you disable verification (not recommended).
NLB TLS: Network Load Balancer can terminate TLS (since 2019) or pass through TCP. For passthrough, use TCP listeners; targets see the original TLS connection.
ACM private certificates: ACM can issue private CA certificates for internal services, enabling internal mTLS without managing your own PKI infrastructure.

GCP-specific considerations:

Google-managed certificates: Free, automatically renewed certificates for domains. Use external HTTP(S) load balancer for automatic provisioning.
Cloud Armor integration: WAF inspection happens at the load balancer after TLS termination. Cannot inspect encrypted passthrough traffic.
Internal load balancers: Support TLS termination for service-to-service traffic within VPC.

terraform-aws-alb-https

Terraform (AWS)

# AWS ALB with TLS termination and re-encryption to targets
resource "aws_lb" "main" {
  name               = "secure-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.public_subnets
}
 
# HTTPS listener with ACM certificate
resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.main.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"  # TLS 1.3 preferred
  certificate_arn   = aws_acm_certificate.main.arn
 
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}
 
# Target group with HTTPS to instances (re-encryption)
resource "aws_lb_target_group" "app" {
  name        = "app-targets"
  port        = 443
  protocol    = "HTTPS"  # Re-encrypt to targets
  vpc_id      = var.vpc_id
  target_type = "instance"
 
  health_check {
    port     = 443
    protocol = "HTTPS"
    path     = "/health"
  }
}
 
# ACM certificate (auto-validated via DNS)
resource "aws_acm_certificate" "main" {
  domain_name       = "api.example.com"
  validation_method = "DNS"
 
  lifecycle {
    create_before_destroy = true
  }
}

Private Key Security in Cloud

Kubernetes TLS Termination Patterns

Kubernetes adds layers of abstraction that affect where TLS terminates. Understanding these patterns is essential for securing Kubernetes workloads.

Kubernetes TLS Termination Points

•Cloud Load Balancer — Using type: LoadBalancer services with cloud-specific annotations for TLS. Termination happens outside the cluster.
•Ingress Controller — Most common pattern. NGINX Ingress, Traefik, or others terminate TLS at the ingress layer. Configure via Ingress resources or IngressClass.
•Gateway API — Newer standard (graduated to GA) with explicit TLSRoute and certificate attachment. More flexible than Ingress.
•Service Mesh Ingress — Istio Gateway, Linkerd ingress. TLS terminates at the mesh boundary.
•Pod-level TLS — Application containers handle TLS directly. Most complex but provides true end-to-end encryption.
•mTLS via Service Mesh — Service meshes handle all inter-pod TLS automatically via sidecars.

kubernetes-ingress-tls
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Kubernetes Ingress with TLS termination
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  namespace: production
  annotations:
    # Force HTTPS redirect
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    # HSTS header
    nginx.ingress.kubernetes.io/configuration-snippet: |
      add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls-secret  # Contains tls.crt and tls.key
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80  # Backend is HTTP (ingress handles TLS)
---
# Secret containing TLS certificate (created by cert-manager or manually)
apiVersion: v1
kind: Secret
metadata:
  name: api-tls-secret
  namespace: production
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-certificate>
  tls.key: <base64-encoded-private-key>

Use cert-manager for Automation

Choosing the Right Termination Strategy

There's no universal best practice—the right termination strategy depends on your security requirements, architecture, compliance needs, and operational maturity.

Termination Strategy Decision Matrix
Factor	Edge Only	Gateway/Re-encrypt	End-to-End (mTLS)
Security Posture	Basic	Good	Excellent
Compliance Readiness	Limited	Most requirements	All requirements
Operational Complexity	Low	Medium	High (without mesh)
Performance Overhead	Minimal	Low	Moderate
Debugging Ease	Easy	Moderate	Difficult
Certificate Management	Simple	Moderate	Complex
Suitable For	Simple apps, legacy	API gateways, most apps	Microservices, high security

Decision Criteria

•Regulatory Requirements — PCI DSS, HIPAA, FedRAMP may mandate encryption for internal traffic. Check your specific requirements.
•Threat Model — What attacks are you defending against? If insider threats are a concern, encrypt internally. If only external, edge may suffice.
•Architecture Complexity — Monolith with trusted internal network? Edge termination is reasonable. Microservices in shared infrastructure? Consider mTLS.
•Team Capabilities — Do you have expertise to manage internal PKI? A service mesh? Choose what you can operate reliably.
•Performance Sensitivity — Sub-millisecond latency requirements may preclude multiple TLS hops. Benchmark before deciding.
•Multi-tenancy — Shared infrastructure (Kubernetes, cloud) increases internal exposure risk. Lean toward more encryption.

Evolve Over Time

Summary: TLS Termination Points

We've explored the critical architectural decision of where to terminate TLS in distributed systems. Let's consolidate the key takeaways:

Key Takeaways

•Termination point is a security decision — Where you decrypt traffic determines who can access plaintext data. The termination point holds private keys and sees all traffic.
•Edge termination is simplest but least secure — Appropriate for low-sensitivity workloads or when compensating controls exist. Internal traffic is exposed.
•Gateway/re-encryption balances security and complexity — Maintains encryption deeper into the architecture while keeping management centralized.
•End-to-end encryption provides strongest protection — Essential for zero trust architectures. Service meshes make this operationally practical.
•Cloud and Kubernetes add abstraction layers — Understand where your cloud load balancer or ingress controller terminates TLS and what that means for your security.
•Choose based on your context — Threat model, compliance requirements, operational maturity, and architecture all influence the right choice.

What's next:

Page Complete

2 / 5