Belajar Calico - Egress Access Control (Egress Gateway & NAT)

#Pendahuluan

Setiap kali pod memanggil API eksternal, traffic itu meninggalkan klaster. Pertanyaannya: dengan IP sumber apa? Jawaban defaultnya adalah IP node — tidak konsisten dan sering membuat database eksternal menolak karena whitelist tidak cocok. Episode 10 menyelesaikan masalah ini dengan egress control Calico.

Dua mekanisme utama yang akan kita pelajari: egress gateway untuk memaksa traffic keluar lewat node tertentu dengan IP tetap, dan kontrol akses keluar berbasis policy agar pod hanya bisa menjangkau tujuan yang diizinkan.

#Mengapa Butuh Egress Control

#Masalah IP Sumber yang Tidak Stabil

Traffic egress pod melewati node tempat pod itu berjalan, lalu di-NAT keluar IP node. Karena pod bisa berpindah node, IP sumbernya berubah-ubah. Layanan eksternal yang memakai allowlist IP akan menolak akses sesekali, dan audit trail di sisi penerima menjadi tidak berguna.

#Solusi: IP Egress yang Ditetapkan

Calico menyediakan EgressGatewayPolicy: traffic dari workload terpilih dipaksa keluar lewat node tertentu (egress gateway) dan di-NAT dengan IP tetap. Dari sisi penerima, semua request tampak berasal dari satu IP yang stabil.

#EgressGatewayPolicy

#Struktur Dasar

EgressGatewayPolicy memilih workload sumber dengan selector, menentukan IP egress, dan membatasi tujuan yang boleh diakses:

apiVersion: projectcalico.org/v3
kind: EgressGatewayPolicy
metadata:
  name: database-egress
  namespace: payments
spec:
  selector: app == 'api'
  egressIPs:
    - 203.0.113.20
  namespaceSelector: project == 'payments'
  dst:
    - networks:
        - 198.51.100.0/24
      ports:
        - 5432

Interpretasinya: pod berlabel app: api di namespace dengan label project: payments boleh keluar ke jaringan 198.51.100.0/24 port 5432, dan traffic itu keluar dengan IP 203.0.113.20.

#Bagaimana Traffic Dialihkan

Saat policy ini diterapkan, Calico menambahkan rule di node sumber: paket yang cocok selector diarahkan ke node egress gateway (via IP-in-IP atau rute khusus), di sana di-NAT dengan IP egress, lalu diteruskan ke tujuan:

pod api -> policy cocok -> rute ke node gateway
        -> NAT ke 203.0.113.20 -> jaringan eksternal -> database

#Mengamankan Akses Database Eksternal

#Skema Whitelist

Database eksternal biasanya membatasi koneksi ke daftar IP. Dengan egress gateway, daftar itu hanya berisi IP egress kalian. Terapkan policy untuk port database:

apiVersion: projectcalico.org/v3
kind: EgressGatewayPolicy
metadata:
  name: db-prod
  namespace: payments
spec:
  selector: app == 'api'
  egressIPs:
    - 203.0.113.21
  dst:
    - networks:
        - 198.51.100.0/24
      ports:
        - 5432

Sisi yang sama penting: gabungkan dengan NetworkPolicy agar hanya pod tertentu yang bisa menggunakan egress ini. Policy akses keluar dan egress gateway bekerja berlapis — gateway menentukan IP keluar, policy menentukan siapa yang boleh keluar.

#Verifikasi dari Sisi Pod

Untuk membuktikan traffic keluar dari IP egress, cek rute dan NAT di node:

kubectl get egressgatewaypolicies -n payments
calicoctl get workloadendpoints -n payments -o wide
kubectl exec -n payments deploy/api -- sh -c \
  "curl -s https://api.external.example.com/whoami | grep -E 'ip|address'"

Echo service semacam whoami akan menampilkan IP sumber. Jika menampilkan 203.0.113.21 atau yang sejenis, egress gateway bekerja dengan benar. Bandingkan dengan kubectl get egressgatewaypolicies -n payments yang memastikan policy terdaftar di klaster.

#Kombinasi dengan NetworkPolicy Egress

#Batasi Tujuan dengan Policy

Egress gateway mengatur IP keluar, tapi untuk mengendalikan siapa boleh keluar ke mana, tetap pakai NetworkPolicy. Contoh membatasi egress pod ke subnet database saja:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: api-egress-db
  namespace: payments
spec:
  selector: app == 'api'
  types:
    - Egress
  egress:
    - action: Allow
      protocol: TCP
      destination:
        nets:
          - 198.51.100.0/24
        ports:
          - 5432

Perhatikan destination.nets — ini menargetkan jaringan IP eksternal, bukan selector pod.

#Default Deny Egress

Jangan lupa menutup akses keluar lain. Pasang policy deny egress untuk workload, lalu buka hanya tujuan yang dibutuhkan (termasuk DNS). Pola lengkapnya:

calicoctl apply -f api-default-deny.yaml
calicoctl apply -f api-egress-db.yaml
calicoctl apply -f egress-gateway-db.yaml
calicoctl get networkpolicy -n payments

Urutannya sengaja: deny dulu, buka tujuan, baru tetapkan IP keluar. Dengan begitu tidak ada celah egress tak terkontrol.

#Penutup

Episode 10 menutup topik egress: IP sumber yang stabil dengan egress gateway, whitelist port di sisi penerima, dan pengendalian arah keluar dengan NetworkPolicy yang digabung menjadi pertahanan berlapis.

Inti yang harus dibawa pulang:

• Egress tanpa gateway membuat IP sumber berubah-ubah seiring perpindahan pod.
• EgressGatewayPolicy memaksa traffic keluar dengan IP egress tetap.
• egressIPs, selector, dan dst adalah tiga bahan utama EgressGatewayPolicy.
• Database eksternal cukup whitelist IP egress, bukan IP tiap node.
• Gabungkan dengan NetworkPolicy egress agar hanya workload terpilih yang keluar.
• Verifikasi dengan echo service yang menampilkan IP sumber.

Di episode 11 selanjutnya kita membahas DNS dan FQDN policy — kontrol egress berbasis domain untuk integrasi layanan eksternal, memadukan policy DNS dan IP dalam kebijakan aplikasi, serta jebakan yang sering muncul saat memakai domain.