Arsip buletin keamanan

Halaman ini berisi arsip historis semua buletin keamanan sebelum tahun 2020 untuk produk berikut:

Untuk melihat buletin keamanan terbaru, lihat halaman Buletin keamanan.

Buletin keamanan GKE

14 November 2019

Dipublikasikan: 14-11-2019
Diperbarui: 14-11-2019
Deskripsi Keparahan Catatan

Kubernetes telah mengungkapkan masalah keamanan di sidecar kubernetes-csi external-provisioner, external-snapshotter, dan external-resizer yang memengaruhi sebagian besar versi sidecar yang dipaketkan dalam driver Container Storage Interface (CSI). Untuk detail selengkapnya, baca pengungkapan Kubernetes.

Apa yang sebaiknya saya lakukan?
Kerentanan ini tidak memengaruhi komponen GKE terkelola. Anda mungkin terpengaruh jika mengelola driver CSI Anda sendiri di cluster GKE Alfa yang menjalankan GKE versi 1.12 atau yang lebih tinggi. Jika Anda terpengaruh, hubungi vendor driver CSI Anda untuk mendapatkan petunjuk upgrade.

Kerentanan apa yang diatasi oleh patch ini?
CVE-2019-11255: CVE ini adalah kerentanan di sidecar kubernetes-csi external-provisioner, external-snapshotter, dan external-resizer yang dapat mengizinkan mutasi atau akses data volume yang tidak sah. Hal ini memengaruhi sebagian besar versi sidecar yang dipaketkan dalam driver CSI.

Sedang

CVE-2019-11255

12 November 2019

Dipublikasikan: 12-11-2019
Diperbarui: 12-11-2019
Deskripsi Keparahan Catatan

Intel telah mengungkapkan CVE yang berpotensi memungkinkan interaksi antara eksekusi spekulatif dan status mikroarsitektur untuk mengekspos data. Untuk detail selengkapnya, lihat pengungkapan Intel.

Infrastruktur host yang menjalankan Kubernetes Engine mengisolasi beban kerja pelanggan. Kecuali jika Anda menjalankan kode yang tidak tepercaya di dalam cluster GKE multi-tenant Anda sendiri dan menggunakan node N2, M2, atau C2, tidak ada tindakan lebih lanjut yang diperlukan. Untuk instance GKE di node N1, Anda tidak perlu melakukan tindakan baru.

Jika Anda menjalankan Google Distributed Cloud, eksposur bergantung pada hardware. Harap bandingkan infrastruktur Anda dengan pengungkapan Intel.

Apa yang harus saya lakukan?

Anda hanya akan terpengaruh jika menggunakan node pool dengan node N2, M2, atau C2 dan node tersebut menjalankan kode yang tidak tepercaya di dalam cluster GKE multi-tenant Anda sendiri.

Memulai ulang node akan menerapkan patch. Cara termudah untuk memulai ulang semua node di node pool Anda adalah dengan menggunakan operasi upgrade untuk memaksa mulai ulang di semua node pool yang terpengaruh.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

CVE-2019-11135: CVE ini juga dikenal sebagai TSX Async Abort (TAA). TAA menyediakan cara lain untuk mengeksfiltrasi data menggunakan struktur data mikroarsitektur yang sama yang dieksploitasi oleh Sampling Data Mikroarsitektur (MDS).

CVE-2018-12207 Ini adalah kerentanan Denial of Service (DoS) yang memengaruhi host virtual machine sehingga memungkinkan tamu berbahaya membuat host yang tidak dilindungi mengalami error. CVE ini juga dikenal sebagai "Machine Check Error on Page Size Change". Hal ini tidak memengaruhi GKE.

Sedang

CVE-2019-11135
CVE-2018-12207

22 Oktober 2019

Dipublikasikan: 22-10-2019
Diperbarui: 22-10-2019
Deskripsi Keparahan Catatan

Baru-baru ini ditemukan kerentanan dalam bahasa pemrograman Go, yang dijelaskan dalam CVE-2019-16276. Kerentanan ini berpotensi memengaruhi konfigurasi Kubernetes yang menggunakan Proxy Autentikasi. Untuk detail selengkapnya, baca pengungkapan Kubernetes.

Kubernetes Engine tidak mengizinkan konfigurasi Proxy Autentikasi, sehingga tidak terpengaruh oleh kerentanan ini.

Tidak ada

CVE-2019-16276

16 Oktober 2019

Dipublikasikan: 16-10-2019
Diperbarui: 24-10-2019
Deskripsi Keparahan Catatan

Pembaruan 24-10-2019: Versi yang di-patch kini tersedia di semua zona.

Baru-baru ini ditemukan kerentanan di Kubernetes, yang dijelaskan dalam CVE-2019-11253, yang memungkinkan pengguna yang diberi otorisasi untuk membuat permintaan POST mengeksekusi serangan Denial of Service jarak jauh di server Kubernetes API. Kubernetes Product Security Committee (PSC) merilis informasi tambahan tentang kerentanan ini yang dapat ditemukan di sini.

Cluster GKE yang menggunakan Jaringan Master yang Diizinkan dan Cluster pribadi tanpa endpoint publik mengurangi kerentanan ini.

Apa yang harus saya lakukan?

Sebaiknya upgrade cluster Anda ke versi patch yang berisi perbaikan begitu tersedia. Kami memperkirakannya akan tersedia di semua zona dengan rilis GKE yang direncanakan untuk minggu 14 Oktober.

Versi patch yang akan berisi mitigasi tercantum di bawah:

  • 1.12.10-gke.15
  • 1.13.11-gke.5
  • 1.14.7-gke.10
  • 1.15.4-gke.15
Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

CVE-2019-11253 adalah kerentanan Denial-of-Service (DoS).

Tinggi

CVE-2019-11253

16 September 2019

Dipublikasikan: 16-09-2019
Diperbarui: 16-10-2019
Deskripsi Keparahan Catatan

Buletin ini telah diperbarui sejak publikasi aslinya.

Bahasa pemrograman Go baru-baru ini menemukan kerentanan keamanan baru CVE-2019-9512 dan CVE-2019-9514, yang merupakan kerentanan Denial of Service (DoS). Di GKE, kerentanan ini mengizinkan pengguna membuat permintaan berbahaya yang dapat menghabiskan terlalu banyak CPU di server Kubernetes API sehingga berpotensi mengurangi ketersediaan bidang kontrol cluster. Untuk detail selengkapnya, lihat pengungkapan bahasa pemrograman Go.

Apa yang harus saya lakukan?

Sebaiknya upgrade cluster Anda ke versi patch terbaru, yang berisi mitigasi untuk kerentanan ini, segera setelah tersedia. Kami memperkirakannya akan tersedia di semua zona dengan rilis GKE berikutnya, sesuai dengan jadwal rilis.

