Belajar Calico - Service Mesh & App Layer

#Pendahuluan

Semua policy yang kalian tulis sejauh ini bekerja di lapisan L3/L4: IP, port, dan protocol. Tapi bagaimana kalau kalian ingin mengizinkan GET /api/users tapi menolak DELETE /api/users? Untuk itu dibutuhkan pemahaman terhadap payload HTTP — inilah lapisan L7 (application layer).

Episode 12 membahas Application Layer Policy (ALP) Calico: bagaimana Envoy proxy menyediakan pengetahuan aplikasi, bagaimana policy menulis metode dan path HTTP, dan bagaimana Calico berdampingan dengan service mesh seperti Istio.

#Application Layer Policy

#Konsep Dasar

ALP menempatkan proxy Envoy pada jalur traffic yang diseleksi. Envoy melihat request HTTP, lalu memutuskan berdasarkan rule L7 yang ditentukan policy. Karena proxy harus melihat traffic, ALP membutuhkan lebih banyak sumber daya dibanding policy L3/L4 — jadi gunakan hanya untuk workload yang benar-benar butuh.

#Mengaktifkan Dukungan L7

ALP diaktifkan lewat resource Installation. Aktifkan dulu, lalu deploy Envoy yang dikelola Calico:

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  applicationLayer:
    enabled: true

Setelah diterapkan, Calico men-deploy Envoy DaemonSet dan mengelola konfigurasinya. Cek statusnya:

kubectl patch installation default --type merge \
  -p '{"spec":{"applicationLayer":{"enabled":true}}}'
kubectl get pods -l k8s-app=calico-envoy -A
kubectl get tigerastatus | grep -i app

kubectl get tigerastatus menampilkan status komponen ALP setelah Envoy siap.

#Menulis ApplicationLayerPolicy

#Policy Berbasis Metode HTTP

ApplicationLayerPolicy memilih workload dengan selector, lalu menulis aturan HTTP:

apiVersion: projectcalico.org/v3
kind: ApplicationLayerPolicy
metadata:
  name: api-read-only
  namespace: payments
spec:
  selector: app == 'api'
  http:
    methods:
      - GET
      - POST
    paths:
      - /api/*
  action: Allow

Policy ini mengizinkan hanya GET dan POST ke path /api/*. Request lain — termasuk DELETE — tidak cocok dengan policy Allow, dan jika ada default deny di lapisan atas, request itu ditolak.

#Kombinasi dengan Policy L3/L4

ALP tidak menggantikan policy jaringan; dia melapis di atasnya. Alur evaluasinya:

NetworkPolicy (L3/L4) -> ApplicationLayerPolicy (L7) -> forwarding
        IP/port cocok?          metode/path cocok?

Aturan praktisnya: L3/L4 menyaring tujuan dan port, L7 menyaring isi request. Keduanya harus lolos agar traffic diizinkan.

#Visibilitas L7

#L7 Flow Logs

Karena Envoy melihat payload, lognya memuat detail aplikasi: metode HTTP, path, status response, dan durasi. Ini modal berharga untuk audit dan debugging. Lihat log Envoy di node yang menangani workload:

kubectl logs -l k8s-app=calico-envoy -A | grep -E "GET|POST|DELETE"
kubectl get pods -l app == 'api' -o name

Grep "GET|POST|DELETE" menampilkan baris akses HTTP yang melewati proxy.

#Deteksi Aksi HTTP dalam Policy

Untuk kebijakan audit atau mitigasi cepat, buat rule yang mencatat aksi berbahaya:

apiVersion: projectcalico.org/v3
kind: ApplicationLayerPolicy
metadata:
  name: log-delete
  namespace: payments
spec:
  selector: app == 'api'
  http:
    methods:
      - DELETE
  action: Log

Aksi Log tidak mengubah keputusan allow/deny, tapi mencatat request yang cocok. Ini cara yang aman untuk observasi sebelum menegakkan kebijakan yang lebih ketat.

#Service Mesh dan Calico

#Calico di Dalam Service Mesh

Calico bisa berjalan di dalam sebuah service mesh seperti Istio. Saat Istio mengelola traffic antar pod dengan sidecar Envoy-nya, Calico tetap memegang policy jaringan L3/L4 di level dataplane. Keduanya saling melengkapi: Istio mengatur routing dan mTLS, Calico menegakkan boundary jaringan.

#Kapan Memakai yang Mana

• Butuh policy per metode/path HTTP dan workload tidak memakai service mesh? Pakai ALP.
• Sudah memakai Istio dengan sidecar? Biarkan Istio menangani L7, Calico fokus ke jaringan.
• Butuh keduanya? Kombinasi bisa, dengan biaya sumber daya yang dipertimbangkan.

#Verifikasi Keseluruhan

Untuk memastikan ALP diterapkan ke endpoint tertentu:

calicoctl get applicationlayerpolicy -n payments -o yaml
calicoctl get workloadendpoints -n payments -o wide
kubectl exec -n payments deploy/api -- \
  curl -s -o /dev/null -w "%{http_code}" -X DELETE http://api/api/users

Request DELETE yang ditolak akan mengembalikan kode selain 2xx, membuktikan policy L7 aktif.

#Penutup

Episode 12 mengangkat Calico ke lapisan aplikasi: Envoy sebagai mata L7, ApplicationLayerPolicy untuk mengatur metode dan path HTTP, dan pemahaman kapan Calico berdampingan dengan service mesh.

Inti yang harus dibawa pulang:

• ALP butuh Envoy proxy yang diaktifkan di resource Installation.
• Policy L7 menulis methods, paths, dan action.
• ALP melapis di atas policy L3/L4, bukan menggantikannya.
• L7 flow logs memuat metode, path, dan status untuk audit.
• Aksi Log berguna untuk observasi sebelum penegakan.
• Dengan Istio, biarkan sidecar menangani L7 dan Calico menegakkan jaringan.

Di episode 13 selanjutnya kita masuk fase keamanan: zero trust security — membangun default-deny per namespace dan per pod, microsegmentation berbasis label, serta pemodelan workload endpoint sebagai fondasi kepercayaan nol.