Belajar Envoy Proxy - Production Hardening & Best Practices

#Pendahuluan

Series ini berakhir bukan dengan materi baru, melainkan dengan penyatuan: production hardening dan best practices. Episode 22 merangkum semua yang kalian pelajari menjadi dua checklist — keamanan dan operasional — ditambah cara menghadapi upgrade Envoy dan strategi fallback saat terjadi masalah.

Ini episode yang paling dekat dengan pekerjaan sehari-hari seorang engineer platform. Kalian tidak akan menemukan konfigurasi baru di sini; kalian akan menemukan urutan prioritas dan kebiasaan yang membedakan lab dari production.

#Security Hardening Checklist

#Daftar Periksa Keamanan

Berikut checklist keamanan yang wajib kalian tinjau sebelum Envoy melayani traffic production:

• TLS di semua jalur: termination di listener, origination ke upstream, sertifikat dari CA tepercaya.
• mTLS untuk komunikasi internal dengan verifikasi SAN atau SPIFFE.
• JWT atau ext_authz di edge untuk autentikasi.
• RBAC untuk otorisasi berbasis atribut.
• Rate limiting dengan failure_mode_deny untuk API publik.
• Admin interface tidak terekspos publik: admin Envoy seharusnya hanya bisa diakses jaringan internal.

#Mengamankan Admin Interface

Admin interface Envoy sangat kuat — dan sangat berbahaya jika terbuka ke publik:

curl -s -o /dev/null -w "%{http_code}\n" http://localhost:9901/server_info
curl -s localhost:9901/stats | grep "admin"

Jika server_info bisa diakses dari jaringan publik, kalian harus segera membatasi. Praktik yang disarankan:

• Jangan binding admin ke 0.0.0.0; gunakan 127.0.0.1 atau network internal.
• Jangan pernah mengekspos port 9901 lewat load balancer publik.
• Gunakan NetworkPolicy atau firewall untuk membatasi akses.
• Pertimbangkan memakai HTTPS untuk admin saat tersedia.

#Menutup Permukaan Lainnya

Tambahan yang sering terlupakan:

• Pastikan failure_mode_allow tidak menyala tanpa alasan pada filter keamanan.
• Nonaktifkan fitur yang tidak dipakai untuk mengurangi permukaan serangan.
• Jaga dependency dan image tetap diperbarui dengan patch keamanan.
• Pantau metric keamanan: RBAC reject, JWT failure, dan rate limit rejection.

#Operational Checklist dan Runbook

#Daftar Periksa Operasional

Checklist ini menangani sisi jalan yang sehat:

• Config dikelola Git dan divalidasi dengan envoy --mode validate di CI.
• Health check readiness dan liveness aktif di orkestrator.
• Access log berisi trace ID, request ID, dan response flags.
• Metrics di-scrape Prometheus dan ada dashboard untuk listener dan cluster.
• Tracing aktif dengan sampling yang masuk akal.
• Circuit breakers dan outlier detection dikonfigurasi di semua cluster.
• Backup dan restore bootstrap untuk disaster recovery.

#Menyusun Runbook

Runbook adalah langkah pemulihan yang sudah ditulis sebelumnya. Satu runbook yang wajib ada untuk Envoy: "Envoy tidak sehat". Isi minimalnya:

1. Buka local:9901/healthcheck/fail atau pastikan readiness gagal.
2. Periksa local:9901/server_info dan log startup.
3. Lihat metric kunci: upstream_cx_total, upstream_rq_5xx, listener_downstream_cx_active.
4. Jika config mencurigakan, kubectl rollout undo atau git revert.
5. Kembalikan traffic saat health check lulus kembali.

curl -s localhost:9901/server_info
curl -s localhost:9901/config_dump | head -30
curl -s localhost:9901/stats | grep -E "upstream_rq_5xx|downstream_cx_active"
docker logs envoy-prod 2>&1 | tail -50

Empat perintah runbook di atas mengumpulkan informasi diagnosis dalam satu sesi. Perintah inilah yang sering kali langsung mengungkap akar masalah sebelum langkah lain diambil.

#Drill Pemulihan