Versi patch yang akan berisi mitigasi tercantum di bawah:

  • Pembaruan 16 Oktober 2019: 1.12.10-gke.15
  • 1.13.10-gke.0
  • 1.14.6-gke.1
Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

CVE-2019-9512 dan CVE-2019-9514 adalah kerentanan Denial of Service (DoS).

Tinggi

CVE-2019-9512
CVE-2019-9514

5 September 2019

Dipublikasikan: 05-09-2019
Diperbarui: 05-09-2019

Buletin untuk perbaikan kerentanan yang didokumentasikan dalam buletin 31 Mei 2019 telah diperbarui.

22 Agustus 2019

Dipublikasikan: 22-08-2019
Diperbarui: 22-08-2019

Buletin untuk 5 Agustus 2019 telah diperbarui. Perbaikan untuk kerentanan yang didokumentasikan dalam buletin sebelumnya tersedia.

8 Agustus 2019

Dipublikasikan: 08-08-2019
Diperbarui: 08-08-2019

Buletin untuk 5 Agustus 2019 telah diperbarui. Kami memperkirakan perbaikan untuk kerentanan yang didokumentasikan dalam buletin tersebut akan tersedia dalam rilis GKE berikutnya.

5 Agustus 2019

Dipublikasikan: 05-08-2019
Diperbarui: 09-08-2019
Deskripsi Keparahan Catatan

Buletin ini telah diperbarui sejak publikasi aslinya.

Kubernetes baru-baru ini menemukan kerentanan, CVE-2019-11247, yang memungkinkan instance resource kustom cakupan cluster ditindaklanjuti seolah-olah objek tersebut adalah objek dengan namespace yang ada di semua Namespace. Artinya, akun pengguna dan layanan yang hanya memiliki izin RBAC tingkat namespace dapat berinteraksi dengan resource kustom cakupan cluster. Untuk mengeksploitasi kerentanan ini, penyerang harus memiliki hak istimewa untuk mengakses resource di namespace mana pun.

Apa yang harus saya lakukan?

Sebaiknya upgrade cluster Anda ke versi patch terbaru, yang berisi mitigasi untuk kerentanan ini, segera setelah tersedia. Kami memperkirakannya akan tersedia di semua zona dengan rilis GKE berikutnya. Versi patch yang akan berisi mitigasi tercantum di bawah:

  • 1.11.10-gke.6
  • 1.12.9-gke.13
  • 1.13.7-gke.19
  • 1.14.3-gke.10 (Saluran Cepat)
Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi kerentanan berikut: CVE-2019-11247.

Sedang

CVE-2019-11247

3 Juli 2019

Dipublikasikan: 03-07-2019
Diperbarui: 03-07-2019
Deskripsi Keparahan Catatan

Versi kubectl yang di-patch untuk mengatasi CVE-2019-11246 kini tersedia dengan gcloud 253.0.0. Lihat Buletin keamanan 25 Juni 2019 untuk informasi selengkapnya.

Catatan: Patch tidak tersedia di kubectl 1.11.10.

Tinggi

CVE-2019-11246

3 Juli 2019

Dipublikasikan: 25-06-2019
Diperbarui: 03-07-2019
Deskripsi Keparahan Catatan
Pembaruan 3 Juli 2019

Pada saat update terakhir kami, patch untuk versi 1.11.9 dan 1.11.10 belum tersedia. Kami kini telah merilis 1.11.10-gke.5 sebagai target upgrade untuk kedua versi 1.11.

Saat ini, master GKE telah di-patch, dan infrastruktur Google yang menjalankan Kubernetes Engine telah di-patch dan dilindungi dari kerentanan ini.

Master 1.11 akan segera tidak digunakan lagi dan dijadwalkan untuk otomatis diupgrade ke 1.12 pada minggu 8 Juli 2019. Anda dapat memilih salah satu tindakan yang disarankan berikut untuk mendapatkan node ke versi yang di-patch:

  • Lakukan upgrade node ke 1.11.10-gke.5 paling lambat 8 Juli 2019. Setelah tanggal ini, versi 1.11 akan mulai dihapus dari daftar target upgrade yang tersedia.
  • Aktifkan upgrade otomatis di node 1.11 dan izinkan node diupgrade saat master diupgrade ke 1.12.
  • Upgrade master dan node secara manual ke versi 1.12 yang diperbaiki.

Buletin asli dari 24 Juni 2019 adalah sebagai berikut:

Update 24 Juni 2019

Mulai 22-06-2019 21.40 UTC, kami telah menyediakan versi Kubernetes yang di-patch berikut. Master antara Kubernetes versi 1.11.0 dan 1.13.6 akan otomatis diupdate ke versi yang di-patch. Jika Anda tidak menjalankan versi yang kompatibel dengan patch ini, upgrade ke versi master yang kompatibel (tercantum di bawah) sebelum mengupgrade node.

Karena keparahan kerentanan ini, baik upgrade otomatis node telah diaktifkan atau belum, sebaiknya Anda mengupgrade node dan master secara manual ke salah satu versi ini secepatnya.

Versi yang di-patch:

  • 1.11.8-gke.10
  • 1.12.7-gke.24
  • 1.12.8-gke.10
  • 1.13.6-gke.13

Berikut adalah buletin asli dari 18 Juni 2019:

Netflix baru-baru ini mengungkapkan tiga kerentanan TCP di kernel Linux:

CVE tersebut secara keseluruhan disebut sebagai NFLX-2019-001.

Kernel Linux yang tidak di-patch mungkin rentan terhadap serangan denial of service yang dipicu dari jarak jauh. Node Google Kubernetes Engine yang mengirim atau menerima traffic jaringan tidak tepercaya terpengaruh, dan sebaiknya ikuti langkah-langkah mitigasi di bawah ini untuk melindungi workload Anda.

Master Kubernetes

  • Master Kubernetes yang menggunakan Jaringan yang Diizinkan untuk membatasi traffic ke jaringan tepercaya tidak akan terpengaruh.

  • Master untuk cluster GKE, yang dikelola oleh Google, akan di-patch secara otomatis dalam beberapa hari mendatang. Pelanggan tidak perlu melakukan tindakan apa pun.

Node Kubernetes

Node yang membatasi traffic ke jaringan tepercaya tidak akan terpengaruh. Ini akan menjadi cluster dengan hal berikut:

  • Node yang dilindungi firewall dari jaringan yang tidak tepercaya atau tanpa IP publik (Cluster pribadi)
  • Cluster tanpa Service LoadBalancer publik

Google sedang menyiapkan mitigasi permanen untuk kerentanan ini yang akan tersedia sebagai versi node baru. Kami akan memperbarui buletin ini dan mengirimkan email kepada semua pelanggan GKE saat perbaikan permanen tersedia.

