Kubernetes NetworkPolicy: Membatasi Akses Antar-Pod dengan Aman

Dalam cluster Kubernetes, Pod sering dapat berkomunikasi satu sama lain melalui jaringan internal. Kemudahan ini membantu aplikasi berjalan, tetapi juga berarti satu layanan yang berhasil disusupi berpotensi mencoba menjangkau layanan lain. NetworkPolicy memberi cara untuk membatasi komunikasi jaringan pada tingkat Pod sehingga akses hanya dibuka sesuai kebutuhan aplikasi.

Panduan ini membahas konsep dasar, contoh konfigurasi, serta langkah penerapan bertahap. NetworkPolicy bukan pengganti autentikasi atau enkripsi, tetapi merupakan salah satu lapisan penting untuk mengurangi pergerakan lateral di dalam cluster.

Apa Itu Kubernetes NetworkPolicy?

NetworkPolicy adalah objek API Kubernetes yang menentukan trafik jaringan mana yang diizinkan menuju Pod (ingress) atau keluar dari Pod (egress). Aturannya menggunakan label untuk memilih Pod dan, bila diperlukan, namespace sumber atau tujuan, protokol, serta port. Dengan begitu, kebijakan dapat mengikuti peran aplikasi, bukan bergantung pada alamat IP Pod yang dapat berubah.

Contohnya, layanan frontend mungkin hanya perlu mengakses API pada port TCP 8080. API tidak semestinya menerima koneksi dari setiap Pod di cluster, sedangkan basis data hanya perlu menerima koneksi dari API pada port tertentu. NetworkPolicy membantu menyatakan batas komunikasi seperti itu secara eksplisit.

Perlu diperhatikan: dukungan NetworkPolicy harus disediakan oleh plugin jaringan atau CNI yang digunakan cluster. Membuat objek kebijakan saja tidak menjamin trafik benar-benar difilter jika implementasi jaringan tidak menegakkannya. Rujuk dokumentasi resmi Kubernetes tentang NetworkPolicy dan dokumentasi CNI yang dipasang.

Memahami Ingress, Egress, dan Selector

• Ingress mengatur koneksi yang masuk ke Pod yang dipilih kebijakan.
• Egress mengatur koneksi yang dimulai dari Pod menuju tujuan lain.
• podSelector menentukan Pod yang dikenai kebijakan melalui label.
• namespaceSelector memilih namespace berdasarkan label, berguna untuk membatasi komunikasi lintas namespace.

Aturan NetworkPolicy bersifat aditif: trafik yang cocok dengan salah satu aturan izin dari kebijakan yang berlaku dapat diizinkan. Kebijakan bukan daftar aturan firewall berurutan yang aturan terakhirnya mengalahkan aturan sebelumnya. Karena itu, periksa semua kebijakan yang memilih Pod yang sama sebelum menyimpulkan mengapa suatu koneksi berhasil atau gagal.

Contoh: Hanya Izinkan Frontend Mengakses API

Misalkan Pod API memiliki label app: api, sementara Pod frontend memiliki label app: frontend. Contoh berikut hanya mengizinkan trafik ingress TCP port 8080 dari Pod frontend yang berada di namespace yang sama.

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

Simpan konfigurasi sebagai allow-frontend-to-api.yaml, lalu terapkan ke cluster pengujian:

kubectl apply -f allow-frontend-to-api.yaml
kubectl describe networkpolicy allow-frontend-to-api -n app
kubectl get pods -n app --show-labels

Pastikan label pada Pod benar-benar sesuai. Selector yang tidak cocok dapat membuat akses yang diharapkan tetap tertutup, atau membuat kebijakan tidak mengenai Pod yang dimaksud. Contoh ini hanya membatasi ingress; kebijakan egress terpisah mungkin diperlukan untuk mengendalikan koneksi keluar dari Pod API.

Menggunakan Default-Deny dengan Hati-Hati

Untuk namespace yang membutuhkan isolasi lebih ketat, tim dapat memulai dengan menolak semua ingress dan egress, lalu menambahkan izin yang diperlukan. Contoh berikut memilih seluruh Pod di namespace app:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Kebijakan tersebut tidak memuat aturan izin, sehingga trafik ingress dan egress yang dicakupnya tidak diizinkan. Terapkan dengan hati-hati: egress ke DNS, layanan eksternal, endpoint metadata, atau layanan observabilitas dapat ikut terputus. Jika aplikasi perlu resolusi nama, tambahkan aturan DNS yang sesuai dengan arsitektur cluster dan port layanan DNS yang benar.

Langkah Penerapan yang Lebih Aman

1. Petakan alur aplikasi. Catat Pod mana yang perlu berbicara dengan API, basis data, DNS, dan layanan eksternal. Jangan membuka semua trafik hanya untuk mengatasi koneksi yang gagal.
2. Gunakan label yang konsisten. Pilih label berdasarkan fungsi, misalnya app: frontend dan app: api, lalu pastikan label tersebut dikelola melalui manifest atau pipeline yang tepercaya.
3. Uji di namespace nonproduksi. Terapkan kebijakan bertahap, jalankan tes konektivitas dari Pod yang diizinkan dan yang seharusnya ditolak, serta pantau log aplikasi.
4. Periksa semua kebijakan yang berlaku. Karena izin dapat digabungkan dari beberapa NetworkPolicy, audit kebijakan yang memilih Pod sama dan hapus izin berlebih melalui proses perubahan yang terkontrol.
5. Dokumentasikan pengecualian. Setiap port atau tujuan yang dibuka sebaiknya memiliki alasan, pemilik layanan, dan rencana peninjauan berkala.

NetworkPolicy berfokus pada kontrol jaringan, bukan identitas pengguna atau enkripsi payload. Tetap gunakan autentikasi layanan, TLS bila sesuai, pembatasan hak akses Kubernetes, dan pengelolaan rahasia yang benar. Untuk memahami lingkungan container secara lebih luas, baca juga panduan Nazuaf tentang perbedaan Docker container dan virtual machine.

Kesimpulan

Kubernetes NetworkPolicy membantu mengurangi komunikasi yang tidak diperlukan antar-Pod dengan aturan ingress dan egress berbasis selector. Mulailah dari alur komunikasi yang benar-benar dibutuhkan, verifikasi dukungan CNI, dan uji setiap perubahan sebelum diterapkan ke produksi. Kebijakan yang sempit, terdokumentasi, dan diuji secara berkala lebih berguna daripada aturan luas yang sekadar membuat koneksi kembali berfungsi.