Belajar Istio - Security Basics (mTLS, Authentication & Authorization)

#Pendahuluan

Traffic sudah bisa diatur dan diamati. Sekarang saatnya mengamankannya. Episode 11 ini membahas pilar security Istio: mTLS untuk enkripsi dan autentikasi antar service, JWT validation untuk membuktikan siapa pemanggil, dan AuthorizationPolicy untuk memutuskan apa yang boleh dilakukan.

Kunci filosofinya: keamanan mesh berbasis identitas workload, bukan sekadar alamat IP. Karena identitas dijamin oleh istiod dan disematkan ke dalam sertifikat, kebijakan bisa berpindah mengikuti workload ke mana pun dia berjalan.

#mTLS Otomatis dengan PeerAuthentication

#Mode mTLS

Mutual TLS membuat dua sisi saling memverifikasi sertifikat. Istio mengotomatiskan ini lewat PeerAuthentication:

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

Tiga mode yang tersedia:

• PERMISSIVE (default): menerima plaintext dan mTLS — untuk migrasi bertahap.
• STRICT: semua traffic wajib mTLS; plaintext ditolak.
• DISABLE: tidak memakai mTLS sama sekali.

mtls.mode: STRICT menjamin tidak ada komunikasi plaintext di namespace tersebut. Gunakan STRICT saat seluruh workload di namespace sudah siap, dan PERMISSIVE selama masa migrasi.

#Linkage dengan DestinationRule

Sebagai bentuk legacy, mTLS juga bisa dipicu dari DestinationRule:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: default
  namespace: default
spec:
  host: "*.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

tls.mode: ISTIO_MUTUAL menyuruh client memakai sertifikat Istio saat menghubungi host yang cocok. Di versi modern, PeerAuthentication adalah cara yang disarankan; DestinationRule semacam ini hanya untuk kompatibilitas atau kasus spesifik.

#JWT dengan RequestAuthentication

RequestAuthentication memvalidasi token JWT pada request. Token yang valid mengikat identitas pengguna ke request:

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-gateway
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  jwtRules:
  - issuer: "https://accounts.example.com"
    jwksUri: "https://accounts.example.com/.well-known/jwks.json"
    forwardOriginalToken: true

issuer dan jwksUri memberi tahu Envoy dari mana mengambil kunci publik untuk memverifikasi tanda tangan JWT. Setelah ini aktif, token yang valid menambah claim ke request — misalnya request.auth.claims — yang bisa dipakai di AuthorizationPolicy. Perlu dicatat: RequestAuthentication hanya memvalidasi, dia tidak menolak request tanpa token. Penolakan dilakukan oleh AuthorizationPolicy.

#AuthorizationPolicy

#Aturan Allow Pertama

AuthorizationPolicy memutuskan apakah request diizinkan. Aturan default-nya: ketika ada policy yang cocok, semuanya ditolak kecuali diizinkan eksplisit:

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

Policy ini mengizinkan service account frontend memanggil metode GET productpage. Setelah diterapkan, semua request lain ke productpage — termasuk dari service lain — ditolak dengan 403. action bisa ALLOW, DENY, atau CUSTOM.

#Kondisi dengan when

Kontrol lebih halus lewat when:

spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
  - when:
    - key: request.auth.claims[role]
      values: ["admin"]
    to:
    - operation:
        methods: ["POST"]

when dengan request.auth.claims[role] hanya mengizinkan pengguna dengan claim role: admin. Ini adalah contoh penggunaan claim JWT yang divalidasi di RequestAuthentication.

#Verifikasi Kebijakan

Uji penolakan dan izin secara langsung:

curl -s -o /dev/null -w "%{http_code}" http://productpage:9080/productpage
curl -H "Authorization: Bearer $TOKEN" http://productpage:9080/productpage

Cek dengan dan tanpa token untuk memastikan respons 403 dan 200 muncul sesuai kebijakan.

#Sertifikat, SDS, dan External CA

Istio menerbitkan sertifikat workload secara otomatis. Sertifikat dikirim ke Envoy lewat SDS (Secret Discovery Service) dan diperbarui sebelum kedaluwarsa tanpa restart. Konfigurasi granular bisa diatur di MeshConfig:

spec:
  meshConfig:
    trustDomain: cluster.local
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"

trustDomain menentukan akar identitas — nilai ini harus konsisten di seluruh mesh. Untuk integrasi CA eksternal seperti cert-manager, tambahkan certificates di MeshConfig atau gunakan Certificate CRD Istio dengan type: ISTIOD.

#Penutup

Episode 11 mengunci komunikasi di dalam mesh: PeerAuthentication untuk mTLS otomatis, RequestAuthentication untuk validasi JWT, AuthorizationPolicy untuk kontrol akses berbasis identitas, serta manajemen sertifikat via SDS dengan opsi integrasi CA eksternal.

Inti yang harus dibawa pulang:

• mTLS mengautentikasi workload; STRICT menolak plaintext.
• PERMISSIVE untuk migrasi, STRICT untuk produksi.
• RequestAuthentication memvalidasi JWT; penolakan dilakukan AuthorizationPolicy.
• AuthorizationPolicy default-deny: hanya yang diizinkan yang lolos.
• when memungkinkan kontrol berbasis claim JWT dan kondisi lain.
• SDS memperbarui sertifikat tanpa restart sidecar.
• trustDomain harus konsisten di seluruh mesh.

Di episode 12 selanjutnya kita akan mengatur isolasi: multi-tenancy, namespace isolation, dan RBAC — memisahkan tenant dengan namespace, membatasi scope egress dengan Sidecar CRD, dan memahami hubungan antara RBAC Kubernetes dengan AuthorizationPolicy Istio.