Belajar DevSecOps Engineer - Network Policies & Segmentation

#Pendahuluan

Setelah Fase 3 ditutup dengan shift-right, kita masuk Fase 4: jaringan. Episode 8 sudah memperkenalkan default-deny dasar; episode ini mendalamkannya menjadi strategi segmentasi utuh. Mengapa penting? Karena model ancaman modern mengasumsikan breach sudah terjadi — pertanyaannya bukan "bagaimana mencegah masuk", melainkan "seberapa jauh attacker bisa bergerak setelah masuk". Itulah konsep lateral movement, dan jaringan datar adalah teman terbaiknya.

Insiden nyata berulang kali menunjukkan pola yang sama: satu container dicompromise lewat RCE web app → karena semua pod saling bisa diakses → database, Redis tanpa auth, dan service internal lain ikut tewas dalam hitungan menit. Segmentasi memutus rantai ini.

#Prinsip Zero Trust Jaringan

Model lama: perimeter — aman di dalam, curiga di luar. Model modern (zero trust): tidak ada lokasi yang dipercaya; setiap koneksi diverifikasi. Untuk platform Kubernetes, prinsipnya diterjemahkan jadi tiga aturan:

1. Default-deny ingress dan egress di setiap namespace.
2. Allowlist eksplisit berdasarkan identitas workload (label/service account), bukan IP statis.
3. mTLS antar-service sehingga identitas + enkripsi tidak bergantung pada letak jaringan.

#Ingress Segmentation: Lebih Detail dari Default-Deny

Episode 8 membuat deny-all; sekarang kita bangun allowlist bertingkat. Contoh arsitektur three-tier:

Aturan segmentasinya ketat dan satu arah:

netpol-api.yaml — hanya frontend & hanya port tertentu

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-ingress
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              env: prod
          podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080
  policyTypes:
    - Ingress

Perhatikan baris yang disorot: kombinasi namespaceSelector + podSelector artinya traffic harus lolos dua syarat sekaligus (dari namespace env=prod DAN pod berlabel app=frontend). Kesalahan umum pemula menaruhnya sebagai dua item array terpisah — yang artinya atau, bukan dan, dan membuka celah besar.

Uji kebijakan kalian secara aktif (jangan asumsikan CNI menerapkannya):

kubectl run nettest --rm -it --image=nicolaka/netshoot -- \
  curl --max-time 3 api.prod.svc.cluster.local:8080
# harus TIMEOUT dari pod tanpa label frontend

#Egress Control: Sisi yang Sering Dilupakan

Ingress saja belum lengkap — attacker yang masuk akan mencoba keluar: download payload, exfiltrate data, beacon ke C2 server. Default-deny egress memaksa semua koneksi keluar dideklarasikan:

netpol-egress.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-egress
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Egress
  egress:
    - to:                      # DNS tetap wajib dibuka
        - namespaceSelector: {}
      ports:
        - protocol: UDP
          port: 53
    - to:                      # hanya boleh ke database internal
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432

Hasilnya: pod api tidak bisa membuka koneksi ke internet sama sekali — bahkan kalau RCE berhasil, payload tidak bisa didownload dan data tidak bisa dikirim keluar. Untuk kasus yang butuh akses external API, gunakan egress gateway atau proxy dengan FQDN allowlist (Cilium mendukung policy berbasis DNS name).

#Service Mesh: Identitas dan mTLS

NetworkPolicy bekerja di L3/L4 (IP/port). Dua kelemahannya:

1. Identitas = label pod — siapa pun yang bisa memodifikasi label di namespace bisa meniru identitas.
2. Traffic internal biasanya plaintext — sniffer di node bisa membaca semuanya.

Service mesh (Istio, Linkerd) menyelesaikan keduanya: sidecar/eBPF proxy menyuntikkan identitas kriptografis (SPIFFE/SVID) ke setiap workload, dan semua traffic antar-service otomatis mutual TLS.

Dengan Linkerd, cukup anotasi namespace; dengan Istio, konfigurasi peer authentication:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: prod
spec:
  mtls:
    mode: STRICT     # tolak semua traffic non-mTLS

STRICT artinya: hanya workload dengan sertifikat mesh yang bisa bicara — plaintext ditolak. Authorization layer mesh-nya juga lebih halus dari label:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: api-from-frontend
  namespace: prod
spec:
  selector:
    matchLabels:
      app: api
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["prod/frontend"]
      to:
        - operation:
            methods: ["GET", "POST"]

Ini L7 authorization: method-level, principal-level — sesuatu yang mustahil dilakukan NetworkPolicy murni.

#Memilih Tingkat Segmentasi

Saran pragmatis: mulai NetworkPolicy menyeluruh (dampak terbesar, biaya terkecil), lalu mesh untuk stack yang benar-benar butuh L7/multi-cluster. Jangan pasang Istio hanya untuk default-deny.

#Penutup

Inti yang harus dibawa pulang:

• Asumsi breach: segmentasi membatasi lateral movement, bukan sekadar mencegah masuk.
• Default-deny + allowlist eksplisit (namespace+pod selector digabung), uji dengan pod test sungguhan.
• Egress control sering terlupa padahal memutus exfiltration & C2; ingat selalu buka DNS.
• Mesh memberi identitas kriptografis + mTLS + L7 authz; adopsi bertahap sesuai kebutuhan.

Di episode 19 selanjutnya kita beralih ke identitas: Identity & Access for Pipelines — bagaimana pipeline dan workload membuktikan siapa mereka tanpa password statis: OIDC federation, SPIFFE/SPIRE in-cluster, dan desain service account least privilege sampai level permission boundary. Sampai jumpa!