Hingga perbaikan permanen tersedia, kami telah membuat DaemonSet Kubernetes yang menerapkan mitigasi dengan mengubah konfigurasi iptables host.

Apa yang harus saya lakukan?

Terapkan DaemonSet Kubernetes ke semua node di cluster Anda dengan menjalankan perintah berikut. Tindakan ini akan menambahkan aturan iptables ke aturan iptables yang ada di node untuk mengurangi kerentanan. Jalankan perintah sekali per cluster per project Google Cloud. 

kubectl apply -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml

Setelah versi node yang di-patch tersedia dan Anda telah mengupgrade semua node yang berpotensi terpengaruh, Anda dapat menghapus DaemonSet menggunakan perintah berikut. Jalankan perintah sekali per cluster per project Google Cloud. 

kubectl delete -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml
Tinggi
Sedang
Sedang
 CVE-2019-11477
CVE-2019-11478
CVE-2019-11479

25 Juni 2019

Deskripsi Keparahan Catatan

Pembaruan 03-07-2019: Patch ini tersedia di gcloud 253.0.0, untuk kubectl versi 1.12.9, 1.13.6, 1.14.2, dan rilis yang lebih baru.

Catatan: Patch ini tidak tersedia di versi 1.11.10.

Kubernetes baru-baru ini menemukan kerentanan, CVE-2019-11246, yang memungkinkan penyerang dengan akses ke operasi kubectl cp dan eksekusi kode di dalam penampung untuk mengubah file di host. Eksploitasi ini berpotensi memungkinkan penyerang mengganti atau membuat file di sistem file host. Untuk detail selengkapnya, lihat pengungkapan Kubernetes.

Semua versi gcloud Google Kubernetes Engine (GKE) terpengaruh oleh kerentanan ini, dan sebaiknya Anda mengupgrade ke versi patch gcloud terbaru saat tersedia. Versi patch mendatang akan menyertakan mitigasi untuk kerentanan ini.

Apa yang harus saya lakukan?

Versi kubectl yang di-patch akan tersedia dalam rilis gcloud mendatang. Anda juga dapat mengupgrade kubectl secara langsung sendiri.

Lacak ketersediaan patch ini di catatan rilis gcloud.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Kerentanan CVE-2019-11246 memungkinkan penyerang yang memiliki akses ke operasi kubectl cp dan eksekusi kode di dalam penampung untuk mengubah file di host. Eksploit ini berpotensi memungkinkan penyerang mengganti atau membuat file di sistem file host

Tinggi

CVE-2019-11246

18 Juni 2019

Deskripsi Keparahan Catatan

Docker baru-baru ini menemukan kerentanan, CVE-2018-15664, yang memungkinkan penyerang yang dapat mengeksekusi kode di dalam penampung untuk membajak operasi docker cp yang dimulai secara eksternal. Eksploitasi ini berpotensi memungkinkan penyerang mengubah lokasi file yang ditulis, ke lokasi arbitrer dalam sistem file host.

Semua node Google Kubernetes Engine (GKE) yang menjalankan Docker terpengaruh oleh kerentanan ini, dan sebaiknya Anda mengupgrade ke versi patch terbaru setelah tersedia. Versi patch mendatang akan menyertakan mitigasi untuk kerentanan ini.

Semua master Google Kubernetes Engine (GKE) yang lebih lama dari versi 1.12.7 menjalankan Docker dan terpengaruh oleh kerentanan ini. Di GKE, pengguna tidak memiliki akses ke docker cp di master sehingga risiko kerentanan ini terbatas untuk master GKE.

Apa yang harus saya lakukan?

Hanya node yang menjalankan Docker yang terpengaruh, dan hanya jika perintah docker cp (atau yang setara dengan API) yang dapat dibajak dikeluarkan. Hal ini diperkirakan cukup tidak biasa di lingkungan Kubernetes. Node yang menjalankan COS dengan containerd tidak terpengaruh.

Agar dapat mengupgrade node, pertama-tama Anda harus mengupgrade master ke versi yang di-patch. Saat patch tersedia, Anda dapat memulai upgrade master atau menunggu Google mengupgrade master secara otomatis. Patch akan tersedia di Docker 18.09.7, yang disertakan dalam patch GKE mendatang. Patch ini hanya akan tersedia untuk GKE versi 1.13 dan yang lebih baru.

Kami akan mengupgrade master cluster ke versi yang di-patch secara otomatis, dengan ritme upgrade reguler. Anda juga dapat memulai upgrade master sendiri setelah versi yang di-patch tersedia.

Kami akan memperbarui buletin ini dengan versi yang berisi patch setelah tersedia. Lacak ketersediaan patch ini di catatan rilis.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

Kerentanan CVE-2018-15664 memungkinkan penyerang yang dapat mengeksekusi kode di dalam penampung untuk membajak operasi docker cp yang dimulai secara eksternal. Eksploitasi ini berpotensi memungkinkan penyerang mengubah tempat file ditulis, ke lokasi arbitrer dalam sistem file host.

Tinggi

31 Mei 2019

Deskripsi Keparahan Catatan

Buletin ini telah diperbarui sejak publikasi aslinya.

Update 2 Agustus 2019

Pada saat buletin awal, hanya 1.13.6-gke.0 hingga 1.13.6-gke.5 yang terpengaruh. Karena regresi, semua versi 1.13.6.x kini terpengaruh. Jika Anda menjalankan 1.13.6, upgrade ke 1.13.7 sesegera mungkin.

Project Kubernetes telah mengungkapkan CVE-2019-11245 di kubelet v1.13.6 dan v1.14.2, yang dapat menyebabkan container berjalan sebagai UID 0 (biasanya dipetakan ke pengguna root), meskipun pengguna lain ditentukan dalam image container. Jika container Anda berjalan sebagai pengguna non-root dan Anda menjalankan node versi 1.13.6-gke.0 hingga 1.13.6-gke.6, sebaiknya tetapkan RunAsUser di semua Pod dalam cluster yang container-nya tidak boleh berjalan sebagai UID 0.

Jika nilai USER non-root ditentukan (misalnya, dengan menetapkan nilai USER dalam Dockerfile), perilaku yang tidak terduga akan terjadi. Saat berjalan untuk pertama kalinya di node, penampung akan mematuhi UID yang ditentukan dengan benar. Namun, karena cacat ini, pada operasi kedua (dan operasi berikutnya), penampung berjalan sebagai UID 0, terlepas dari UID yang ditentukan. Hal ini biasanya merupakan hak istimewa yang dieskalasikan dan tidak diinginkan, dan dapat menyebabkan perilaku aplikasi yang tidak terduga.

Bagaimana cara mengetahui apakah saya menjalankan versi yang terpengaruh?

Jalankan perintah berikut untuk menampilkan semua node dan versi kubelet-nya: 

