Pemeriksaan keamanan Kubernetes: akses, workload, dan jaringan

Mulai dari izin dan alur yang memang diperlukan

Pemeriksaan Kubernetes perlu membuktikan bahwa pekerjaan yang sah tetap berjalan, sementara akses yang tidak diperlukan ditolak. Kubernetes mengatur aplikasi dalam pod, yaitu unit yang berisi satu atau beberapa container. Pemeriksaan image tetap diperlukan, tetapi belum mencakup izin pengelolaan cluster dan hubungan antar-pod.

Catat versi server/client, node, plugin jaringan, namespace, image serta identitas penguji. Namespace memisahkan kelompok objek; jangan menganggap namanya saja sebagai batas keamanan lengkap. Sepakati siapa boleh membaca, membuat, mengubah atau menjalankan perintah pada workload, dan jalur jaringan apa yang diperlukan.

Lingkungan contoh yang dijalankan

Unduh source dan hasil lab infrastruktur 1.0. Pada 1 Oktober 2026, contoh dijalankan memakai kind 0.33.0, Kubernetes server/client 1.36.4, Calico 3.32.2 dan BusyBox 1.37.0 dengan digest image. Host macOS arm64, Docker Engine 29.4.0; cluster memiliki satu node Linux.

API lab hanya mendengar di loopback, dengan kubeconfig terpisah. Namespace kompli-demo berisi tiga pod dan Secret berisi penanda buatan. Tidak menguji cluster atau data produksi. README menjelaskan pembuatan cluster, pemasangan plugin dan penghapusannya.

Jalankan runner setelah cluster khusus lab siap; jangan mengganti context dengan cluster kerja:

python3 kubernetes-checks.py --kubectl /path/to/kubectl --kubeconfig ./lab-kubeconfig --out kubernetes-results.json --confirm-disposable-cluster

Batasi izin pengelolaan dan akses Secret

Role-Based Access Control atau RBAC menentukan tindakan yang boleh dilakukan identitas. Mulai dari kebutuhan pekerjaan, lalu periksa Role/RoleBinding yang memberinya izin. Wildcard dapat memberi akses lebih luas saat jenis objek baru ditambahkan. Izin membuat pod juga dapat membuka akses tidak langsung ke Secret pada namespace tersebut; jangan hanya memeriksa izin get secrets.

Contoh mengubah Role milik service account reader dari izin wildcard menjadi get/list pods saja. Berikut pemeriksaan baca yang dipakai pada lab:

kubectl --kubeconfig ./lab-kubeconfig --context kind-kompli-infrastructure-lab -n kompli-demo auth can-i get secrets --as=system:serviceaccount:kompli-demo:reader

Hasil sebelum pembatasan yes. Sesudah pembatasan: get secrets no, create pods no, sementara get pods tetap yes. Permintaan API membaca Secret buatan juga ditolak dengan Forbidden. Ini bukti untuk identitas dan namespace tersebut; belum menilai semua binding, kelompok, impersonation atau jalur peningkatan hak.

Pada pod contoh, automountServiceAccountToken dimatikan karena aplikasi tidak memakai API Kubernetes. Pemeriksaan runtime tidak menemukan file token pada path otomatis. Hal ini tidak membuktikan tidak ada token lain yang diberikan melalui Secret, file atau integrasi berbeda.

Periksa admission dan keadaan proses

Admission adalah pemeriksaan API sebelum menerima objek. Label namespace lab memakai Restricted dengan versi v1.36. Konfigurasi pod privileged diterima pada server dry run sebelum pembatasan, lalu ditolak setelah label diterapkan. Pod privileged itu tidak benar-benar dijalankan.

Konfigurasi contoh yang sah tetap diterima: pengguna non-root, privilege escalation dimatikan, capabilities dihapus dan seccomp RuntimeDefault. Ketika server dijalankan, perintah id melaporkan uid=10001, dan layanan HTTP tetap berfungsi.

Simpan kedua jenis bukti: penolakan konfigurasi dan keadaan proses yang berjalan. Perubahan policy tidak otomatis memperbaiki seluruh workload lama. Rencanakan penerapan serta uji fungsi; jangan melabeli semua namespace produksi Restricted tanpa memeriksa ketergantungan dan jalur pemulihan.

Buktikan aturan jaringan bekerja

