Belajar Istio - Production Hardening & Best Practices

#Pendahuluan

Dua puluh satu episode membekali kalian semua bagian Istio — dari instalasi, traffic management, observability, sampai recovery. Episode terakhir ini mengubah pengetahuan itu menjadi tindakan: checklist yang bisa kalian gunakan langsung untuk memeriksa mesh produksi, standar yang harus dipegang tim, dan praktik yang memisahkan mesh yang sehat dari mesh yang rapuh.

#Checklist Keamanan

#mTLS dalam Mode STRICT

Keamanan mesh dimulai dari memastikan semua traffic terenkripsi dan terautentikasi:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: mesh-wide
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

mtls.mode: STRICT di istio-system berlaku ke seluruh mesh. Jangan menurunkan mode ke PERMISSIVE tanpa alasan dan tanpa jadwal kembali ke STRICT.

#AuthorizationPolicy Least-privilege

Kunci kedua: semua yang tidak diizinkan harus ditolak. Terapkan policy allow yang presisi untuk setiap service penting:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all-default
  namespace: default
spec: {}

AuthorizationPolicy kosong dengan spec: {} menolak semua request ke namespace default. Kemudian beri izin eksplisit per service — persis pola yang kita bangun di episode 11. Service yang tidak punya policy eksplisit otomatis tertutup.

#Rotasi Secret dan CA

Sertifikat workload diperbarui otomatis oleh SDS sebelum kedaluwarsa. Yang perlu diperhatikan:

• Pantau masa berlaku sertifikat di metrik istiod.
• Rencanakan rotasi root CA dan trust domain jauh sebelum masa transisi.
• Backup private key root CA di tempat aman yang terpisah.

#Checklist Operasional

#Resource Quotas dan Batasan

Mesh yang tidak dibatasi bisa menghabiskan cluster. Pasang ResourceQuota per namespace dan batasi resource sidecar:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mesh-quota
  namespace: default
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi

ResourceQuota menjaga satu tenant tidak menelan seluruh cluster. Verifikasi pemakaian sidecar dengan kubectl top secara berkala dan sesuaikan sizing (episode 14).

#Monitoring, Alerting, dan Runbook

Mesh produksi harus terlihat setiap saat:

• Pantau metrik inti: error rate, p99 latency, konvergensi istiod, dan health sidecar.
• Alert dari error budget (episode 20), bukan dari setiap fluktuasi.
• Setiap alert yang bisa meng-halaman harus punya runbook: gejala, diagnosis, langkah perbaikan, dan waktu eskalasi.
• Jalankan incident drill berkala (episode 19 dan 21) dan perbarui runbook dari temuan.

monitor -> alert -> runbook -> drill -> perbaikan

#Standar Dokumentasi

#Service Owner dan Pola yang Diizinkan

Mesh yang besar hanya bisa dikelola banyak tim jika ada standar. Dokumentasikan:

• Pola yang diizinkan: kapan memakai VirtualService, kapan AuthorizationPolicy, dan kapan — dengan hati-hati — EnvoyFilter.
• Kepemilikan: setiap service punya owner yang bertanggung jawab atas kebijakannya.
• Support matrix: versi Istio yang didukung, versi Kubernetes yang kompatibel, dan jadwal upgrade.
• Templat: contoh YAML yang disetujui untuk routing, security, dan observability.

Standar ini disimpan sebagai bagian dari repo GitOps (episode 18) sehingga hidup bersama konfigurasi, bukan di wiki yang usang.

#Review Berkala

Lakukan audit mesh secara periodik:

istioctl analyze --all-namespaces
istioctl proxy-status
kubectl get authorizationpolicy -A -o wide

istioctl analyze --all-namespaces dan proxy-status menjadi pembuka setiap audit. Bandingkan hasilnya dengan standar dokumentasi, perbaiki drift, dan catat temuan untuk review berikutnya.

#Penutup

Episode 22 menutup series dengan tindakan: hardening keamanan dengan mTLS STRICT dan AuthorizationPolicy least-privilege, checklist operasional dengan resource quota, monitoring, alerting, dan runbook, serta standar dokumentasi yang menjaga mesh tetap terkelola saat banyak tim terlibat.

Inti yang harus dibawa pulang:

• mTLS STRICT dan default-deny adalah fondasi keamanan mesh.
• Semua yang tidak diizinkan eksplisit harus ditolak.
• Sertifikat diperbarui otomatis, tetapi rotasi CA perlu direncanakan.
• ResourceQuota dan sizing sidecar menjaga resource tetap sehat.
• Alert berbasis error budget; setiap alert punya runbook.
• Incident drill berkala mengubah dokumen DR menjadi kemampuan nyata.
• Dokumentasikan pola yang diizinkan, kepemilikan, dan support matrix.

Selamat, kalian sudah menyelesaikan seluruh 23 episode Belajar Istio! Dari pre-requisites, arsitektur, instalasi, traffic management, security, observability, hingga hardening produksi — kalian kini punya peta lengkap untuk mengoperasikan service mesh. Langkah selanjutnya: praktikkan di cluster pribadi, baca release notes Istio untuk setiap versi baru, ikuti dokumentasi resmi Istio dan Envoy, dan terus perbarui pengetahuan kalian seiring fitur seperti ambient mesh yang semakin matang. Service mesh adalah fondasi platform — sekarang giliran kalian membangunnya.