Runbook tidak berguna jika tidak pernah diuji. Lakukan drill berkala: matikan satu control plane, restart satu Envoy, atau aktifkan fault injection di staging. Latihan membuat tim yakin runbook benar-benar bekerja saat insiden nyata datang.

#Upgrade Envoy dan Strategi Fallback

#Merencanakan Upgrade

Upgrade Envoy perlu perencanaan karena beberapa fitur berubah antar versi:

1. Baca release notes dan daftar breaking changes.
2. Uji config di environment staging dengan versi baru.
3. Validasi semua fitur yang kalian pakai (terutama WASM dan filter custom).
4. Gulirkan upgrade bertahap ke production.
5. Pantau metric setelah setiap tahap.

envoy --version | grep "version"
docker images envoyproxy/envoy --format "{{.Tag}}"

Perintah envoy --version memastikan binary yang berjalan. Selalu catat versi config yang dipakai bersama versi Envoy — pasangan config-versi inilah yang penting untuk rollback.

#Fallback Strategy

Fallback berarti punya jalan keluar cepat saat upgrade atau perubahan menyebabkan masalah:

• Rollback config: kembalikan config sebelumnya via GitOps.
• Rollback image: pakai image Envoy versi sebelumnya.
• Lingkungan paruh waktu: pertahankan satu fleet versi lama sebagai cadangan.
• Drain dan shift: pindahkan traffic ke instance sehat dengan drain_listeners.

curl -s -X POST localhost:9901/drain_listeners
curl -s -X POST localhost:9901/healthcheck/fail

Perintah drain_listeners dan healthcheck/fail adalah pintu keluar yang aman: Envoy berhenti menerima koneksi baru sambil menyelesaikan request yang berjalan, lalu pod bisa dihentikan tanpa memutus traffic.

#Menyusun Matriks Kompatibilitas

Buat tabel kompatibilitas config terhadap versi Envoy: fitur apa yang dipakai, di versi berapa fitur tersebut stabil, dan config mana yang perlu berubah saat upgrade. Matriks ini mengubah upgrade dari peristiwa menegangkan menjadi langkah terjadwal.

#Refleksi Seluruh Series

#Apa yang Sudah Kalian Kuasai

Menutup episode 22, mari rangkum perjalanan 23 episode ini:

• Dari prasyarat jaringan di episode 0 sampai konfigurasi production di episode 22.
• Listener, cluster, route, dan filter chain sebagai fondasi arsitektur.
• xDS dan control plane untuk dynamic configuration.
• TLS, mTLS, JWT, RBAC, dan ext_authz untuk keamanan.
• Canary, mirroring, fault injection untuk traffic shaping.
• Prometheus, tracing, access log, dan SLO untuk observability.
• GitOps, CI/CD, dan runbook untuk operasional.

Setiap konsep yang muncul di production Envoy — di Istio, Gloo, atau deployment langsung — kini punya makna bagi kalian karena kalian pernah membangunnya dari dasar.

#Penutup

Episode 22 menutup series dengan disiplin production: checklist keamanan dan operasional, runbook yang teruji, serta strategi upgrade dan fallback yang membuat perubahan tidak menakutkan.

Inti yang harus dibawa pulang:

• Hardening dimulai dari TLS, mTLS, autentikasi, RBAC, dan rate limiting.
• Admin interface harus dibatasi jaringan internal, bukan terbuka publik.
• Config dikelola Git, divalidasi CI, dan digulirkan bertahap.
• Runbook harus ditulis, diuji, dan dipakai saat insiden.
• Upgrade Envoy direncanakan dengan release notes, staging, dan metric.
• Selalu punya fallback: rollback config, rollback image, dan drain listener.

Sampai jumpa di series berikutnya! Kalian kini bisa membaca config Envoy di service mesh mana pun dengan percaya diri. Jika kalian ingin lanjut belajar, rekomendasi saya adalah mendalami Istio sebagai penerapan paling matang dari Envoy sebagai data plane, atau membangun control plane xDS sendiri dengan go-control-plane untuk memahami protokol dari dalam. Selamat berkarya dengan Envoy!