Episode ini membahas keamanan transport Envoy: TLS termination di listener, TLS origination ke upstream, mutual TLS antar service, serta certificate rotation dan integrasi SDS untuk mengelola sertifikat.

Dunia microservices tidak berjalan di HTTP polos. Episode 6 mengamankan jalur traffic dengan TLS dan mTLS: kalian akan belajar mengenkripsi koneksi dari klien ke Envoy (termination), dari Envoy ke backend (origination), dan akhirnya mutual TLS di mana kedua sisi saling memverifikasi identitas.
Topik ini juga memperkenalkan SDS — Secret Discovery Service — yang mengotomatiskan rotasi sertifikat tanpa restart. Di akhir episode, kalian akan memahami kenapa service mesh seperti Istio bisa menghidupkan mTLS antar service hanya dengan konfigurasi.
Sebelum konfigurasi, buat sertifikat uji dengan openssl:
openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
-keyout ~/envoy-lab/certs/ca-key.pem -out ~/envoy-lab/certs/ca.pem \
-subj "/CN=Envoy Lab CA"
openssl req -newkey rsa:2048 -nodes \
-keyout ~/envoy-lab/certs/server-key.pem -out ~/envoy-lab/certs/server.csr \
-subj "/CN=envoy.example.com"
openssl x509 -req -in ~/envoy-lab/certs/server.csr \
-CA ~/envoy-lab/certs/ca.pem -CAkey ~/envoy-lab/certs/ca-key.pem \
-CAcreateserial -out ~/envoy-lab/certs/server.pem -days 365Perintah openssl x509 -req menandatangani CSR server dengan CA yang baru dibuat. Hasilnya adalah pasangan server.pem dan server-key.pem plus CA ca.pem yang akan dipakai untuk verifikasi.
Untuk menerima HTTPS di Envoy, tambahkan transport socket TLS pada listener:
listeners:
- name: listener_tls
address:
socket_address:
address: 0.0.0.0
port_value: 10443
filter_chains:
- transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
common_tls_context:
tls_certificates:
- certificate_chain:
filename: /etc/envoy/certs/server.pem
private_key:
filename: /etc/envoy/certs/server-key.pem
filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: tls_ingress
route_config:
name: tls_routes
virtual_hosts:
- name: tls_vh
domains:
- "envoy.example.com"
routes:
- match:
prefix: "/"
route:
cluster: api_service
http_filters:
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.RouterBagian kunci adalah DownstreamTlsContext yang memberitahu Envoy bagaimana mengamankan koneksi dari klien. Karena file sertifikat dimount dari direktori certs, pastikan mount volume menyertakan direktori tersebut saat menjalankan kontainer.
Arah sebaliknya: Envoy mengenkripsi koneksi ke backend. Konfigurasi ini berada di transport socket cluster:
clusters:
- name: secure_backend
connect_timeout: 0.25s
type: STRICT_DNS
lb_policy: ROUND_ROBIN
transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
common_tls_context:
validation_context:
trusted_ca:
filename: /etc/envoy/certs/ca.pem
match_subject_alt_names:
- exact: backend.internal
load_assignment:
cluster_name: secure_backend
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: backend.internal
port_value: 8443UpstreamTlsContext memberitahu Envoy untuk mengencrypt koneksi ke backend dan memverifikasi sertifikatnya terhadap CA di validation_context. Sertifikat backend harus memiliki SAN backend.internal agar cocok dengan match_subject_alt_names.
mTLS menggabungkan keduanya: klien (Envoy) juga harus menunjukkan sertifikatnya saat membuat koneksi. Di sisi Envoy sebagai upstream:
transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
common_tls_context:
tls_certificates:
- certificate_chain:
filename: /etc/envoy/certs/client.pem
private_key:
filename: /etc/envoy/certs/client-key.pem
validation_context:
trusted_ca:
filename: /etc/envoy/certs/ca.pemSedangkan di sisi listener yang menerima mTLS, tambahkan require_client_certificate: true di dalam DownstreamTlsContext. Kombinasi inilah yang membuat dua service hanya mau bicara jika identitas lawan terbukti dari CA yang sama.
Sertifikat statis di bootstrap punya kelemahan besar: rotasi membutuhkan restart Envoy. Di production, restart semua proxy untuk mengganti sertifikat adalah operasi yang mahal dan berisiko. Solusinya adalah SDS — Envoy mengambil sertifikat dari sumber dinamis.
Dengan SDS, tls_certificates diganti referensi ke secret yang dikelola sumber eksternal:
common_tls_context:
tls_certificate_sds_secret_configs:
- name: server_cert
sds_config:
path: /etc/envoy/sds.yamlKonfigurasi tls_certificate_sds_secret_configs memberi tahu Envoy untuk meminta secret bernama server_cert melalui sumber yang didefinisikan di sds.yaml. Saat control plane memperbarui secret, Envoy memuat sertifikat baru tanpa restart — mekanisme yang sama dipakai Istio untuk memutar sertifikat sidecar. Untuk memeriksa sertifikat aktif, buka local:9901/certs — endpoint tersebut menampilkan semua sertifikat yang sedang dimuat lengkap dengan tanggal kedaluwarsanya.
Episode 6 mengamankan transport Envoy dari semua sisi: termination untuk klien, origination untuk upstream, mTLS yang memverifikasi kedua arah, dan SDS yang mengotomatiskan rotasi sertifikat.
Inti yang harus dibawa pulang:
DownstreamTlsContext mengamankan koneksi dari klien; UpstreamTlsContext mengamankan ke backend.openssl s_client adalah tool andalan inspeksi handshake TLS.local:9901/certs memperlihatkan sertifikat aktif dan tanggal kedaluwarsanya.Di episode 7 selanjutnya kita akan membahas access logging dan basic observability — mengaktifkan access log, format log dan request metadata, health check liveness readiness untuk Envoy sendiri, serta cara Envoy mengekspos metrics ke Prometheus.