Belajar DevOps Engineer - Networking & Service Mesh

#Pendahuluan

Di episode 8 kalian men-deploy aplikasi dan mengeksposnya via Service dan Ingress. Tetapi di sistem nyata, satu request melewati banyak service — dan setiap hop itu butuh networking yang bisa diandalkan dan aman: bagaimana satu service menemukan service lain? Bagaimana traffic dienkripsi? Bagaimana satu service membuktikan identitasnya ke service lain?

Episode 19 menjawab pertanyaan-pertanyaan itu di tiga lapisan: DNS dan networking dalam cluster, TLS dengan cert-manager untuk komunikasi eksternal, dan service mesh — Istio/Linkerd — untuk keamanan dan reliabilitas antar-service dengan mutual TLS (mTLS). Ini adalah lapisan yang membuat arsitektur microservice berjalan aman pada skala besar.

#DNS dan Networking dalam Cluster

Setiap Service di Kubernetes otomatis mendapat DNS record internal. Ini yang memungkinkan service saling menemukan hanya dengan nama — tanpa tahu IP:

myapp.default.svc.cluster.local   # nama DNS penuh service myapp
http://myapp:8080                  # dipakai di dalam namespace default

Kubernetes juga mendukung NetworkPolicy — firewall yang menentukan service mana boleh berkomunikasi dengan siapa:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-api
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api
      ports:
        - protocol: TCP
          port: 3000

Default Kubernetes membolehkan semua traffic. NetworkPolicy default-deny + allowlist adalah praktik yang harus kalian pasang sejak awal — jaringan yang "terbuka semua" adalah undangan untuk pergerakan lateral setelah satu service ditembus.

#TLS dan Certificate dengan cert-manager

Lalu lintas menuju aplikasi harus dienkripsi dengan TLS. Di Kubernetes, alur yang benar untuk mengelola certificate adalah cert-manager — controller yang meminta certificate dari Let's Encrypt (melalui ACME) dan memperbaruinya otomatis sebelum kedaluwarsa.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: app-tls
  namespace: default
spec:
  secretName: app-tls-secret
  dnsNames:
    - app.example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

Setelah certificate dibuat, Ingress memakainya — dan seluruh traffic ke app.example.com terenkripsi:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls-secret
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app
                port:
                  number: 80

#mTLS: Kedua Sisi Saling Memverifikasi

TLS biasa mengamankan koneksi browser → server: server membuktikan identitasnya, browser memverifikasi. Tapi ketika service berbicara ke service, kalian tidak tahu siapa di ujung sana — seorang attacker yang sudah masuk ke satu Pod bisa berpura-pura menjadi service lain. Mutual TLS (mTLS) menjawabnya: kedua pihak memverifikasi identitas satu sama lain dengan certificate sendiri.

mTLS diimplementasikan paling praktis lewat service mesh, karena mesh otomatis menyuntikkan identity per-Pod dan mengatur certificate — tanpa mengubah kode aplikasi.

#Service Mesh: Istio dan Linkerd

Service mesh menambahkan lapisan proxy (sidecar) di samping setiap Pod. Semua traffic masuk-keluar Pod lewat proxy, sehingga mesh bisa mengatur traffic, keamanan, dan observability secara terpusat:

Keduanya memberi empat kemampuan inti: mTLS otomatis, traffic shifting (canary dari episode 6), retry/timeout, dan metrics per-service tanpa instrumentasi manual.

#Praktik: Mengamankan Service-to-Service

Dengan Istio, kebijakan mTLS bisa dinyatakan secara deklaratif. Sebuah PeerAuthentication memaksa semua traffic antar-service di namespace terenkripsi:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT

Dan AuthorizationPolicy membatasi service mana yang boleh memanggil service lain:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: billing-allow-api
  namespace: default
spec:
  selector:
    matchLabels:
      app: billing
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/default/sa/api
      to:
        - operation:
            methods: ["GET", "POST"]

istioctl x describe pod billing-<id>
kubectl exec -n default deploy/billing -- curl -v http://api:8080/health 2>&1 | grep "SSL"

#Pitfall Umum

• NetworkPolicy tanpa default-deny — allowlist tidak berguna jika default-nya allow semua.
• Certificate manual — certificate yang tidak pernah dirotasi otomatis adalah downtime yang menunggu. Letakkan cert-manager sejak awal.
• mTLS dimatikan "sementara" — mode PERMISSIVE seharusnya hanya fase transisi menuju STRICT.
• Mesh di seluruh cluster sekaligus — adopsi bertahap per-namespace, ukur overhead, lalu perluas.
• Mengabaikan observability mesh — mesh menghasilkan metrics mTLS yang berguna; sambungkan ke Prometheus (episode 11), jangan dibiarkan menganggur.

#Penutup

Inti yang harus dibawa pulang:

• DNS internal membuat service saling menemukan; NetworkPolicy default-deny membatasi pergerakan lateral.
• cert-manager mengotomasi siklus hidup certificate TLS; Ingress memakainya untuk lalu lintas eksternal.
• mTLS membuat kedua sisi saling memverifikasi — identitas terenkripsi antar-service.
• Service mesh (Istio/Linkerd) menyediakan mTLS, traffic shifting, dan metrics tanpa mengubah kode aplikasi.

Di episode 20 selanjutnya kita membahas Disaster Recovery & Backup — RPO/RTO, backup dengan Velero dan Restic, dan rencana pemulihan yang diuji dengan simulasi nyata. Semua arsitektur yang kalian bangun di episode 8-19 tidak bernilai jika tidak bisa dipulihkan setelah bencana.