kubectl get nodes -o=jsonpath='{range .items[*]}'\
'{.status.nodeInfo.machineID}'\
'{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'

Jika output mencantumkan versi kubelet yang tercantum di bawah, node Anda akan terpengaruh:

  • v1.13.6
  • v1.14.2
Bagaimana cara mengetahui apakah konfigurasi saya terpengaruh?

Jika penampung Anda berjalan sebagai pengguna non-root, dan Anda menjalankan node versi 1.13.6-gke.0 hingga 1.13.6-gke.6, Anda akan terpengaruh kecuali dalam kasus berikut:

  • Pod yang menentukan nilai non-root yang valid untuk runAsUser PodSecurityContext tidak akan terpengaruh dan terus berfungsi seperti yang diharapkan.
  • PodSecurityPolicies yang menerapkan setelan runAsUser juga tidak terpengaruh dan terus berfungsi seperti yang diharapkan.
  • Pod yang menentukan mustRunAsNonRoot:true tidak akan dimulai sebagai UID 0, tetapi akan gagal dimulai jika terpengaruh oleh masalah ini.
Apa yang harus saya lakukan?

Tetapkan Konteks Keamanan RunAsUser di semua Pod di cluster yang tidak boleh berjalan sebagai UID 0. Anda dapat menerapkan konfigurasi ini menggunakan PodSecurityPolicy.

Sedang CVE-2019-11245

14 Mei 2019

Deskripsi Keparahan Catatan

Update 11-06-2019: Patch ini tersedia di 1.11.10-gke.4, 1.12.8-gke.6, dan 1.13.6-gke.5 yang dirilis pada minggu 28-05-2019, dan rilis yang lebih baru.

Intel telah mengungkapkan CVE berikut:

CVE tersebut secara keseluruhan disebut sebagai Microarchitectural Data Sampling (MDS). Kerentanan ini berpotensi memungkinkan data diekspos melalui interaksi eksekusi spekulatif dengan status mikroarsitektur. Untuk detail selengkapnya, lihat pengungkapan Intel.

Infrastruktur host yang menjalankan Kubernetes Engine mengisolasi beban kerja pelanggan dari satu sama lain. Kecuali jika Anda menjalankan kode tidak tepercaya di dalam cluster GKE multi-tenant Anda sendiri, Anda tidak akan terpengaruh.

Bagi pelanggan yang menjalankan kode tidak tepercaya di layanan multi-tenant mereka sendiri dalam Kubernetes Engine, ini adalah kerentanan yang sangat parah. Untuk menguranginya di Kubernetes Engine, nonaktifkan Hyper-Threading di node Anda. Hanya node Google Kubernetes Engine (GKE) yang menggunakan beberapa CPU yang terpengaruh oleh kerentanan ini. Perhatikan bahwa VM n1-standard-1 (default GKE), g1-small, dan f1-micro hanya mengekspos 1 vCPU ke lingkungan tamu sehingga tidak perlu menonaktifkan Hyper-Threading.

Perlindungan tambahan untuk mengaktifkan fungsi flush akan disertakan dalam versi patch mendatang. Kami akan mengupgrade master dan node dengan upgrade otomatis ke versi yang di-patch secara otomatis dalam beberapa minggu mendatang, dengan ritme upgrade reguler. Patch saja tidak cukup untuk memitigasi eksposur terhadap kerentanan ini. Lihat tindakan yang disarankan di bawah.

Jika menjalankan GKE di premis, Anda mungkin terpengaruh, bergantung pada hardware yang digunakan. Silakan baca Pengungkapan Intel.

Apa yang harus saya lakukan?

Kecuali jika Anda menjalankan kode yang tidak tepercaya di dalam cluster GKE multi-tenant Anda sendiri, Anda tidak akan terpengaruh.

Untuk node di Kubernetes Engine, buat node pool baru dengan Hyper-Threading dinonaktifkan dan jadwalkan ulang workload Anda ke node baru.

Perhatikan bahwa VM n1-standard-1, g1-small, dan f1-micro hanya mengekspos 1 vCPU ke lingkungan tamu sehingga tidak perlu menonaktifkan Hyper-Threading.

Peringatan:
  • Menonaktifkan Hyper-Threading dapat berdampak buruk pada performa cluster dan aplikasi Anda. Pastikan hal ini dapat diterima sebelum men-deploynya ke cluster produksi Anda.
  • Hyper-threading dapat dinonaktifkan di tingkat node pool GKE dengan men-deploy DaemonSet. Namun, men-deploy DaemonSet ini akan menyebabkan semua node Anda di kumpulan node dimulai ulang secara bersamaan. Oleh karena itu, sebaiknya buat node pool baru di cluster Anda, deploy DaemonSet untuk menonaktifkan Hyper-Threading di node pool tersebut, lalu migrasikan workload Anda ke node pool baru.

Untuk membuat node pool baru dengan Hyper-Threading dinonaktifkan:

  1. Buat node pool baru di cluster Anda dengan label node cloud.google.com/gke-smt-disabled=true: 
    gcloud container node-pools create smt-disabled --cluster=[CLUSTER_NAME] \
    --node-labels=cloud.google.com/gke-smt-disabled=true
  2. Deploy DaemonSet ke node pool baru ini. DaemonSet hanya akan berjalan di node dengan label cloud.google.com/gke-smt-disabled=true. Tindakan ini akan menonaktifkan Hyper-Threading, lalu memulai ulang node. 
    kubectl create -f \
https://raw.githubusercontent.com/GoogleCloudPlatform/\
k8s-node-tools/master/disable-smt/gke/disable-smt.yaml
  3. Pastikan pod DaemonSet berada dalam status berjalan. 
    kubectl get pods --selector=name=disable-smt -n kube-system

    Anda akan mendapatkan respons yang mirip dengan:

    NAME                READY     STATUS    RESTARTS   AGE

disable-smt-2xnnc   1/1       Running   0          6m
  4. Pastikan "SMT telah dinonaktifkan" muncul dalam log pod. 
    kubectl logs disable-smt-2xnnc disable-smt -n kube-system

Anda harus terus menjalankan DaemonSet di nodepool agar perubahan diterapkan secara otomatis pada node baru yang dibuat di kumpulan. Pembuatan node dapat dipicu oleh perbaikan otomatis node, upgrade manual atau otomatis, dan penskalaan otomatis.

Untuk mengaktifkan kembali Hyper-Threading, Anda harus membuat ulang node pool tanpa men-deploy DaemonSet yang disediakan, dan memigrasikan workload ke node pool baru.

Sebaiknya upgrade node secara manual setelah patch tersedia. Agar dapat mengupgrade, pertama-tama Anda harus mengupgrade master ke versi terbaru. Master GKE akan otomatis diupgrade dengan ritme upgrade reguler.