NetworkPolicy membutuhkan plugin yang mendukung enforcement. Aturan bersifat aditif: policy lain yang mengizinkan jalur dapat membuatnya tetap terbuka. Periksa semua policy yang memilih pod; ingress dan egress memiliki pembatasan tersendiri.

Lab memakai HTTP pada IP pod server, TCP 8080, agar pemeriksaan ini tidak bergantung pada DNS. Data sepenuhnya buatan; HTTP digunakan untuk menguji pembatasan koneksi, bukan pola transportasi produksi.

Keadaan	Hasil yang tercatat
Belum ada pembatasan ingress	Client A dan B membaca KUBERNETES_LAB_OK.
Policy deny memilih server	Keduanya mengalami timeout; exit code 1.
Ditambahkan izin untuk label client A	A membaca penanda; B tetap timeout.
Uji ulang dengan koneksi baru	A tetap berhasil dan B tetap ditolak.

Timeout saja tidak cukup membuktikan policy bekerja: server mati juga menimbulkannya. Kontrol positif A, hasil sebelum perubahan dan uji ulang membantu memperjelas penyebab pada lab ini. Buktikan juga egress serta ketergantungan DNS jika masuk lingkup lingkungan Anda.

Catat bagian yang belum diperiksa

Contoh ini memeriksa satu Role namespace, admission satu konfigurasi, tiga pod Linux dan satu jalur ingress. Belum memeriksa multi-node, Windows, egress, DNS, akses metadata cloud, audit log lengkap, backup, enkripsi etcd, supply chain seluruh image atau kepatuhan cluster. Kubernetes Secret yang menggunakan base64 belum berarti terenkripsi; pengamanan penyimpanan perlu diperiksa terpisah.

Gunakan catatan verifikasi untuk versi, kasus, hasil dan batas. Lengkapi dengan pemeriksaan image/container, Infrastructure as Code serta identitas workload. Rujukan teknis ini bukan kewajiban hukum Indonesia dengan sendirinya.

Rencana tambahan: egress, DNS dan beberapa workload

Bagian ini ditambahkan 2 Oktober 2026 berdasarkan dokumentasi NetworkPolicy. Belum dijalankan pada cluster; hasil ingress di atas tetap berasal dari lab 1 Oktober. Tidak ada simulator, VM atau cluster baru yang dijalankan pada batch ini.

Untuk lingkungan uji yang diizinkan, petakan frontend, API, database dan resolver. Periksa dukungan enforcement plugin dan seluruh policy yang memilih masing-masing pod. Jika sumber diisolasi untuk egress dan tujuan diisolasi untuk ingress, koneksi perlu diizinkan pada kedua sisi. Namespace saja tidak menutup koneksi.

Contoh objek berikut hanya acuan yang belum diterapkan. Objek memilih seluruh pod pada namespace buatan dan tidak memberi pengecualian; bukan konfigurasi siap pakai. Jangan memasangnya di namespace kerja.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: lab-deny-egress
  namespace: kompli-demo
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress: []

Policy lain yang mengizinkan egress tetap dapat membuka jalur karena aturan aditif. Tambahkan izin yang telah ditinjau untuk resolver dan tujuan aplikasi pada lingkungan uji, lalu periksa kasus berikut. Tidak ada hasil aktual untuk tabel ini.

Kasus yang direncanakan	Bukti yang dicari
Frontend → API; API → database	Jalur sah bekerja, layanan tak terkait ditolak.
API → DNS yang dipilih	Resolusi berjalan pada UDP dan TCP yang diperlukan; periksa resolver lokal bila dipakai.
API → tujuan luar yang diizinkan/tidak diizinkan	Koneksi baru sesuai aturan; tujuan kontrol positif tetap hidup.
Client dengan label/namespace berbeda	Uji gabungan namespaceSelector dan podSelector; label dapat diubah oleh pihak berizin.
Workload pada beberapa node	Catat penempatan pod dan hasil lintas-node, bukan hanya satu node.
Policy tambahan membuka akses	Uji ulang izin efektif dari seluruh policy, bukan hanya berkas yang baru ditambahkan.

Core NetworkPolicy tidak memilih tujuan memakai FQDN dan tidak memeriksa izin akun aplikasi atau TLS. Perilaku NAT serta koneksi yang sudah terbentuk dapat bergantung implementasi. Catat versi plugin, sumber/tujuan dan batasnya di catatan verifikasi. Peta alur lintas-platform tetap di segmentasi jaringan layanan.