Belajar Kata Containers - Network Security & Policy

#Pendahuluan

Di episode 7 kita melihat bagaimana microVM memiliki jaringan sendiri. Episode 14 menanyakan pertanyaan keamanannya: siapa yang boleh berbicara dengan siapa? Isolasi microVM membatasi apa yang bisa dilihat tenant satu sama lain di level kernel — tapi aplikasi tetap bisa saling terhubung lewat jaringan. Memisahkan keduanya adalah kesalahan umum yang harus kalian hindari.

Network policy dan mTLS beroperasi di atas isolasi microVM: microVM memberi isolasi runtime, policy memberi kontrol komunikasi, dan mTLS memberi kerahasiaan data dalam transit. Ketiganya bekerja bersama untuk membentuk pertahanan berlapis.

#NetworkPolicy dengan CNI

#Dasar NetworkPolicy

NetworkPolicy adalah objek Kubernetes yang mengontrol komunikasi antar pod. Ia bekerja dengan selector label: pod mana yang boleh menerima/mengirim dari pod mana, pada port apa. Implementasinya disediakan CNI — karena itu pilihan CNI menentukan seberapa penuh NetworkPolicy didukung.

Contoh policy: hanya pod frontend yang boleh mengakses pod api, dan hanya lewat port 8080:

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

podSelector dengan app: api menentukan pod sasaran, dan blok ingress membatasi siapa yang boleh masuk. Policy ini bekerja sama untuk pod Kata dan pod runc — CNI tidak membedakan keduanya di level network.

#Mengapa Policy Tetap Diperlukan

Isolasi microVM tidak menerapkan policy otomatis. Pod Kata di node A masih bisa berbicara dengan pod Kata di node B jika CNI mengizinkan. Isolasi runtime ≠ isolasi jaringan. Ini poin yang sering disalahpahami: kalian memakai Kata untuk isolasi host, tapi tetap butuh policy untuk kontrol komunikasi.

Ingat dari episode 7: CNI berjalan normal untuk pod Kata. Karena itu NetworkPolicy standar berlaku seperti biasa — tanpa perubahan khusus. Ini keuntungan besar dari integrasi Kata dengan Kubernetes.

#Egress Filtering

Policy ingress membatasi masuk; egress membatasi keluar. Untuk workload untrusted (tema yang berulang di series ini), egress filtering sangat penting: meskipun sebuah microVM dikompromikan, traffic keluarannya dibatasi.

Contoh: pod sandbox hanya boleh mengakses registry tertentu dan CoreDNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sandbox-egress
spec:
  podSelector:
    matchLabels:
      app: sandbox
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
    - to:
        - ipBlock:
            cidr: 10.0.0.0/16
      ports:
        - protocol: TCP
          port: 443

Blok egress pertama mengizinkan DNS ke kube-system, yang kedua mengizinkan HTTPS ke CIDR tertentu. Semua traffic keluar lain di-block. Untuk sandbox yang mengeksekusi kode tak dikenal, egress filtering adalah kontrol paling bernilai — ia membatasi "jangkauan" sebuah kompromi.

#Identitas Pod

NetworkPolicy berbasis label sudah kuat, tapi label bisa dipalsukan dalam beberapa kasus. Solusi lebih kuat datang dari identitas workload: pendekatan yang menurunkan identitas dari label yang diverifikasi, bukan alamat IP. Berbagai CNI modern (termasuk yang berbasis eBPF) mendukung identitas seperti ini — policy ditulis terhadap identity, sehingga tetap valid meskipun IP pod berubah.

Bagi pod Kata, identitas bekerja seperti biasa: pod dianggap sebagai workload Kubernetes standar, dan CNI menetapkan identitas berdasarkan labelnya. Isolasi microVM tidak mengganggu mekanisme ini.

Konsekuensi menariknya: kombinasi identitas + microVM memberi dua lapis pertahanan. Identitas mencegah spoofing di level jaringan; microVM mencegah tenant menembus node. Ini pola yang dipakai deployment production untuk workload untrusted.

#Data-in-Transit: mTLS dengan Service Mesh

#Mengapa mTLS untuk MicroVM

Egress filtering membatasi ke mana traffic bisa pergi, tapi tidak mengamankan isi traffic di jaringan. Untuk workload yang memproses data sensitif, komunikasi antar pod harus dienkripsi dan diautentikasi. Di sinilah mTLS (mutual TLS) masuk — biasanya via service mesh seperti Istio atau Cilium Service Mesh.

mTLS berarti kedua pihak saling membuktikan identitas lewat sertifikat, dan semua traffic dienkripsi. Tidak seperti TLS biasa (yang hanya mengautentikasi server), mTLS mengautentikasi keduanya — cocok untuk komunikasi service-to-service.

#Service Mesh di Atas Kata

Service mesh bekerja di level workload — biasanya dengan sidecar proxy di samping container aplikasi. Pod Kata bisa memakai sidecar: container sidecar hidup di dalam microVM yang sama dengan container aplikasi (ingat episode 4: satu pod = satu microVM).

Alurnya tetap sama: aplikasi berbicara ke localhost sidecar, sidecar melakukan mTLS ke sidecar tujuan. Karena semua container dalam satu pod berbagi microVM, sidecar dan aplikasi berkomunikasi lewat network loopback guest — tidak ada overhead jaringan eksternal di antara keduanya.

Mengaktifkan mTLS via Istio untuk namespace tertentu:

kubectl label namespace kata-prod istio-injection=enabled
kubectl get pods -n kata-prod

kubectl label namespace kata-prod istio-injection=enabled memerintahkan Istio menyuntikkan sidecar ke pod baru di namespace tersebut. Pod Kata akan menerima sidecar seperti pod biasa — integrasi mulus.

#Verifikasi Traffic Terenkripsi

Dari dalam guest, kalian bisa memverifikasi bahwa traffic keluar dienkripsi dengan melihat proses sidecar:

kata-runtime list
sudo kata-runtime exec <sandbox-id> ps aux | grep -i envoy

kata-runtime exec <sandbox-id> ps aux | grep -i envoy menampilkan proses Envoy (proxy Istio) yang berjalan di dalam microVM — bukti bahwa mTLS dikelola dari dalam guest, dan traffic keluar microVM sudah terenkripsi.

#Penutup

Inti yang harus dibawa pulang:

• NetworkPolicy bekerja normal untuk pod Kata — isolasi runtime ≠ isolasi jaringan.
• Egress filtering membatasi jangkauan kompromi untuk workload untrusted.
• Identitas pod menambah lapisan anti-spoofing di atas isolasi microVM.
• mTLS service mesh mengenkripsi dan mengautentikasi traffic antar pod.
• Sidecar berjalan di dalam microVM yang sama dengan aplikasi.
• Pertahanan berlapis: microVM + policy + mTLS.

Di episode 15 selanjutnya kita akan membahas secure boot & image trust — verifikasi guest kernel dengan signature, image attestation, image signing, SBOM, dan policy admission dengan Kyverno/OPA untuk workload Kata. Supply chain adalah pintu masuk serangan yang paling sering dilupakan.