Kami akan memperbarui buletin ini dengan versi yang berisi patch setelah tersedia.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091: Kerentanan ini mengeksploitasi eksekusi spekulatif. CVE ini secara kolektif disebut sebagai Microarchitectural Data Sampling. Kerentanan ini berpotensi memungkinkan data diekspos melalui interaksi eksekusi spekulatif dengan status mikroarsitektur. 		Sedang

5 April 2019

Deskripsi Keparahan Catatan

Baru-baru ini, kerentanan keamanan CVE-2019-9900 dan CVE-2019-9901. ditemukan di Envoy.

Istio menyematkan Envoy, dan kerentanan ini memungkinkan kebijakan Istio dilewati dalam beberapa kasus.

Jika telah mengaktifkan Istio di Google Kubernetes Engine (GKE), Anda mungkin terpengaruh oleh kerentanan ini. Sebaiknya upgrade cluster yang terpengaruh ke versi patch terbaru sesegera mungkin, dan upgrade sidecar Istio Anda (petunjuk di bawah).

Apa yang harus saya lakukan?

Karena keparahan kerentanan ini, baik upgrade node otomatis telah diaktifkan atau belum, sebaiknya Anda:

  1. Upgrade cluster secara manual segera setelah patch tersedia.
  2. Upgrade sidecar Anda dengan mengikuti dokumentasi upgrade sidecar.

Versi yang di-patch akan tersedia untuk semua project GKE sebelum pukul 19.00 PDT hari ini.

Patch ini akan tersedia di versi GKE di bawah. Cluster baru akan menggunakan versi yang di-patch secara default saat diumumkan di halaman buletin keamanan GKE, yang diperkirakan pada 15 April 2019. Jika Anda membuat cluster baru sebelum tanggal tersebut, Anda harus menentukan versi yang di-patch agar dapat digunakan. Pelanggan GKE yang telah mengaktifkan upgrade node otomatis dan tidak mengupgrade secara manual, node-nya akan otomatis diupgrade ke versi yang di-patch pada minggu berikutnya.

Versi yang Di-patch:

  • 1.10.12-gke.14
  • 1.11.6-gke.16
  • 1.11.7-gke.18
  • 1.11.8-gke.6
  • 1.12.6-gke.10
  • 1.13.4-gke.10

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

CVE-2019-9900 dan CVE-2019-9901. Anda dapat membaca selengkapnya di blog Istio.

Tinggi

1 Maret 2019

Deskripsi Keparahan Catatan

Pembaruan 22-03-2019: Patch ini tersedia di Kubernetes 1.11.8-gke.4, 1.13.4-gke.1, dan rilis yang lebih baru. Patch ini belum tersedia di versi 1.12. Lacak ketersediaan patch ini di catatan rilis.

Kubernetes baru-baru ini menemukan kerentanan denial of service baru CVE-2019-1002100, yang memungkinkan pengguna yang diberi otorisasi untuk membuat permintaan patch membuat permintaan "json-patch" berbahaya yang menghabiskan CPU dan memori dalam jumlah yang berlebihan di server Kubernetes API, sehingga berpotensi mengurangi ketersediaan bidang kontrol cluster. Untuk detail selengkapnya, baca pengungkapan Kubernetes. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh kerentanan ini. Versi patch mendatang akan menyertakan mitigasi untuk kerentanan ini. Secara otomatis kami akan meng-upgrade master cluster ke versi yang sudah di-patch dalam beberapa minggu ke depan dengan ritme upgrade reguler.

Apa yang harus saya lakukan?

Anda tidak perlu melakukan tindakan apa pun. Master GKE akan otomatis diupgrade dengan ritme upgrade reguler. Jika ingin meng-upgrade master terlebih dahulu, Anda dapat memulai upgrade master secara manual.

Kami akan memperbarui buletin ini dengan versi yang berisi patch. Perhatikan bahwa patch hanya akan tersedia di versi 1.11+, bukan juga di 1.10.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

Kerentanan CVE-2019-1002100 memungkinkan pengguna membuat patch khusus jenis "json-patch" yang menghabiskan CPU dalam jumlah berlebihan di server Kubernetes API, sehingga berpotensi mengurangi ketersediaan bidang kontrol cluster.

Sedang CVE-2019-1002100

11 Februari 2019 (runc)

Deskripsi Keparahan Catatan

Open Containers Initiative (OCI) baru-baru ini menemukan kerentanan keamanan baru CVE-2019-5736 di runc yang memungkinkan container escape mendapatkan hak istimewa root di node host.

Kerentanan ini memengaruhi node Ubuntu Google Kubernetes Engine (GKE). Kami sarankan untuk meng-upgrade ke versi patch terbaru secepatnya, seperti dijelaskan di bawah ini.

Apa yang harus saya lakukan?

Agar dapat mengupgrade node, pertama-tama upgrade master ke versi terbaru. Patch ini tersedia dalam Kubernetes 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 dan rilis yang lebih baru. Lacak ketersediaan beberapa patch ini di catatan rilis.

Perlu diingat bahwa hanya node Ubuntu di GKE yang terpengaruh. Node yang menjalankan COS tidak terpengaruh.

Perhatikan bahwa runc versi baru telah meningkatkan penggunaan memori dan mungkin memerlukan pembaruan memori yang dialokasikan ke penampung jika Anda telah menetapkan batas memori yang rendah (< 16 MB).

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

CVE-2019-5736 merupakan kerentanan di runc yang mengizinkan container berbahaya (dengan interaksi pengguna minimal dalam bentuk exec) menimpa biner runc host sehingga mendapatkan eksekusi kode level root pada node host. Kerentanan ini tidak memengaruhi container yang tidak dijalankan sebagai root. Kerentanan ini dinilai sebagai kerentanan keparahan 'Tinggi'.

 Tinggi CVE-2019-5736

11 Februari 2019 (Go)

Deskripsi Keparahan Catatan

Pembaruan 25-02-2019: Patch tidak tersedia di 1.11.7-gke.4 seperti yang telah diinformasikan sebelumnya. Jika menjalankan 1.11.7, Anda dapat: mendowngrade ke 1.11.6, mengupgrade ke 1.12, atau menunggu hingga patch 1.11.7 berikutnya tersedia pada minggu 04-03-2019.

Bahasa pemograman Go baru-baru ini menemukan kerentanan keamanan baru CVE-2019-6486, yang merupakan kerentanan Denial of Service (DoS) dalam penerapan crypto/elliptic dari elliptic curve P-521 dan P-384. Pada Google Kubernetes Engine (GKE), kerentanan ini mengizinkan pengguna membuat permintaan berbahaya yang dapat menghabiskan terlalu banyak CPU di server Kubernetes API sehingga berpotensi mengurangi ketersediaan bidang kontrol kluster. Untuk detail selengkapnya, baca pengungkapan bahasa pemrograman Go.

