Belajar Calico - Zero Trust Security (Default Deny & Microsegmentation)

#Pendahuluan

Zero trust adalah prinsip sederhana dengan implementasi yang menuntut kedisiplinan: jangan percaya apa pun secara default, verifikasi setiap koneksi. Dalam konteks jaringan Kubernetes, artinya tidak ada workload yang bisa bicara ke workload lain kecuali diizinkan secara eksplisit.

Di episode 13 kita menerjemahkan prinsip itu menjadi praktik Calico: default-deny di level namespace dan pod, microsegmentation dengan label, dan pemodelan workload endpoint sebagai unit keamanan. Kalian akan keluar dari episode ini dengan pola yang bisa langsung dipakai sebagai baseline klaster.

#Prinsip Zero Trust di Jaringan

#Menempatkan Batas Kepercayaan

Di klaster tanpa policy, setiap pod bisa menjangkau pod lain — tidak ada batas. Zero trust menempatkan batas di beberapa titik: namespace (batas antar tim), label (batas antar aplikasi), dan port (batas antar fungsi). Tiga lapis itu bisa diaktifkan bersama dengan Calico.

#Default Deny sebagai Landasan

Langkah pertama zero trust adalah memastikan tanpa policy eksplisit, tidak ada traffic. Di episode 6 kita membuat deny global dengan GlobalNetworkPolicy. Di episode ini kita menerapkannya lebih granular: default-deny per namespace.

#Default Deny per Namespace

#Policy Per Namespace

Untuk menutup sebuah namespace sekaligus:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  selector: all()
  types:
    - Ingress
    - Egress
  ingress: []
  egress: []

Policy ini mencocokkan semua pod di namespace payments, lalu tanpa rule apa pun — hasilnya, semua traffic masuk dan keluar ditolak. Tim yang ingin membuka akses menambah policy Allow di tier yang sesuai.

#Alur Aktivasi Bertahap

Menerapkan default deny langsung ke seluruh klaster itu menakutkan. Aktivasi bertahap yang disarankan:

kubectl label ns payments policy.open=true
calicoctl apply -f - <<EOF
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  selector: all()
  types:
    - Ingress
    - Egress
  ingress: []
  egress: []
EOF
calicoctl get networkpolicy -n payments

Mula-mula per-batch namespace, amati alarm, lalu baru skala ke seluruh klaster.

#Microsegmentation dengan Label

#Membagi Workload dengan Label

Microsegmentation artinya memecah jaringan menjadi segmen kecil berbasis label. Contoh model keamanan untuk aplikasi pembayaran:

• tier: web hanya bisa menerima dari ingress controller.
• tier: api hanya menerima dari tier: web dan keluar ke tier: db.
• tier: db hanya menerima dari tier: api pada port database.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: api-allow-web
  namespace: payments
spec:
  selector: tier == 'api'
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      source:
        selector: tier == 'web'
      destination:
        ports:
          - 8080

Policy ini hanya mengizinkan tier: web menghubungi tier: api di port 8080. Traffic lain ditolak oleh default deny namespace.

#Workload Endpoint sebagai Unit Keamanan

Semua ini bekerja karena setiap pod direpresentasikan sebagai workload endpoint dengan label dari pod-nya. Saat pod diberi label baru, policy yang memakai label itu otomatis berlaku — tanpa restart dan tanpa edit manual:

calicoctl get workloadendpoints -n payments -o wide
kubectl label pod api-pod-xyz tier=api
calicoctl get workloadendpoints -n payments -o wide | grep api-pod

calicoctl get workloadendpoints -o wide menampilkan endpoint berikut label dan node-nya. Perubahan label langsung tercermin di endpoint.

#Memodelkan Alur Koneksi yang Sah

#Inventori Alur Terlebih Dahulu

Sebelum menulis policy, petakan alur koneksi yang sah. Untuk setiap pasangan workload, tulis: sumber, tujuan, port, dan protocol. Dari inventori ini, tiap baris menjadi satu rule Allow. Policy yang dihasilkan ringkas dan bisa diaudit:

ingress-nginx  -> tier:web    (TCP 80, 443)
tier:web       -> tier:api    (TCP 8080)
tier:api       -> tier:db     (TCP 5432)
tier:api       -> kube-dns    (UDP 53)
tier:api       -> api.external.example.com (TCP 443)

#Menulis Policy yang Sesuai Inventori

Dari inventori di atas, setiap baris menjadi NetworkPolicy atau rule dalam policy yang lebih besar. Jangan lupa baris DNS — tanpa itu egress ke domain (episode 11) dan resolve biasa akan gagal.

#Menguji Efektivitas Zero Trust

#Uji dari Luar Batas

Setelah policy diterapkan, uji dengan pod yang seharusnya ditolak:

kubectl run intruder --image=busybox -n payments --command -- sleep 3600
kubectl exec -n payments intruder -- wget -T 3 -q -O - http://api:8080
kubectl exec -n payments deploy/api -- wget -T 3 -q -O - http://db:5432

Kedua perintah harus timeout. Jika berhasil, ada policy Allow yang terlalu luas — audit rule dan persempit selectornya.

#Audit dengan Flow Log

Untuk melihat keputusan yang diambil dataplane selama pengujian:

kubectl logs -n calico-system ds/calico-node | grep -iE "deny|drop" | tail -20

#Penutup

Episode 13 mengubah prinsip zero trust menjadi kebijakan yang bisa dijalankan: default-deny per namespace dan pod, microsegmentation berbasis label, dan pemodelan workload endpoint sebagai unit keamanan.

Inti yang harus dibawa pulang:

• Zero trust = default deny di semua level, lalu buka hanya yang sah.
• Policy dengan ingress: [] dan egress: [] menutup namespace.
• Aktivasi bertahap per batch namespace mengurangi risiko.
• Microsegmentation memakai label seperti tier sebagai segmen.
• Workload endpoint merefleksikan label pod secara real-time.
• Inventori alur koneksi dulu, baru tulis policy.

Di episode 14 selanjutnya kita membahas host endpoint dan node security — melindungi node Kubernetes itu sendiri dengan HostEndpoint, mengunci port manajemen, dan menerapkan policy untuk traffic ke node dan antar node.