Keselamatan Kubernetes: RBAC, Dasar Rangkaian dan Keselamatan Pod

Kubernetes mengatur beban kerja berContainer pada skala besar, tetapi kerumitannya mewujudkan permukaan serangan yang luas. Komponen utama yang mesti dilindungi termasuk: Pelayan API (satah kawalan pusat — jika dikompromi, penyerang akan mengawal keseluruhan kelompok), etcd (pangkalan data keadaan kelompok — menyimpan rahsia dalam base64 dan mesti disulitkan semasa tidak digunakan), kubelet (ejen nod — API kubelet tanpa pengesahan membolehkan pelaksanaan Pod sewenang-wenangnya), masa jalan Container (Docker/containerd) dan fabrik rangkaian yang menyambungkan semua Pod. Calon Security+ perlu memahami bahawa salah konfigurasi Kubernetes merupakan antara penemuan keselamatan awan yang paling lazim.

RBAC (Role-Based Access Control) Kubernetes mengawal pengguna, akaun perkhidmatan dan proses yang boleh melakukan tindakan tertentu pada sumber API tertentu. Model ini mempunyai empat objek: Role (keizinan berruang nama), ClusterRole (keizinan seluruh kelompok), RoleBinding (memberikan Role kepada subjek dalam sesuatu ruang nama) dan ClusterRoleBinding (memberikan ClusterRole kepada subjek di seluruh kelompok). Setiap arahan kubectl diterjemahkan kepada panggilan API yang diperiksa berdasarkan peraturan RBAC. Jika RBAC tidak dikonfigurasi, mana-mana pengguna yang disahkan (atau akaun perkhidmatan) mungkin mempunyai akses pentadbiran.

Setiap Pod dalam Kubernetes berjalan di bawah akaun perkhidmatan — identiti yang digunakan untuk pengesahan API. Secara lalai, Pod menggunakan akaun perkhidmatan default dalam ruang namanya, yang mungkin mempunyai keizinan luas. Prinsip keistimewaan minimum memerlukan penciptaan akaun perkhidmatan khusus untuk setiap aplikasi, dengan hanya keizinan yang diperlukan oleh aplikasi tersebut. Selain itu, menetapkan automountServiceAccountToken: false pada Pod yang tidak memerlukan akses API menghalang token akaun perkhidmatan daripada dipasang ke dalam sistem fail Pod, tempat aplikasi yang telah dikompromi boleh menggunakannya untuk membuat panggilan API.

Secara lalai dalam Kubernetes, semua Pod boleh berkomunikasi dengan semua Pod lain dalam mana-mana ruang nama. Pod yang telah dikompromi boleh terus cuba mencapai pangkalan data, API dalaman dan perkhidmatan mikro lain. Sumber Kubernetes NetworkPolicy mentakrifkan peraturan yang mengehadkan trafik antara Pod berdasarkan label, ruang nama dan port. Pendekatan yang disyorkan ialah dasar rangkaian 'tolak semua secara lalai' dalam setiap ruang nama, diikuti peraturan benarkan yang jelas untuk laluan komunikasi yang diperlukan. Perhatikan bahawa NetworkPolicy memerlukan pemalam CNI yang menyokongnya (Calico, Cilium, Weave) — Kubernetes biasa mengabaikan NetworkPolicy tanpa CNI yang serasi.

Pod Security Standards (PSS), yang diperkenalkan dalam Kubernetes 1.23 dan stabil dalam 1.25, menggantikan Pod Security Policy (PSP) yang telah ditamatkan dengan tiga profil terbina dalam yang dikuatkuasakan pada peringkat ruang nama: Privileged (tanpa sekatan, untuk komponen sistem), Baseline (menghalang peningkatan keistimewaan yang diketahui seperti Container berkeistimewaan dan akses rangkaian hos) dan Restricted (diperketatkan, memerlukan pengguna bukan root, menggugurkan semua keupayaan dan menguatkuasakan sistem fail root baca sahaja). Ruang nama dilabelkan untuk menguatkuasakan tahap dasar, dan Pod yang melanggarnya ditolak semasa kemasukan.

Secrets Kubernetes menyimpan data sensitif seperti kata laluan, token dan sijil TLS. Secara lalai, Secrets disimpan dalam etcd sebagai nilai yang dikodkan base64 — bukan dalam bentuk yang disulitkan. Sesiapa yang boleh membaca etcd atau mempunyai keizinan RBAC yang mencukupi boleh menyahkodnya dengan mudah. Amalan terbaik termasuk: mendayakan penyulitan semasa tidak digunakan untuk etcd menggunakan AES-GCM dengan kunci yang disimpan dalam KMS (AWS KMS, GCP KMS), berintegrasi dengan pengurus rahsia luaran seperti HashiCorp Vault atau AWS Secrets Manager melalui Secrets Store CSI Driver, serta mengehadkan akses Secret melalui RBAC supaya hanya akaun perkhidmatan yang memerlukannya boleh membacanya.