Semua master Google Kubernetes Engine (GKE) terpengaruh oleh Kerentanan ini. Versi patch terbaru mencakup mitigasi untuk kerentanan ini. Secara otomatis kami akan meng-upgrade master kluster ke versi yang sudah di-patch dalam beberapa minggu ke depan dengan ritme upgrade reguler.

Apa yang harus saya lakukan?

Anda tidak perlu melakukan tindakan apa pun. Master GKE akan otomatis diupgrade dengan ritme upgrade reguler. Jika ingin meng-upgrade master terlebih dahulu, Anda dapat memulai upgrade master secara manual.

Patch ini tersedia dalam GKE 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5, dan rilis yang lebih baru.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

CVE-2019-6486 adalah kerentanan dalam penerapan crypto/elliptic dari elliptic curve P-521 dan P-384. Dengan kerentanan ini, pengguna dapat membuat input yang menghabiskan terlalu banyak CPU.

Tinggi CVE-2019-6486

3 Desember 2018

Deskripsi Keparahan Catatan

Baru-baru ini Kubernetes menemukan kerentanan keamanan baru CVE-2018-1002105, yang membuat pengguna dengan hak istimewa yang relatif rendah dapat melewati otorisasi ke API kubelet sehingga memiliki kemampuan untuk mengeksekusi operasi arbitrer untuk semua Pod pada semua node di dalam kluster. Untuk detail selengkapnya, baca pengungkapan Kubernetes. Kerentanan ini memengaruhi semua master Google Kubernetes Engine (GKE), dan kami telah mengupgrade kluster ke versi patch terbaru. Anda tidak perlu melakukan tindakan apa pun.

Apa yang harus saya lakukan?

Anda tidak perlu melakukan tindakan apa pun. Master GKE telah diupgrade.

Patch ini tersedia dalam GKE 1.9.7-gke.11, 1.10.6-gke.11, 1.10.7-gke.11, 1.10.9-gke.5, and 1.11.2-gke.18 dan rilis yang lebih baru.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

Kerentanan CVE-2018-1002105 memungkinkan pengguna dengan hak istimewa yang relatif rendah untuk mengabaikan otorisasi ke API kubelet. Hal ini memberi pengguna yang diberi otorisasi untuk membuat permintaan yang dapat diupgrade untuk mengeskalasi dan membuat panggilan arbitrer ke API kubelet. Kerentanan ini dinilai sebagai kerentanan Kritis di Kubernetes. Mengingat beberapa detail dalam.implementasi GKE yang dapat mencegah lokasi eskalasi yang tidak terautentikasi, kerentanan ini dinilai sebagai kerentanan Tinggi.

Tinggi CVE-2018-1002105

13 November 2018

Deskripsi

Update 16-11-2018: Pencabutan dan rotasi untuk semua token yang mungkin terpengaruh selesai. Tidak diperlukan tindakan lebih lanjut.

Google baru-baru ini menemukan plugin Calico Container Network Interface (CNI) yang, dalam konfigurasi tertentu, dapat membuat log informasi sensitif. Masalah ini terlacak di dalam Tigera Technical Advisory TTA-2018-001.

  • Saat berjalan dengan logging level debug, plugin Calico CNI akan menulis konfigurasi klien Kubernetes API ke dalam log.
  • Calico CNI juga akan menuliskan token Kubernetes API ke log di level info jika kolom "k8s_auth_token" ditetapkan pada konfigurasi jaringan CNI.
  • Selain itu, saat berjalan dengan logging level debug, jika token akun layanan ditetapkan secara eksplisit, baik dalam file konfigurasi Calico yang dibaca oleh Calico, atau sebagai variabel lingkungan yang digunakan oleh Calico, komponen Calico (calico/node, felix, CNI) akan menulis informasi ini ke file log.

Token-token tersebut memiliki izin sebagai berikut: 

bgpconfigurations.crd.projectcalico.org     [create get list update watch]
bgppeers.crd.projectcalico.org              [create get list update watch]
clusterinformations.crd.projectcalico.org   [create get list update watch]
felixconfigurations.crd.projectcalico.org   [create get list update watch]
globalbgpconfigs.crd.projectcalico.org      [create get list update watch]
globalfelixconfigs.crd.projectcalico.org    [create get list update watch]
globalnetworkpolicies.crd.projectcalico.org [create get list update watch]
globalnetworksets.crd.projectcalico.org     [create get list update watch]
hostendpoints.crd.projectcalico.org         [create get list update watch]
ippools.crd.projectcalico.org               [create get list update watch]
networkpolicies.crd.projectcalico.org       [create get list update watch]
nodes                                       [get list update watch]
pods                                        [get list watch patch]
namespaces                                  [get list watch]
networkpolicies.extensions                  [get list watch]
endpoints                                   [get]
services                                    [get]
pods/status                                 [update]
networkpolicies.networking.k8s.io           [watch list]

Kluster Google Kubernetes Engine dengan Kebijakan Jaringan Kluster dan Stackdriver Logging yang aktif mencatat token akun layanan Calico ke Stackdriver. Kerentanan tidak memengaruhi Kluster tanpa Kebijakan Jaringan yang aktif.

Kami menerapkan perbaikan yang dapat memigrasikan plugin Calico CNI hanya untuk melakukan log di level peringatan dan menggunakan akun layanan yang baru. Kode calico yang di-patch akan diterapkan pada rilis yang lebih baru.

Selama seminggu ke depan, kami akan melakukan pencabutan berkelanjutan untuk setiap token yang mungkin terpengaruh. Buletin ini akan diperbarui saat pencabutan selesai. Anda tidak perlu melakukan tindakan lebih lanjut. (Rotasi ini diselesaikan pada 16-11-2018)

Jika ingin segera merotasi token ini, silakan jalankan perintah berikut. Rahasia baru untuk akun layanan akan dibuat ulang secara otomatis dalam beberapa detik. 

kubectl get sa --namespace kube-system calico -o template --template '{{(index .secrets 0).name}}' | xargs kubectl delete secret --namespace kube-system

Deteksi

GKE mencatat semua akses ke server API. Untuk menentukan apakah token Calico digunakan dari luar rentang IP yang diperkirakan Google Cloud, Anda dapat menjalankan kueri Stackdriver berikut. Perlu diingat bahwa kueri ini hanya akan menampilkan record untuk panggilan yang dilakukan dari luar jaringan GCP. Sebaiknya sesuaikan dengan kebutuhan untuk lingkungan yang spesifik. 

resource.type="k8s_cluster"
protoPayload.authenticationInfo.principalEmail="system:serviceaccount:kube-system:calico"
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.34.208.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.192.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.200.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.59.80.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.208.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.216.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.220.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.222.0/24")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.224.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.216.148.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.222.176.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "173.255.112.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "192.158.28.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.192.112.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.232.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.236.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.236.48.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.251.128.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.204.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.208.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.167.160.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.178.192.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.2.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.240.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.128.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.154.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.196.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "208.68.108.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.184.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.188.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.202.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.192.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.196.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.198.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.200.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "2600:1900::/35")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.232.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.234.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.236.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.240.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.232.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.220.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.242.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.244.0.0/14")

