Belajar Envoy Proxy - TLS & mTLS
Episode 6 of 23

Belajar Envoy Proxy - TLS & mTLS

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.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

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.

Membuat Sertifikat Uji Lokal

Sertifikat Self-Signed untuk Lab

Sebelum konfigurasi, buat sertifikat uji dengan openssl:

Generate CA dan sertifikat lab
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 365

Perintah 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.

TLS Termination di Listener

Mengonfigurasi Transport Socket

Untuk menerima HTTPS di Envoy, tambahkan transport socket TLS pada listener:

Listener dengan TLS termination
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.Router

Bagian 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.

TLS Origination ke Upstream

Envoy sebagai TLS Client

Arah sebaliknya: Envoy mengenkripsi koneksi ke backend. Konfigurasi ini berada di transport socket cluster:

Cluster dengan TLS origination
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: 8443

UpstreamTlsContext 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.

Mutual TLS (mTLS)

Dua Sisi Saling Memverifikasi

mTLS menggabungkan keduanya: klien (Envoy) juga harus menunjukkan sertifikatnya saat membuat koneksi. Di sisi Envoy sebagai upstream:

UpstreamTlsContext dengan client cert
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.pem

Sedangkan 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.

Certificate Rotation dan SDS

Masalah Sertifikat Statis

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.

Menghubungkan SDS ke Sumber Sertifikat

Dengan SDS, tls_certificates diganti referensi ke secret yang dikelola sumber eksternal:

Sertifikat dinamis via SDS
common_tls_context:
  tls_certificate_sds_secret_configs:
    - name: server_cert
      sds_config:
        path: /etc/envoy/sds.yaml

Konfigurasi 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.

Penutup

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.
  • TLS termination butuh sertifikat server; TLS origination butuh trusted CA.
  • mTLS menggabungkan client cert dan verifikasi CA di kedua sisi.
  • openssl s_client adalah tool andalan inspeksi handshake TLS.
  • Sertifikat statis butuh restart untuk rotasi; SDS menggantinya secara dinamis.
  • 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.

Belajar Envoy Proxy - TLS & mTLS | Belajar Envoy Proxy