Pengawal kemasukan ialah pemalam dalam pelayan API Kubernetes yang memintas permintaan API selepas pengesahan dan kebenaran tetapi sebelum objek disimpan, lalu membolehkannya mengesahkan, mengubah atau menolak permintaan. Pengawal kemasukan yang berkaitan dengan keselamatan termasuk: PodSecurity (menguatkuasakan Pod Security Standards), ImagePolicyWebhook (membolehkan pengesahan penandatanganan imej luaran), AlwaysPullImages (memaksa pengambilan imej baharu untuk menghalang penggunaan imej berniat jahat yang dicache secara setempat) dan OPA/Gatekeeper (Open Policy Agent — paling fleksibel, membolehkan dasar tersuai yang dinyatakan dalam bahasa Rego untuk menguatkuasakan sebarang peraturan keselamatan organisasi).

Pengukuhan komponen satah kawalan Kubernetes adalah kritikal: pelayan API harus menggunakan --anonymous-auth=false untuk melumpuhkan akses tanpa pengesahan, --audit-log-path yang dikonfigurasi untuk merekodkan semua aktiviti API, serta TLS untuk semua sambungan. kubelet harus menggunakan --authorization-mode=Webhook (bukan AlwaysAllow) dan melumpuhkan pengesahan tanpa nama. etcd harus mempunyai penyulitan rakan setara dan klien TLS, akses rangkaian yang terhad (hanya boleh dicapai oleh pelayan API) serta penyulitan data semasa tidak digunakan. Penanda Aras CIS Kubernetes menyediakan senarai semak menyeluruh untuk semua tetapan komponen.

ruang nama Kubernetes menyediakan pemisahan logik sumber tetapi bukan sempadan keselamatan yang kukuh dengan sendirinya — ruang nama terutamanya menyediakan pengasingan organisasi. Untuk pengasingan penyewaan berbilang yang sebenar (contohnya, beban kerja pelanggan yang berbeza), kawalan tambahan diperlukan: dasar rangkaian untuk menyekat trafik antara ruang nama, kuota sumber untuk menghalang DoS jiran yang bising, kumpulan nod berasingan untuk penyewa yang memerlukan pengasingan kukuh atau kelompok khusus bagi setiap penyewa. Banyak organisasi menggunakan Hierarchical Namespaces atau penyelesaian komersial seperti vCluster untuk penyewaan berbilang yang lebih kukuh dalam satu kelompok.

Kubernetes pengelogan audit merekodkan setiap permintaan API: pihak yang membuatnya, asalnya, tindakan yang diminta dan Resource yang disasarkan. Log audit penting untuk penyiasatan forensik selepas insiden keselamatan serta untuk mengesan tingkah laku luar biasa seperti pengikatan peranan yang tidak lazim, capaian kepada rahsia atau perintah exec ke dalam pod produksi. Log audit hendaklah distrim ke SIEM berpusat. Falco menyediakan pemantauan masa jalan bagi tingkah laku kontena, manakala perkhidmatan Kubernetes terurus awan (EKS, GKE, AKS) menyediakan integrasi log audit asli dengan platform pengelogan masing-masing.

Keselamatan rantaian bekalan untuk Kubernetes memastikan hanya imej yang dipercayai dan disahkan sampai ke produksi. Syor CNCF Keselamatan Rantaian Bekalan merangkumi: mengesahkan tandatangan imej dengan Cosign sebelum pelancaran (dikuatkuasakan melalui pengawal kemasukan), menjana dan mengesahkan SBOM (Senarai Bahan Perisian) untuk semua imej kontena bagi menjejaki asal usul komponen, memautkan imej kepada digest (myimage@sha256:abc123) dan bukannya tag boleh ubah, serta mengimbas semua carta Helm pihak ketiga untuk mencari salah konfigurasi dan kelemahan sebelum pelancaran.

Dalam pelajaran ini, anda telah mempelajari bahawa: RBAC Kubernetes mengawal capaian API melalui Roles, ClusterRoles dan Bindings — sentiasa gunakan keistimewaan minimum untuk akaun perkhidmatan; konfigurasi NetworkPolicy larangan lalai menghalang pergerakan sisi antara pod dan ruang nama; dan Pod Security Standards menguatkuasakan pengerasan kontena pada peringkat ruang nama dengan menyekat kontena berkeistimewaan, capaian rangkaian hos dan pelaksanaan sebagai root. Seterusnya, kita akan meneroka keselamatan tanpa pelayan dan permukaan serangan pada peringkat fungsi.