14 Agustus 2018

Deskripsi Keparahan Catatan

Intel telah mengungkapkan CVE berikut:

CVE tersebut secara keseluruhan disebut sebagai "L1 Terminal Fault (L1TF)".

Kerentanan L1TF ini mengeksploitasi eksekusi spekulatif dengan menyerang konfigurasi struktur data tingkat prosesor. "L1" merujuk pada cache Data Level-1 (L1D), resource kecil pada inti yang digunakan untuk mempercepat akses memori.

Baca entri blog Google Cloud untuk mengetahui detail selengkapnya tentang kerentanan dan mitigasi Compute Engine ini.

Dampak Google Kubernetes Engine

Infrastruktur yang menjalankan Kubernetes Engine dan mengisolasi Kluster dan Node pelanggan dari satu sama lain dilindungi dari serangan yang diketahui.

Kumpulan node Kubernetes Engine dengan Container-Optimized OS image Google dan dengan konfigurasi upgrade otomatis yang aktif, akan secara otomatis diperbarui menjadi versi COS image yang di-patch karena versi ini tersedia mulai minggu 20-08-0218.

Kumpulan node Kubernetes Engine dengan konfigurasi upgrade otomatis yang belum diaktifkan harus di-upgrade secara manual saat tersedianya versi COS image yang di-patch tersedia.

Tinggi

6 Agustus 2018; terakhir diperbarui: 5 September 2018

Deskripsi Keparahan Catatan

Update 05-09-2018

Baru-baru ini terungkap adanya kerentanan CVE-2018-5391. Serupa dengan CVE-2018-5390, kerentanan ini merupakan kerentanan jaringan tingkat kernel yang meningkatkan efektivitas serangan Denial of Service (DoS) terhadap sistem yang rentan. Perbedaan utamanya adalah bahwa CVE-2018-5391 dapat dieksploitasi melalui koneksi IP. Kami memperbarui buletin ini untuk mencakup kedua kerentanan ini.

Deskripsi

CVE-2018-5390 ("SegmentSmack") merupakan kerentanan jaringan tingkat kernel yang meningkatkan efektivitas serangan Denial of Service (DoS) terhadap sistem yang rentan melalui koneksi TCP.

CVE-2018-5391 ("FragmentSmack") merupakan kerentanan jaringan tingkat kernel yang meningkatkan efektivitas serangan Denial of Service (DoS) terhadap sistem yang rentan melalui koneksi IP.

Dampak Google Kubernetes Engine

Mulai 11-08-2018, semua master Kubernetes Engine dilindungi dari kedua kerentanan tersebut. Selain itu, semua kluster Kubernetes Engine dengan konfigurasi upgrade otomatis juga dilindungi dari kedua kerentanan. Kumpulan node Kubernetes Engine yang tidak dikonfigurasi untuk mengupgrade otomatis dan terakhir di-upgrade secara manual sebelum 11-08-2018, terpengaruh oleh kedua kerentanan.

Versi yang di-patch

Karena keparahan kerentanan ini, kami sarankan untuk mengupgrade node secara manual segera setelah patch tersedia.

Tinggi

30 Mei 2018

Deskripsi Keparahan Catatan

Baru-baru ini ditemukan kerentanan di Git yang dapat mengizinkan eskalasi hak istimewa dalam Kubernetes jika pengguna yang tidak memiliki hak istimewa diizinkan untuk membuat Pod dengan volume gitRepo. CVE teridentifikasi dengan tag CVE-2018-11235.

Apakah saya terpengaruh?

Kerentanan akan memengaruhi Anda jika hal-hal berikut ini terjadi:

  • Pengguna tidak tepercaya dapat membuat Pod (atau memicu pembuatan Pod).
  • Pod yang dibuat oleh pengguna tidak tepercaya memiliki batasan yang mencegah akses root host (misalnya, melalui PodSecurityPolicy).
  • Pod yang dibuat oleh pengguna tidak tepercaya diizinkan menggunakan jenis volume gitRepo.

Kerentanan ini memengaruhi semua Kubernetes Engine yang rentan.

Apa yang harus saya lakukan?

Larang penggunaan jenis volume gitRepo. Untuk melarang volume gitRepo dengan PodSecurityPolicy, hapus gitRepo dari daftar yang diizinkan volumes di PodSecurityPolicy.

Perilaku volume gitRepo yang setara dapat dicapai dengan menggandakan repositori git ke volume EmptyDir dari initContainer: 

apiVersion: v1
kind: Pod
metadata:
  name: git-repo-example
spec:
  initContainers:
    # This container clones the desired git repo to the EmptyDir volume.
    - name: git-clone
      image: alpine/git # Any image with git will do
      args:
        - clone
        - --single-branch
        - --
        - https://github.com/kubernetes/kubernetes # Your repo
        - /repo # Put it in the volume
      securityContext:
        runAsUser: 1 # Any non-root user will do. Match to the workload.
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  containers:
    ...
  volumes:
    - name: git-repo
      emptyDir: {}

Patch apa yang dapat mengatasi kerentanan ini?

Patch akan disertakan dalam rilis Kubernetes Engine berikutnya. Periksa kembali di sini untuk mengetahui detail selengkapnya.

Sedang

21 Mei 2018

Deskripsi Keparahan Catatan

Baru-baru ini ditemukan beberapa kerentanan di kernel Linux yang dapat mengizinkan eskalasi hak istimewa atau Denial of Service (melalui crash kernel) dari proses yang tidak memiliki hak istimewa. Beberapa CVE ini teridentifikasi dengan tag CVE-2018-1000199, CVE-2018-8897, dan CVE-2018-1087. Semua node Kubernetes Engine terpengaruh oleh kerentanan ini, dan kami sarankan untuk mengupgrade ke versi patch terbaru, seperti dijelaskan di bawah ini.

Apa yang harus saya lakukan?

Agar dapat mengupgrade, pertama-tama upgrade master ke versi terbaru. Patch ini tersedia dalam Kubernetes Engine 1.8.12-gke.1, Kubernetes Engine 1.9.7-gke.1, dan Kubernetes Engine 1.10.2-gke.1. Rilis ini mencakup Container-Optimized OS dan Ubuntu image.

Jika sebelumnya telah membuat kluster baru, Anda harus menetapkan versi yang di-patch agar kluster dapat digunakan. Pelanggan dengan konfigurasi upgrade node otomatis yang aktif dan pelanggan yang tidak meng-upgrade secara manual, node-nya akan diupgrade menjadi versi yang di-patch dalam beberapa minggu mendatang.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

