Keamanan Kubernetes: RBAC, Kebijakan Jaringan, dan Keamanan Pod

Kubernetes mengatur beban kerja berbasis Container dalam skala besar, tetapi kompleksitasnya menciptakan permukaan serangan yang luas. Komponen utama yang harus diamankan mencakup: Server API (bidang kontrol pusat—jika disusupi, seluruh cluster dapat dikendalikan), etcd (basis data status cluster—menyimpan rahasia dalam base64 dan harus dienkripsi saat tidak digunakan), kubelet (agen node—API kubelet tanpa autentikasi memungkinkan eksekusi Pod secara sewenang-wenang), runtime Container (Docker/containerd), dan infrastruktur jaringan yang menghubungkan semua Pod. Peserta ujian Security+ perlu memahami bahwa kesalahan konfigurasi Kubernetes termasuk temuan keamanan cloud yang paling umum.

RBAC (Role-Based Access Control) Kubernetes mengatur pengguna, akun layanan, dan proses mana yang dapat melakukan tindakan tertentu pada sumber daya API tertentu. Model ini memiliki empat objek: Role (izin berdasarkan namespace), ClusterRole (izin untuk seluruh cluster), RoleBinding (memberikan Role kepada subjek dalam suatu namespace), dan ClusterRoleBinding (memberikan ClusterRole kepada subjek di seluruh cluster). Setiap perintah kubectl diterjemahkan menjadi panggilan API yang diperiksa berdasarkan aturan RBAC. Jika RBAC tidak dikonfigurasi, pengguna terautentikasi mana pun (atau akun layanan) dapat memiliki akses administratif.

Setiap Pod di Kubernetes berjalan menggunakan akun layanan—identitas yang digunakan untuk autentikasi API. Secara bawaan, Pod menggunakan akun layanan default di namespace-nya, yang mungkin memiliki izin luas. Prinsip hak istimewa minimum mengharuskan pembuatan akun layanan khusus untuk setiap aplikasi, dengan hanya izin yang dibutuhkannya. Selain itu, pengaturan automountServiceAccountToken: false pada Pod yang tidak memerlukan akses API mencegah token akun layanan dipasang ke sistem berkas Pod, tempat aplikasi yang telah disusupi dapat menggunakannya untuk melakukan panggilan API.

Secara bawaan di Kubernetes, semua Pod dapat berkomunikasi dengan semua Pod lain di namespace mana pun. Pod yang telah disusupi dapat segera mencoba menjangkau basis data, API internal, dan layanan mikro lainnya. Sumber daya NetworkPolicy Kubernetes menentukan aturan yang membatasi lalu lintas antar-Pod berdasarkan label, namespace, dan port. Pendekatan yang disarankan adalah kebijakan jaringan 'tolak semua secara bawaan' di setiap namespace, yang kemudian diikuti aturan izinkan secara eksplisit untuk jalur komunikasi yang diperlukan. Perhatikan bahwa NetworkPolicy memerlukan plugin CNI yang mendukungnya (Calico, Cilium, Weave)—Kubernetes vanilla mengabaikan NetworkPolicy tanpa CNI yang kompatibel.

Pod Security Standards (PSS), diperkenalkan di Kubernetes 1.23 dan stabil pada 1.25, menggantikan Pod Security Policy (PSP) yang sudah tidak digunakan dengan tiga profil bawaan yang diberlakukan pada tingkat namespace: Privileged (tanpa pembatasan, untuk komponen sistem), Baseline (mencegah eskalasi hak istimewa yang diketahui, seperti Container dengan hak istimewa dan akses jaringan host), serta Restricted (diperketat, mengharuskan pengguna non-root, menanggalkan semua kapabilitas, dan memberlakukan sistem berkas root hanya-baca). Namespace diberi Label untuk memberlakukan tingkat kebijakan, dan Pod yang melanggarnya ditolak saat penerimaan.

Secret Kubernetes menyimpan data sensitif seperti kata sandi, token, dan sertifikat TLS. Secara bawaan, Secret disimpan di etcd sebagai nilai yang dikodekan dengan base64—bukan dienkripsi. Siapa pun yang dapat membaca etcd atau memiliki izin RBAC yang memadai dapat mendekodenya dengan mudah. Praktik terbaik mencakup: mengaktifkan enkripsi saat tidak digunakan untuk etcd menggunakan AES-GCM dengan kunci yang disimpan dalam KMS (AWS KMS, GCP KMS), mengintegrasikan pengelola rahasia eksternal seperti HashiCorp Vault atau AWS Secrets Manager melalui Secrets Store CSI Driver, serta membatasi akses Secret melalui RBAC agar hanya akun layanan yang membutuhkannya yang dapat membacanya.

