Dokumen ini menjelaskan cara Google mengelola kerentanan dan patch keamanan untuk Google Kubernetes Engine (GKE). Informasi ini mungkin berguna bagi Spesialis keamanan yang mendukung penyelesaian masalah atau kerentanan keamanan yang memerlukan bantuan strategis, seperti insiden dan masalah yang diteruskan dari dukungan.
Patching tanggung jawab bersama
Patching merupakan tanggung jawab bersama antara Google dan pelanggan, seperti yang dijelaskan dalam Tanggung jawab bersama GKE.
Cara kami menemukan kerentanan
Google telah melakukan investasi besar pada desain dan hardening keamanan proaktif, bahkan sistem software dengan desain terbaik sekalipun memiliki kerentanan. Untuk menemukan kerentanan tersebut dan melakukan patch sebelum dapat dieksploitasi, Google telah melakukan investasi yang signifikan di berbagai bidang.
Untuk tujuan patching, GKE adalah lapisan Sistem Operasi (OS) dengan container yang berjalan di atasnya. Sistem operasi, Container-Optimized OS atau Ubuntu, telah diperkuat dan berisi jumlah minimum software yang diperlukan untuk menjalankan container. Fitur GKE berjalan sebagai container di atas image dasar. GKE secara konsisten berupaya mengurangi jumlah dependensi yang dimiliki komponen sistem, sehingga membantu mengurangi permukaan serangan dan meningkatkan efisiensi manajemen kerentanan. Misalnya, komponen sistem GKE dapat menggunakan image dasar minimal jika memungkinkan.
Google mengidentifikasi dan memperbaiki kerentanan dan patch yang tidak ada dengan cara berikut:
Container-Optimized OS: Google memindai image untuk mengidentifikasi potensi kerentanan dan patch yang tidak ada. Tim Container-Optimized OS meninjau dan menyelesaikan masalah.
Ubuntu: Canonical memberi Google build OS dengan semua patch keamanan yang tersedia dan diterapkan.
Google memindai container menggunakan Container Registry Artifact Analysis untuk menemukan kerentanan dan patch yang tidak ada di Kubernetes dan container yang dikelola Google. Jika perbaikan tersedia, pemindai secara otomatis memulai proses patch dan rilis.
Selain pemindaian otomatis, Google menemukan dan melakukan patch pada kerentanan yang tidak diketahui oleh pemindai dengan cara berikut.
Google melakukan audit, pengujian penetrasi, dan penemuan kerentanan sendiri di seluruh platform. Untuk mengetahui daftar platform, lihat bagian sebelumnya, Tanggung jawab bersama dalam penerapan patch.
Tim khusus di dalam Google dan vendor keamanan pihak ketiga tepercaya melakukan riset serangan mereka sendiri. Google juga bekerja sama dengan CNCF untuk menyediakan banyak keahlian konsultasi teknis dan organisasi untuk audit keamanan Kubernetes.
Google secara aktif berinteraksi dengan komunitas riset keamanan melalui beberapa vulnerability reward program. Program hadiah kerentanan khusus memberikan hadiah yang signifikan, termasuk 133.337 USD untuk kerentanan cloud terbaik yang ditemukan setiap tahunnya. Google Cloud Untuk GKE, ada program yang memberikan reward kepada peneliti keamanan jika mereka dapat merusak kontrol keamanan kami. Program ini mencakup semua dependensi software GKE.
Google berkolaborasi dengan partner software open source dan industri lain yang membagikan kerentanan, riset keamanan, dan patch sebelum rilis publik kerentanan tersebut. Tujuan dari kolaborasi ini adalah untuk melakukan patch infrastruktur Internet dalam jumlah besar sebelum kerentanan diumumkan kepada publik. Dalam beberapa kasus, Google berkontribusi terhadap kerentanan yang ditemukan dalam komunitas ini. Misalnya, Project Zero Google menemukan dan memublikasikan kerentanan Spectre and Meltdown. Tim Keamanan Google Cloud juga secara rutin menemukan dan memperbaiki kerentanan di Kernel-based Virtual Machine (KVM).
Kolaborasi keamanan Google terjadi di berbagai level. Terkadang masalah ini terjadi secara formal melalui program yang didaftarkan oleh organisasi untuk menerima notifikasi pra-rilis terkait kerentanan software untuk produk seperti Kubernetes dan Envoy. Kolaborasi juga terjadi secara informal karena interaksi kami dengan banyak project open source, seperti kernel Linux, runtime container, teknologi virtualisasi, dan lainnya.
Untuk Kubernetes, Google adalah anggota aktif dan pendiri Security Response Committee (SRC) dan menulis banyak Proses Rilis Keamanan. Google adalah anggota Daftar Distributor Kubernetes yang menerima notifikasi kerentanan sebelumnya dan telah terlibat dalam triase, patching, pengembangan mitigasi, dan komunikasi dalam hampir semua kerentanan keamanan Kubernetes yang serius. Google juga menemukan beberapa kerentanan Kubernetes, seperti CVE-2019-11254, CVE-2019-11255, dan CVE-2021-25741.
Meskipun kerentanan yang tidak terlalu parah ditemukan dan di-patch di luar proses ini, sebagian besar kerentanan keamanan yang penting dilaporkan secara pribadi melalui salah satu saluran yang sebelumnya tercantum. Pelaporan awal memberi Google waktu sebelum kerentanan menjadi publik untuk meneliti pengaruhnya terhadap GKE, mengembangkan patch atau mitigasi, serta menyiapkan saran dan komunikasi untuk pelanggan. Jika memungkinkan, Google akan melakukan patch pada semua cluster sebelum rilis publik kerentanan.
Cara kerentanan diklasifikasikan
GKE melakukan investasi besar dalam memperkuat keamanan pada seluruh stack, termasuk OS, container, Kubernetes, dan lapisan jaringan, selain menetapkan setelan default yang baik, konfigurasi yang di-hardening dengan keamanan, dan komponen terkelola. Gabungan upaya ini membantu mengurangi dampak dan kemungkinan kerentanan.
Tim keamanan GKE mengklasifikasikan kerentanan berdasarkan sistem penskoran kerentanan Kubernetes. Klasifikasi mempertimbangkan banyak faktor, termasuk konfigurasi dan hardening keamanan GKE. Karena faktor ini dan investasi yang dilakukan GKE dalam hal keamanan, klasifikasi kerentanan GKE mungkin berbeda dari sumber klasifikasi lainnya.
Tabel berikut menjelaskan kategori tingkat keparahan kerentanan:
| Keparahan | Deskripsi |
|---|---|
| Penting | Kerentanan mudah dieksploitasi di semua cluster oleh penyerang jarak jauh yang tidak diautentikasi yang mengakibatkan penyusupan sistem sepenuhnya. |
| Tinggi | Kerentanan mudah dieksploitasi oleh banyak cluster yang mengakibatkan hilangnya kerahasiaan, integritas, atau ketersediaan. |
| Sedang | Kerentanan yang dapat dieksploitasi untuk beberapa cluster di mana hilangnya kerahasiaan, integritas, atau ketersediaan dibatasi oleh konfigurasi umum, kesulitan eksploitasi itu sendiri, akses yang diperlukan, atau interaksi pengguna. |
| Rendah | Semua kerentanan lainnya. Eksploitasi tidak mungkin dilakukan atau konsekuensi dari eksploitasi terbatas. |
Lihat buletin keamanan untuk mengetahui contoh kerentanan, perbaikan dan mitigasi, serta ratingnya.
Cara kerentanan di-patch untuk cluster GKE
Melakukan patch pada kerentanan melibatkan upgrade ke nomor versi GKE yang baru. Versi GKE mencakup komponen berversi untuk sistem operasi, komponen Kubernetes, dan container lain yang membentuk platform GKE. Perbaikan beberapa kerentanan hanya memerlukan upgrade bidang kontrol, yang dilakukan secara otomatis oleh Google di GKE, sementara yang lain memerlukan upgrade bidang kontrol dan node.
Agar cluster tetap diperkuat dari kerentanan pada semua tingkat keparahan, sebaiknya ikuti praktik terbaik untuk upgrade cluster GKE guna membantu memastikan cluster Anda menerima patch keamanan secara tepat waktu.
Google merekomendasikan upgrade cluster Kubernetes setidaknya setiap bulan. Untuk mengetahui daftar platform, lihat bagian sebelumnya, Tanggung jawab bersama dalam penerapan patch.
Beberapa pemindai keamanan atau pemeriksaan versi manual mungkin secara keliru mengasumsikan bahwa komponen seperti runc atau containerd tidak memiliki patch keamanan upstream tertentu. GKE secara rutin melakukan patch pada komponen dan hanya melakukan upgrade versi paket jika diperlukan, yang berarti bahwa komponen GKE secara fungsional serupa dengan komponen upstream-nya meskipun nomor versi komponen GKE tidak cocok dengan nomor versi upstream. Untuk mengetahui detail tentang CVE tertentu, lihat buletin keamanan GKE.
Melakukan patch pada linimasa
Tujuan Google adalah memitigasi kerentanan yang terdeteksi dalam jangka waktu yang sesuai dengan risiko yang dimiliki. GKE disertakan dalam ATO sementara FedRAMPGoogle Cloud, yang mengharuskan perbaikan kerentanan yang diketahui dalam jangka waktu tertentu sesuai dengan tingkat keparahannya sebagaimana ditentukan dalam kontrol RA-5(d) dari catatan Penilaian Risiko (RA) RA-5, "Pemindaian Kerentanan", dalam spreadsheet Dasar Kontrol Keamanan FedRAMP.
Untuk setiap kerentanan yang diketahui, tujuan GKE adalah merilis versi patch yang memperbaiki kerentanan dalam jangka waktu yang sesuai. Setelah GKE menyediakan versi patch untuk memperbaiki kerentanan yang diketahui, upgrade cluster Anda ke versi tersebut untuk memenuhi jangka waktu penerapan patch bagi organisasi Anda.
Bagaimana kerentanan dan patch dikomunikasikan
Sumber terbaik untuk informasi terkini tentang kerentanan dan patch keamanan untuk GKE adalah buletin keamanan.
Mulai 1 Juni 2026, GKE tidak memublikasikan buletin keamanan untuk Google Distributed Cloud (khusus software), GKE di AWS, atau GKE di Azure. Untuk melihat buletin keamanan dan perbaikan kerentanan yang lebih baru untuk produk ini, lihat dokumen berikut:
Kerentanan terkadang dirahasiakan di bawah embargo selama waktu terbatas. Embargo membantu mencegah publikasi awal kerentanan yang dapat menyebabkan upaya eksploitasi secara luas sebelum langkah-langkah dapat diambil untuk mengatasinya. Dalam situasi embargo, catatan rilis merujuk pada "update keamanan" hingga embargo dicabut. Setelah embargo dicabut, Google memperbarui catatan rilis untuk menyertakan kerentanan tertentu.
Tim keamanan GKE memublikasikan buletin keamanan untuk kerentanan tingkat keparahan Tinggi dan Kritis. Saat tindakan pelanggan diperlukan untuk mengatasi kerentanan Tinggi dan Penting ini, Google akan menghubungi pelanggan melalui email. Selain itu, Google juga dapat menghubungi pelanggan yang memiliki kontrak dukungan melalui saluran dukungan.
Apa cara tercepat untuk menginstal patch keamanan?
Semua cluster akan otomatis di-patch dengan upgrade otomatis GKE. Bagian ini menjelaskan cara menerapkan patch lebih cepat daripada upgrade otomatis untuk perbaikan keamanan tertentu, atau secara berkelanjutan. Dengan menggabungkan lingkungan pengujian, upgrade manual lintas saluran, setelan patch yang dipercepat, dan notifikasi berbasis peristiwa, Anda dapat mengurangi waktu tunggu penerapan patch.
GKE mengelola peluncuran versi di seluruh saluran rilis untuk memastikan versi baru memenuhi syarat dan diuji. Untuk mengurangi waktu tunggu penerapan patch, Anda perlu memahami cara kerja peluncuran ini, lalu menyesuaikan perilaku default agar sesuai dengan kebutuhan spesifik Anda.
Menguji versi yang di-patch melibatkan menjalankan versi tersebut di cluster dari waktu ke waktu untuk mengamati stabilitas. Proses ini membantu menemukan bug yang hanya muncul setelah penggunaan yang lama di berbagai lingkungan. Untuk memastikan waktu tunggu yang memadai, rilis patch GKE diperkenalkan terlebih dahulu ke saluran Cepat, diikuti oleh Reguler dan Stabil. Rilis juga diuji di setiap saluran sebelum menjadi target upgrade untuk saluran tersebut.
Kualifikasikan patch lebih awal dan kelola peluncuran dengan urutan peluncuran
Untuk memenuhi syarat patch keamanan yang ingin Anda percepat, gunakan urutan peluncuran untuk meluncurkan di seluruh lingkungan, menguji patch di cluster GKE lain sebelum mengupgrade lingkungan produksi. Pendekatan ini memungkinkan Anda memverifikasi kompatibilitas workload, dan mendeteksi masalah segera setelah perbaikan keamanan dirilis oleh Google. Kemudian, Anda dapat menerapkan versi yang telah di-patch ke seluruh armada dan mengontrol waktu perendaman yang tersisa.
Kurangi penundaan soak dengan upgrade otomatis patch yang dipercepat
Atau, Anda dapat memilih untuk menggunakan patch lebih cepat dengan mengaktifkan upgrade otomatis patch yang dipercepat untuk cluster Anda. Fitur ini memberi tahu GKE untuk melewati waktu perendaman dalam saluran untuk update patch, terutama patch keamanan. Jika Anda menggunakan pendekatan ini, Google merekomendasikan untuk menjalankan cluster pengujian di saluran Cepat (juga dengan upgrade otomatis patch yang dipercepat) untuk memenuhi syarat patch.
Upgrade manual ke versi patch yang lebih baru di saluran Reguler dan Stabil
Jika workload produksi Anda berada di cluster yang terdaftar di saluran Reguler atau Stabil, Anda tidak perlu keluar dari saluran tersebut atau menunggu peluncuran patch bertahap otomatis untuk menjangkau Anda jika ada update keamanan tertentu yang perlu diprioritaskan.
Jika Anda telah memenuhi syarat untuk versi patch, Anda dapat memulai upgrade secara manual pada cluster Anda di Regular atau Stable ke versi patch yang sama persis untuk mengontrol waktu berdiam yang tersisa.
Mengotomatiskan pengelolaan patch dengan notifikasi cluster
Anda tidak perlu memantau halaman web buletin keamanan untuk mendapatkan informasi patch. Untuk mendapatkan notifikasi terprogram yang cepat tentang patch yang tersedia dan memicu tindakan kualifikasi patch dan upgrade, Anda dapat menggunakan notifikasi cluster.
Untuk mendapatkan notifikasi terkait buletin keamanan atau upgrade terjadwal, konfigurasi notifikasi Anda untuk memfilter secara khusus jenis peristiwa berikut:
Notifikasi cluster memungkinkan Anda menerima pesan real-time saat peristiwa ini terjadi. Anda dapat mengintegrasikan notifikasi ini ke dalam sistem informasi keamanan dan manajemen peristiwa (SIEM), operasi chat, atau memicu pipeline pengujian otomatis.