CVE-2018-1000199: Kerentanan ini memengaruhi kernel Linux. Kerentanan ini memungkinkan pengguna atau proses yang tidak memiliki hak istimewa menyebabkan eror pada sistem kernel, yang mengarah ke serangan DoS atau eskalasi akses. Kerentanan ini dinilai sebagai kerentanan Tinggi dengan CVSS sebesar 7,8.

CVE-2018-8897: Kerentanan ini memengaruhi kernel Linux. Kerentanan ini mengizinkan pengguna atau proses yang tidak memiliki hak istimewa menyebabkan eror pada sistem kernel dan mengarah ke serangan DoS. Kerentanan ini dinilai sebagai kerentanan Sedang, dengan CVSS sebesar 6,5.

CVE-2018-1087: Kerentanan ini memengaruhi hypervisor KVM kernel Linux. Kerentanan ini mengizinkan proses yang tidak memiliki hak istimewa menyebabkan error pada kernel tamu atau untuk mendapatkan hak istimewa. Kerentanan ini di-patch di dalam infrastruktur tempat dijalankannya Kubernetes Engine, sehingga Kubernetes Engine tidak terpengaruh. Kerentanan ini dinilai sebagai kerentanan Tinggi, dengan skor CVSS seebsar 8,0.

Tinggi

12 Maret 2018

Deskripsi Keparahan Catatan

Project Kubernetes baru-baru ini mengungkap kerentanan keamanan baru, CVE-2017-1002101 dan CVE-2017-1002102 yang mengizinkan container mengakses file dari luar container. Kerentanan ini memengaruhi semua node Kubernetes Engine. Kami sarankan untuk mengupgrade ke versi patch terbaru secepatnya, seperti dijelaskan di bawah ini:

Apa yang harus saya lakukan?

Baik upgrade node otomatis telah diaktifkan atau belum, karena keparahan kerentanan ini, kami sarankan untuk mengupgrade node secara manual segera setelah patch tersedia. Patch akan tersedia untuk semua pelanggan pada 16 Maret, tetapi dapat tersedia lebih cepat berdasarkan zona kluster Anda, sesuai dengan jadwal rilis.

Agar dapat mengupgrade, pertama-tama upgrade master ke versi terbaru. Patch ini tersedia dalam Kubernetes Engine 1.9.4-gke.1, Kubernetes 1.8.9-gke.1, dan Kubernetes 1.7.14-gke.1. Kluster baru akan menggunakan versi yang di-patch secara default pada 30 Maret, jika sebelumnya Anda telah membuat kluster baru, tetapkan versi yang di-patch agar kluster dapat digunakan.

Pelanggan Kubernetes Engine yang telah mengaktifkan konfigurasi upgrade node otomatis dan yang tidak mengupgrade secara manual, node-nya akan di-upgrade menjadi versi yang di-patch pada 23 April. Namun, karena sifat kerentanan, kami menganjurkan agar Anda mengupgrade node secara manual segera setelah patch tersedia.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch mengurangi dua kerentanan berikut:

Kerentanan CVE-2017-1002101 mengizinkan container menggunakan pemasangan volume sublokasi guna mengakses file di luar volume. Artinya, jika Anda memblokir akses container ke volume hostpath dengan PodSecurityPolicy, penyerang dengan kemampuan memperbarui atau membuat pod dapat memasang hostpath apa pun menggunakan jenis volume lainnya.

Kerentanan CVE-2017-1002102 mengizinkan container menggunakan jenis volume tertentu - termasuk rahasia, config map, volume terproyeksi, atau volume downward API - untuk menghapus file di luar volume. Artinya, jika container yang menggunakan salah satu jenis volume ini disusupi atau jika Anda mengizinkan pengguna tidak tepercaya untuk membuat pod, penyerang dapat menggunakan container tersebut untuk menghapus file arbitrer di host.

Untuk mempelajari selengkapnya tentang perbaikan, baca entri blog Kubernetes.

Tinggi

Buletin keamanan Google Distributed Cloud

16 Oktober 2019

Deskripsi Keparahan Catatan

Baru-baru ini ditemukan kerentanan di Kubernetes, yang dijelaskan dalam CVE-2019-11253, yang memungkinkan pengguna yang diberi otorisasi untuk membuat permintaan POST mengeksekusi serangan Denial of Service jarak jauh di server Kubernetes API. Kubernetes Product Security Committee (PSC) merilis informasi tambahan tentang kerentanan ini yang dapat ditemukan di sini.

Anda dapat mengurangi kerentanan ini dengan membatasi klien mana yang memiliki akses jaringan ke server Kubernetes API Anda.

Apa yang harus saya lakukan?

Sebaiknya upgrade cluster ke versi patch yang berisi perbaikan segera setelah tersedia.

Versi patch yang akan berisi perbaikan tercantum di bawah ini:

  • GKE Enterprise 1.1.1, yang menjalankan Kubernetes versi 1.13.7-gke.30
Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi kerentanan berikut: CVE-2019-11253.

Tinggi

CVE-2019-11253

23 Agustus 2019

Deskripsi Keparahan Catatan

Baru-baru ini kami menemukan dan memitigasi kerentanan saat proxy RBAC yang digunakan untuk mengamankan endpoint pemantauan tidak memberikan otorisasi kepada pengguna dengan benar. Akibatnya, metrik dari komponen tertentu tersedia untuk pengguna yang tidak diberi otorisasi dari dalam jaringan cluster internal. Komponen berikut terpengaruh:

  • etcd
  • etcd-events
  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler
  • node-exporter
  • kube-state-metrics
  • prometheus
  • alertmanager
Apa yang harus saya lakukan?

Sebaiknya Anda mengupgrade cluster ke versi 1.0.2-gke.3, yang menyertakan patch untuk kerentanan ini, sesegera mungkin.

Sedang

Rilis Google Distributed Cloud

22 Agustus 2019

Deskripsi Keparahan Catatan

Kubernetes baru-baru ini menemukan kerentanan, CVE-2019-11247, yang memungkinkan instance resource kustom cakupan cluster ditindaklanjuti seolah-olah objek tersebut adalah objek dengan namespace yang ada di semua Namespace. Artinya, akun pengguna dan layanan yang hanya memiliki izin RBAC tingkat namespace dapat berinteraksi dengan resource kustom cakupan cluster. Untuk mengeksploitasi kerentanan ini, penyerang harus memiliki hak istimewa untuk mengakses resource di namespace mana pun.

Apa yang harus saya lakukan?

Sebaiknya Anda mengupgrade cluster ke versi 1.0.2-gke.3, yang menyertakan patch untuk kerentanan ini, sesegera mungkin.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi kerentanan berikut: CVE-2019-11247.

Sedang

CVE-2019-11247