Pengendali penerimaan adalah plugin di server API Kubernetes yang mencegat permintaan API setelah autentikasi dan otorisasi, tetapi sebelum objek disimpan, sehingga dapat memvalidasi, mengubah, atau menolak permintaan. Pengendali penerimaan yang relevan dengan keamanan mencakup: PodSecurity (memberlakukan Pod Security Standards), ImagePolicyWebhook (memungkinkan verifikasi penandatanganan image eksternal), AlwaysPullImages (memaksa pengambilan image baru untuk mencegah penggunaan image berbahaya yang tersimpan secara lokal), dan OPA/Gatekeeper (Open Policy Agent—yang paling fleksibel, memungkinkan kebijakan khusus yang ditulis dalam bahasa Rego untuk memberlakukan aturan keamanan organisasi apa pun).

Penguatan komponen bidang kontrol Kubernetes sangat penting: server API harus menggunakan --anonymous-auth=false untuk menonaktifkan akses tanpa autentikasi, mengonfigurasi --audit-log-path untuk merekam semua aktivitas API, dan menggunakan TLS untuk semua koneksi. kubelet harus menggunakan --authorization-mode=Webhook (bukan AlwaysAllow) dan menonaktifkan autentikasi anonim. etcd harus menggunakan enkripsi TLS untuk rekan dan klien, akses jaringan yang dibatasi (hanya dapat dijangkau oleh server API), serta enkripsi data saat tidak digunakan. CIS Kubernetes Benchmark menyediakan daftar periksa komprehensif untuk semua pengaturan komponen.

Namespace Kubernetes menyediakan pemisahan logis sumber daya, tetapi bukan batas keamanan yang kuat jika berdiri sendiri—fungsi utamanya adalah menyediakan isolasi organisasi. Untuk isolasi multi-penyewa yang sebenarnya (misalnya, beban kerja milik pelanggan yang berbeda), diperlukan kontrol tambahan: kebijakan jaringan untuk memblokir lalu lintas lintas-namespace, kuota sumber daya untuk mencegah DoS akibat tetangga yang menghabiskan sumber daya, kumpulan node terpisah untuk penyewa yang memerlukan isolasi kuat, atau cluster khusus untuk setiap penyewa. Banyak organisasi menggunakan Hierarchical Namespaces atau solusi komersial seperti vCluster untuk multi-penyewaan yang lebih kuat dalam satu cluster.

Kubernetes pencatatan audit merekam setiap permintaan API: siapa yang membuatnya, dari mana asalnya, tindakan apa yang diminta, dan Resource apa yang dituju. Log audit sangat penting untuk penyelidikan forensik setelah insiden keamanan serta untuk mendeteksi perilaku anomali seperti pengikatan peran yang tidak biasa, akses ke secret, atau perintah exec ke pod produksi. Log audit sebaiknya dialirkan ke SIEM terpusat. Falco menyediakan pemantauan perilaku kontainer saat berjalan, sedangkan layanan Kubernetes yang dikelola cloud (EKS, GKE, AKS) menyediakan integrasi log audit bawaan dengan platform logging masing-masing.

Keamanan rantai pasokan untuk Kubernetes memastikan bahwa hanya citra tepercaya dan terverifikasi yang mencapai produksi. Rekomendasi Supply Chain Security dari CNCF mencakup: memverifikasi tanda tangan citra dengan Cosign sebelum deployment (diberlakukan melalui pengendali penerimaan), membuat dan memverifikasi SBOM (Software Bills of Materials) untuk semua citra kontainer guna melacak asal-usul komponen, menetapkan citra ke digest (myimage@sha256:abc123) alih-alih tag yang dapat berubah, serta memindai semua bagan Helm pihak ketiga untuk mencari kesalahan konfigurasi dan kerentanan sebelum deployment.

Uji pemahaman Anda tentang konsep CompTIA Security+ (SY0-701) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari: RBAC Kubernetes mengendalikan akses API melalui Roles, ClusterRoles, dan Bindings — selalu terapkan hak istimewa minimum pada akun layanan; konfigurasi NetworkPolicy yang secara bawaan menolak semua akses mencegah pergerakan lateral antara pod dan namespace; serta Pod Security Standards memberlakukan penguatan keamanan kontainer pada tingkat namespace dengan memblokir kontainer berhak istimewa, akses jaringan host, dan eksekusi sebagai root. Selanjutnya kita akan membahas keamanan tanpa server dan permukaan serangan pada tingkat fungsi.