Halaman ini menjelaskan deteksi ancaman GKE, yang memungkinkan Anda memindai cluster GKE yang memenuhi syarat untuk menemukan ancaman aktif di dasbor postur keamanan GKE. Dasbor postur keamanan GKE memungkinkan Anda mengaktifkan berbagai kemampuan pemindaian dan audit di cluster GKE yang memenuhi syarat dan menampilkan rekomendasi yang dapat ditindaklanjuti untuk membantu Anda menyelesaikan masalah keamanan.
Cara kerjanya
GKE Threat Detection adalah kemampuan dasbor postur keamanan GKE lanjutan yang tersedia untuk pengguna GKE Enterprise. Saat cluster GKE Anda terdaftar dalam fleet, deteksi ancaman GKE akan mengevaluasi log audit GKE di Cloud Logging berdasarkan serangkaian aturan yang telah ditentukan untuk ancaman cluster dan workload. Jika ancaman ditemukan, Anda akan melihat temuan di dasbor postur keamanan GKE dengan deskripsi ancaman, potensi dampaknya, dan tindakan yang direkomendasikan untuk mengurangi ancaman tersebut.
Semua cluster GKE terdaftar di seluruh fleet Anda terus-menerus dipindai untuk mendeteksi ancaman aktif. Kami mengklasifikasikan ancaman yang terdeteksi menggunakan taktik MITRE ATT&CK®.
Deteksi ancaman GKE didukung oleh layanan Event Threat Detection Security Command Center. Di dasbor postur keamanan GKE, hanya subset aturan yang berlaku untuk GKE yang dievaluasi.
Fitur postur keamanan GKE yang disertakan
Deteksi ancaman GKE dipaketkan dengan tingkat lanjut pemindaian postur keamanan Kubernetes. Saat mengaktifkan deteksi ancaman GKE di cluster, Anda juga mengaktifkan fitur pemindaian berikut:
- Audit konfigurasi workload
- Munculnya buletin keamanan (Pratinjau)
Penggunaan dalam konteks strategi keamanan yang lebih luas
Deteksi ancaman GKE adalah salah satu dari berbagai produk visibilitas keamanan yang harus Anda gunakan di lingkungan Anda. Sebaiknya gunakan fitur lain dari dasbor postur keamanan GKE, seperti pemindaian kerentanan, untuk memastikan Anda memantau cluster untuk berbagai masalah keamanan. Untuk informasi selengkapnya, lihat Tentang dasbor postur keamanan di dokumentasi GKE.
Sebaiknya Anda juga menerapkan sebanyak mungkin tindakan keamanan dari Meningkatkan keamanan cluster di cluster dan workload Anda.
Harga
GKE Threat Detection ditawarkan tanpa biaya tambahan melalui GKE Enterprise.
Aturan standar deteksi ancaman GKE
Tabel berikut menjelaskan aturan evaluasi yang digunakan oleh deteksi ancaman GKE untuk mengevaluasi log audit GKE Anda:
| Nama tampilan | Nama API | Jenis sumber log | Deskripsi |
|---|---|---|---|
| Penghindaran Pertahanan: Deployment Workload Breakglass Dibuat (Pratinjau) | BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_CREATE |
Cloud Audit Logs: Log Aktivitas Admin |
Mendeteksi deployment workload yang di-deploy menggunakan flag break-glass untuk mengganti kontrol Binary Authorization. |
| Defense Evasion: Deployment Workload Breakglass Diperbarui (Pratinjau) | BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_UPDATE |
Cloud Audit Logs: Log Aktivitas Admin |
Mendeteksi kapan beban kerja diperbarui menggunakan flag break-glass untuk mengganti kontrol Binary Authorization. |
| Penemuan: Dapat mendapatkan pemeriksaan objek Kubernetes sensitif | GKE_CONTROL_PLANE_CAN_GET_SENSITIVE_OBJECT |
Cloud Audit Logs: Log Akses Data GKE |
Pelaku yang berpotensi berbahaya mencoba menentukan objek sensitif di GKE yang dapat mereka kueri, dengan menggunakan perintah
|
| Eskalasi Hak Istimewa: Perubahan pada objek RBAC Kubernetes sensitif | GKE_CONTROL_PLANE_EDIT_SENSITIVE_RBAC_OBJECT |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Untuk mengeskalasi hak istimewa, pelaku yang berpotensi berbahaya mencoba mengubah objek kontrol akses berbasis peran (RBAC) ClusterRole, RoleBinding, atau ClusterRoleBinding dari peran sensitif
cluster-admin
menggunakan permintaan PUT atau PATCH.
|
| Eskalasi Hak Istimewa: Membuat CSR Kubernetes untuk sertifikat master | GKE_CONTROL_PLANE_CSR_FOR_MASTER_CERT |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Pelaku yang berpotensi berbahaya membuat
permintaan penandatanganan sertifikat
(CSR) master Kubernetes, yang memberinya
akses
cluster-admin.
|
| Eskalasi Hak Istimewa: Pembuatan binding Kubernetes sensitif | GKE_CONTROL_PLANE_CREATE_SENSITIVE_BINDING |
Cloud Audit Logs: Log audit Aktivitas Admin IAM |
Untuk mengeskalasi hak istimewa, pelaku yang berpotensi berbahaya mencoba membuat objek
RoleBinding atau ClusterRoleBinding baru untuk
peran
cluster-admin.
|
| Eskalasi Hak Istimewa: Mendapatkan CSR Kubernetes dengan kredensial bootstrap yang disusupi | GKE_CONTROL_PLANE_GET_CSR_WITH_COMPROMISED_BOOTSTRAP_CREDENTIALS |
Cloud Audit Logs: Log Akses Data GKE |
Pelaku yang berpotensi berbahaya membuat kueri untuk
permintaan penandatanganan sertifikat
(CSR), dengan perintah kubectl, menggunakan kredensial bootstrap yang disusupi.
|
| Eskalasi Hak Istimewa: Peluncuran penampung Kubernetes dengan hak istimewa | GKE_CONTROL_PLANE_LAUNCH_PRIVILEGED_CONTAINER |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Pelaku yang berpotensi berbahaya membuat Pod yang berisi container dengan hak istimewa atau container dengan kemampuan eskalasi hak istimewa.
Penampung dengan hak istimewa memiliki kolom |
| Akses Kredensial: Secret Diakses di Namespace Kubernetes | SECRETS_ACCESSED_IN_KUBERNETES_NAMESPACE |
Cloud Audit Logs: Log Akses Data GKE |
Mendeteksi kapan secret atau token akun layanan diakses oleh akun layanan di namespace Kubernetes saat ini. |
| Akses Awal: Resource GKE Anonim yang Dibuat dari Internet (Pratinjau) | GKE_RESOURCE_CREATED_ANONYMOUSLY_FROM_INTERNET |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Mendeteksi peristiwa pembuatan resource dari pengguna internet yang efektif anonim. |
| Akses Awal: Resource GKE Diubah secara Anonim dari Internet (Pratinjau) | GKE_RESOURCE_MODIFIED_ANONYMOUSLY_FROM_INTERNET |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Mendeteksi peristiwa manipulasi resource dari pengguna internet yang efektif anonim. |
| Eskalasi Hak Istimewa: Pengguna Anonim yang Efektif Diberi Akses Cluster GKE (Pratinjau) | GKE_ANONYMOUS_USERS_GRANTED_ACCESS |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang membuat binding RBAC yang mereferensikan salah satu pengguna atau grup berikut:
Pengguna dan grup ini secara efektif bersifat anonim dan harus dihindari saat membuat binding peran atau binding peran cluster ke peran RBAC apa pun. Tinjau binding untuk memastikan bahwa binding tersebut diperlukan. Jika binding tidak diperlukan, hapus. |
| Eksekusi: Exec atau Lampiran yang Mencurigakan ke Pod Sistem (Pratinjau) | GKE_SUSPICIOUS_EXEC_ATTACH |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang menggunakan perintah exec atau attach untuk mendapatkan shell atau
menjalankan perintah pada penampung yang berjalan di namespace kube-system.
Metode ini terkadang digunakan untuk tujuan proses debug yang sah. Namun, namespace kube-system ditujukan untuk objek sistem yang dibuat oleh Kubernetes,
dan eksekusi perintah atau pembuatan shell yang tidak terduga harus ditinjau.
|
| Eskalasi Hak Istimewa: Workload yang Dibuat dengan Pemasangan Jalur Host Sensitif (Pratinjau) | GKE_SENSITIVE_HOSTPATH |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang membuat beban kerja yang berisi pemasangan volume hostPath ke
jalur sensitif di sistem file node host. Akses ke jalur ini di sistem file
host dapat digunakan untuk mengakses informasi sensitif atau istimewa di node dan untuk
escape penampung. Jika memungkinkan, jangan izinkan volume hostPath apa pun di
cluster Anda.
|
| Eskalasi Akses: Beban kerja dengan shareProcessNamespace diaktifkan (Pratinjau) | GKE_SHAREPROCESSNAMESPACE_POD |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang men-deploy workload dengan opsi shareProcessNamespace yang ditetapkan ke
true, sehingga memungkinkan semua container berbagi namespace proses Linux yang sama.
Hal ini dapat memungkinkan penampung yang tidak tepercaya atau disusupi untuk mengeskalasi hak istimewa dengan
mengakses dan mengontrol variabel lingkungan, memori, dan data sensitif lainnya dari
proses yang berjalan di penampung lain.
|
| Eskalasi Hak Istimewa: ClusterRole dengan Kata Kerja Berhak Istimewa (Pratinjau) | GKE_CLUSTERROLE_PRIVILEGED_VERBS |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang membuat ClusterRole RBAC yang berisi kata kerja bind,
escalate, atau impersonate. Subjek yang terikat dengan
peran dengan kata kerja ini dapat meniru identitas pengguna lain dengan hak istimewa yang lebih tinggi, terikat dengan
Roles atau ClusterRoles tambahan yang berisi izin
tambahan, atau mengubah izin ClusterRole mereka sendiri. Hal ini dapat menyebabkan subjek tersebut mendapatkan hak istimewa admin cluster.
|
| Eskalasi Hak Istimewa: ClusterRoleBinding ke Peran Berhak Istimewa (Pratinjau) | GKE_CRB_CLUSTERROLE_AGGREGATION_CONTROLLER |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang membuat ClusterRoleBinding RBAC yang mereferensikan system:controller:clusterrole-aggregation-controller
ClusterRole
default. ClusterRole default ini memiliki
kata kerja escalate, yang memungkinkan subjek mengubah hak istimewa peran
mereka sendiri, sehingga memungkinkan eskalasi hak istimewa.
|
| Defense Evasion: Certificate Signing Request (CSR) yang Dihapus Secara Manual (Pratinjau) | GKE_MANUALLY_DELETED_CSR |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang menghapus permintaan penandatanganan sertifikat (CSR) secara manual. CSR secara otomatis dihapus oleh pengontrol pengumpulan sampah, tetapi pelaku kejahatan mungkin menghapusnya secara manual untuk menghindari deteksi. Jika CSR yang dihapus adalah untuk sertifikat yang disetujui dan diterbitkan, pelaku yang berpotensi berbahaya kini memiliki metode autentikasi tambahan untuk mengakses cluster. Izin yang terkait dengan sertifikat bervariasi bergantung pada subjek yang disertakan, tetapi dapat memiliki hak istimewa yang sangat tinggi. Kubernetes tidak mendukung pencabutan sertifikat. |
| Akses Kredensial: Gagal Mencoba Menyetujui Permintaan Penandatanganan Sertifikat Kubernetes (CSR) (Pratinjau) | GKE_APPROVE_CSR_FORBIDDEN |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang mencoba menyetujui permintaan penandatanganan sertifikat (CSR) secara manual, tetapi tindakan tersebut gagal. Membuat sertifikat untuk autentikasi cluster adalah metode umum bagi penyerang untuk membuat akses persisten ke cluster yang disusupi. Izin yang terkait dengan sertifikat bervariasi bergantung pada subjek yang disertakan, tetapi dapat memiliki hak istimewa yang sangat tinggi. |
| Akses Kredensial: Permintaan Penandatanganan Sertifikat (CSR) Kubernetes yang Disetujui Secara Manual (Pratinjau) | GKE_CSR_APPROVED |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang menyetujui permintaan penandatanganan sertifikat (CSR) secara manual. Membuat sertifikat untuk autentikasi cluster adalah metode umum bagi penyerang untuk membuat akses persisten ke cluster yang disusupi. Izin yang terkait dengan sertifikat bervariasi bergantung pada subjek yang disertakan, tetapi dapat memiliki hak istimewa yang sangat tinggi. |
| Eksekusi: Pod Kubernetes Dibuat dengan Argumen Reverse Shell Potensial (Pratinjau) | GKE_REVERSE_SHELL_POD |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang membuat Pod yang berisi perintah atau argumen yang biasanya dikaitkan dengan reverse shell. Penyerang menggunakan reverse shell untuk memperluas atau mempertahankan akses awal mereka ke cluster dan untuk mengeksekusi perintah arbitrer. |
| Penghindaran Pertahanan: Potensi Penyamaran Pod Kubernetes (Pratinjau) | GKE_POD_MASQUERADING |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang men-deploy Pod dengan konvensi penamaan yang mirip dengan beban kerja default yang dibuat GKE untuk operasi cluster reguler. Teknik ini disebut penyamaran. |
| Eskalasi Hak Istimewa: Nama Penampung Kubernetes yang Mencurigakan - Eksploitasi dan Pelarian (Pratinjau) | GKE_SUSPICIOUS_EXPLOIT_POD |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang men-deploy Pod dengan konvensi penamaan yang mirip dengan alat umum yang digunakan untuk container escape atau untuk menjalankan serangan lain di cluster. |
| Dampak: Nama Penampung Kubernetes yang Mencurigakan - Penambangan Koin (Pratinjau) | GKE_SUSPICIOUS_CRYPTOMINING_POD |
Cloud Audit Logs: Log Aktivitas Admin GKE |
Seseorang men-deploy Pod dengan konvensi penamaan yang mirip dengan penambang koin cryptocurrency umum. Hal ini mungkin merupakan upaya penyerang yang telah mendapatkan akses awal ke cluster untuk menggunakan resource cluster tersebut untuk menambang mata uang kripto. |
Cara mengaktifkan deteksi ancaman GKE
Untuk mengaktifkan deteksi ancaman GKE, Anda harus mendaftarkan cluster yang memenuhi syarat ke paket lanjutan pemindaian postur keamanan Kubernetes. Tindakan ini juga mengaktifkan semua kemampuan yang disertakan dalam tingkat dasar pemindaian postur keamanan Kubernetes, seperti pengauditan konfigurasi workload dan munculnya buletin keamanan.
Untuk mempelajari lebih lanjut, lihat Menemukan ancaman di cluster menggunakan deteksi ancaman GKE.
Batasan
Batasan berikut berlaku untuk deteksi ancaman GKE:
- Hanya tersedia di GKE Enterprise
- Hanya tersedia untuk project dalam organisasi
- Tidak mendukung opsi Security Command Center seperti mengonfigurasi residensi data
- Hanya menampilkan hasil untuk cluster yang terdaftar ke suatu fleet
- GKE menyimpan temuan ancaman yang tidak lagi memiliki resource terkait yang terpengaruh hingga 180 hari
- Hanya menampilkan hasil untuk cluster yang ada. Jika Anda menghapus cluster, deteksi ancaman GKE tidak akan lagi menampilkan temuan di dasbor postur keamanan GKE.