Catatan perev. : Ini bukan artikel pertama dengan rekomendasi keamanan umum tentang Kubernet yang kami terjemahkan di blog kami. Namun, relevansinya - setidaknya sebagai pengingat hal-hal sederhana dan penting yang tidak boleh ditutup-tutupi karena kurangnya waktu - hanya dikonfirmasi oleh peristiwa baru-baru ini yang disebutkan oleh penulis di awal materi. Omong-omong, penulisnya adalah Connor Gilbert, manajer produk untuk StackRox, platform siap pakai untuk mengamankan aplikasi yang digunakan dalam kluster Kubernetes. Jadi, inilah sarannya kepada pembaca blog CNCF ...
NB : Untuk membuat artikel lebih informatif, untuk beberapa istilah / metode yang disebutkan oleh penulis, kami menambahkan tautan ke dokumentasi yang relevan.
Bulan lalu, Kubernetes, sistem orkestrasi peti kemas paling populer di dunia,
menemukan kerentanan keamanan utama pertama yang menghantam ekosistem proyek. Kerentanan
CVE-2018-1002105 memungkinkan penyerang untuk berkompromi cluster melalui server API Kubernetes, yang memungkinkan kode berbahaya dijalankan untuk menginstal malware, dll.
Awal tahun ini, konfigurasi panel kontrol Kubernetes yang salah menyebabkan fakta bahwa sumber daya Tesla
telah menginstal perangkat lunak penambangan cryptocurrency. Kemudian penyerang mengambil keuntungan dari fakta bahwa salah satu panel Kubernetes tidak dilindungi kata sandi, yang memungkinkan mereka untuk mengakses salah satu pod dengan akun untuk mengakses infrastruktur Tesla yang lebih besar di AWS.
Organisasi yang mempercepat implementasi wadah dan orkestrasi mereka juga perlu mengambil langkah-langkah wajib untuk melindungi bagian penting dari infrastruktur mereka. Berikut adalah sembilan praktik keamanan terbaik Kubernet berdasarkan data pelanggan: ikuti mereka untuk melindungi infrastruktur Anda dengan lebih baik.
1. Perbarui ke versi terbaru
Dalam setiap rilis [Kubernetes] triwulanan, tidak hanya perbaikan bug, tetapi juga fitur keamanan baru: untuk memanfaatkannya, kami sarankan bekerja dengan versi stabil terbaru.
Menggunakan rilis terbaru dengan tambalan terbaru akan sangat relevan mengingat penemuan terbaru dari CVE-2018-1002105. Pembaruan dan dukungan mungkin lebih sulit daripada fitur baru yang ditawarkan dalam rilis, jadi rencanakan pembaruan Anda setidaknya sekali dalam satu kuartal.
Pembaruan yang disederhanakan secara signifikan dapat menggunakan penyedia solusi Kubernetes yang dikelola.
2. Aktifkan kontrol akses berbasis peran (RBAC)
Gunakan
RBAC (Kontrol Akses Berbasis Peran) untuk mengontrol siapa yang dapat mengakses API Kubernetes dan hak apa yang mereka miliki. Biasanya, RBAC diaktifkan secara default di Kubernetes versi 1.6 dan lebih tinggi (atau lebih baru untuk beberapa penyedia), tetapi jika Anda telah diperbarui sejak itu dan tidak mengubah konfigurasi, Anda harus memeriksa ulang pengaturan Anda. Karena mekanisme di mana pekerjaan pengontrol otorisasi di Kubernetes digabungkan
(untuk urutan operasi umum, baca artikel " Apa yang terjadi di Kubernet ketika run kubectl dimulai? Bagian 1 " - sekitar Terjemahan. ) , Anda harus mengaktifkan RBAC dan legacy ABAC diaktifkan (Kontrol Akses Berbasis Atribut).
Namun, mengaktifkan RBAC tidak cukup - masih perlu digunakan secara efektif. Dalam kasus umum, hak atas seluruh cluster
(cluster-wide) harus dihindari, dengan memberikan preferensi pada hak dalam ruang nama tertentu. Hindari memberi seseorang hak istimewa administrator gugus bahkan untuk debugging - jauh lebih aman untuk memberikan hak hanya jika perlu dan dari waktu ke waktu.
Anda bisa melihat peran cluster dan hanya peran dengan
kubectl get clusterrolebinding atau
kubectl get rolebinding --all-namespaces . Dan agar Anda dapat dengan cepat memeriksa siapa peran
cluster-admin (dalam contoh ini, ini hanya untuk grup
masters ):
$ kubectl describe clusterrolebinding cluster-admin Name: cluster-admin Labels: kubernetes.io/boostrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate=true Role: Kind: ClusterRole Name: cluster-admin Subjects: Kind Name ---- ---- Group system:masters Namespace ---------
Jika aplikasi membutuhkan akses ke Kubernetes API, buat akun layanan terpisah
(baca lebih lanjut tentang mereka dalam materi ini - kira - kira. Terjemahan ) . Dan berikan mereka set hak minimum yang diperlukan untuk setiap kasus penggunaan. Pendekatan ini jauh lebih baik daripada memberikan terlalu banyak hak istimewa ke akun default di namespace.
Sebagian besar aplikasi tidak memerlukan akses ke API sama sekali:
Anda dapat mengatur automountServiceAccountToken menjadi
false untuk mereka.
3. Gunakan ruang nama untuk menetapkan batas keamanan
Membuat ruang nama yang terpisah adalah penting sebagai tingkat pertama isolasi komponen. Jauh lebih mudah untuk menyesuaikan pengaturan keamanan - misalnya, kebijakan jaringan - ketika berbagai jenis beban kerja digunakan dalam ruang nama yang terpisah.
Apakah tim Anda menggunakan ruang nama secara efisien? Periksa daftar mereka untuk non-standar (tidak dibuat secara default):
$ kubectl get ns NAME STATUS AGE default Active 16m kube-public Active 16m kube-system Active 16m
4. Pisahkan beban kerja sensitif.
Praktik yang baik untuk membatasi konsekuensi potensial kompromi adalah menjalankan beban kerja dengan data sensitif pada set mesin khusus. Pendekatan ini mengurangi risiko aplikasi yang kurang aman mengakses aplikasi dengan data sensitif yang berjalan di lingkungan yang dapat dieksekusi wadah yang sama atau pada host yang sama. Misalnya, sebuah kubelet dari node yang dikompromikan biasanya memiliki akses ke konten rahasia hanya jika mereka dipasang pada pod yang dijadwalkan untuk dieksekusi pada node yang sama. Jika rahasia penting dapat ditemukan pada beberapa node cluster, penyerang akan memiliki lebih banyak peluang untuk mendapatkannya.
Pemisahan dapat dilakukan dengan menggunakan
kumpulan simpul -
kumpulan simpul (di cloud atau untuk di tempat) - serta mekanisme kontrol Kubernet, seperti ruang nama,
noda, toleransi, dan lainnya.
5. Lindungi akses ke metadata layanan cloud
Metadata sensitif - misalnya, kredensial administratif kubelet - dapat dicuri atau digunakan dengan maksud jahat untuk meningkatkan hak istimewa dalam sebuah cluster. Misalnya,
penemuan terbaru dalam karunia bug Shopify menunjukkan secara detail bagaimana pengguna dapat melebihi otoritas dengan menerima metadata dari penyedia cloud menggunakan data yang dibuat khusus untuk salah satu layanan microser.
Di GKE, fungsi
penyembunyian metadata ,
penyembunyian metadata , mengubah mekanisme untuk menyebarkan cluster dengan cara yang menghindari masalah seperti itu, dan kami menyarankan untuk menggunakannya sampai solusi permanen diimplementasikan.
Penanggulangan serupa mungkin diperlukan di lingkungan lain.
6. Membuat dan menetapkan kebijakan jaringan cluster
Kebijakan Jaringan - Kebijakan
Jaringan - memungkinkan Anda untuk mengontrol akses jaringan ke dan dari aplikasi kemas. Untuk menggunakannya, Anda harus memiliki penyedia jaringan dengan dukungan untuk sumber daya tersebut; untuk penyedia solusi Kubernetes yang dikelola seperti Google Kubernetes Engine (GKE), dukungan harus diaktifkan. (Mengaktifkan kebijakan jaringan untuk kluster yang ada di GKE akan memerlukan pembaruan singkat.)
Setelah semuanya siap, mulailah dengan kebijakan jaringan default sederhana - misalnya, memblokir (secara default) lalu lintas dari ruang nama lain.
Jika Anda menggunakan Google Container Engine, Anda dapat memeriksa apakah dukungan kebijakan diaktifkan pada kluster yang berfungsi:
$ gcloud container clusters list \ --format='table[box] (name,addonsConfig.networkPolicyConfig)'
7. Tetapkan Kebijakan Keamanan Pod untuk kluster.
Kebijakan Keamanan Pod -
Kebijakan Keamanan Pod - menetapkan nilai default yang digunakan untuk memulai beban kerja di kluster. Pertimbangkan mendefinisikan kebijakan dan mengaktifkan
pengontrol penerimaan Kebijakan Keamanan Pod: instruksi untuk langkah-langkah ini bervariasi tergantung pada penyedia cloud atau model penyebaran yang digunakan.
Sebagai permulaan, Anda mungkin
NET_RAW kemampuan NET_RAW dalam wadah untuk melindungi diri Anda dari serangan spoofing jenis tertentu.
8. Bekerja pada keamanan simpul
Untuk meningkatkan keamanan host, Anda dapat mengikuti langkah-langkah ini:
- Pastikan bahwa host dikonfigurasikan dengan aman dan benar . Salah satu caranya adalah Tolok Ukur CIS ; Banyak produk memiliki autochecker yang secara otomatis memeriksa sistem untuk kepatuhan dengan standar-standar ini.
- Monitor ketersediaan jaringan port penting . Pastikan bahwa jaringan memblokir akses ke port yang digunakan oleh kubelet, termasuk 10250 dan 10255. Pertimbangkan untuk membatasi akses ke server API Kubernetes - dengan pengecualian jaringan tepercaya. Dalam kelompok yang tidak memerlukan otentikasi dan otorisasi di kubelet API, penyerang menggunakan akses ke port tersebut untuk meluncurkan cryptocurrency miner.
- Minimalkan akses administratif ke host Kubernetes . Akses ke node cluster pada prinsipnya harus dibatasi: untuk debugging dan memecahkan masalah lain, sebagai suatu peraturan, Anda dapat melakukannya tanpa akses langsung ke node.
9. Aktifkan Audit Logging
Pastikan
log audit diaktifkan dan bahwa Anda memantau terjadinya panggilan API yang tidak biasa atau tidak diinginkan, terutama dalam konteks setiap kegagalan otorisasi - entri tersebut akan memiliki pesan dengan status "Terlarang". Kegagalan otorisasi dapat berarti bahwa penyerang berusaha untuk mengambil keuntungan dari kredensial yang diperoleh.
Penyedia solusi terkelola (termasuk GKE) menyediakan akses ke data ini di antarmuka mereka dan dapat membantu Anda mengatur notifikasi jika terjadi kegagalan otorisasi.
Mencari masa depan
Ikuti panduan ini untuk kluster Kubernetes yang lebih aman. Ingat bahwa bahkan setelah cluster dikonfigurasikan dengan aman, Anda harus memastikan keamanan dalam aspek lain dari konfigurasi dan pengoperasian kontainer. Untuk meningkatkan keamanan tumpukan teknologi, jelajahi alat-alat yang menyediakan sistem pusat untuk mengelola kontainer yang digunakan, terus memantau dan melindungi kontainer dan aplikasi asli cloud.
PS dari penerjemah
Baca juga di blog kami: