Arsip buletin keamanan

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

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

Kerentanan apa yang dapat diatasi oleh patch ini?
CVE-2019-11255: CVE ini merupakan kerentanan dalam file bantuan kubernetes-csi external-provisioner, external-snapshotter dan external-resizer yang dapat mengizinkan akses atau mutasi data volume tanpa izin. Hal ini memengaruhi sebagian besar versi file bantuan yang dipaketkan dalam driver CSI.

Sedang

CVE-2019-11255

Intel telah mengungkapkan CVE yang berpotensi mengizinkan interaksi antara eksekusi spekulatif dan status mikroarsitektur untuk mengekspos data. Untuk detail lebih lanjut, lihat Pengungkapan Intel.

Infrastruktur host yang menjalankan Kubernetes Engine mengisolasi workload pelanggan. Anda tidak perlu melakukan tindakan lebih lanjut, kecuali Anda menjalankan kode yang tidak tepercaya di dalam cluster GKE multi-tenant Anda sendiri dan menggunakan node N2, M2, atau C2. Untuk instance GKE pada node N1, Anda tidak perlu melakukan tindakan baru apa pun.

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

Apa yang harus saya lakukan?

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

Memulai ulang node akan menerapkan patch. Cara termudah untuk memulai ulang semua node di kumpulan node Anda adalah menggunakan operasi upgrade untuk memaksa mulai ulang di semua kumpulan node 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 pemindahan data yang tidak sah menggunakan struktur data mikroarsitektur yang sama yang dieksploitasi oleh Pengambilan Sampel Data Microarchitectural (MDS).

CVE-2018-12207 Ini adalah kerentanan Denial of Service (DoS) yang memengaruhi host virtual machine yang memungkinkan tamu berbahaya membuat error pada host yang tidak dilindungi. CVE ini juga dikenal sebagai "Error Mesin Pemeriksaan saat Perubahan Ukuran Halaman". Hal ini tidak memengaruhi GKE.

Sedang

CVE-2019-11135
CVE-2018-12207

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

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

Tidak ada

CVE-2019-16276

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

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

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

Apa yang harus saya lakukan?

Sebaiknya upgrade cluster Anda ke versi patch yang berisi perbaikan segera setelah tersedia. Kami berharap aplikasi tersebut tersedia di semua zona dan rilis GKE direncanakan pada pekan 14 Oktober.

Versi patch yang akan berisi mitigasi tercantum di bawah ini:

• 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

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). Pada GKE, hal ini dapat memungkinkan pengguna membuat permintaan berbahaya yang mengonsumsi 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 Anda mengupgrade cluster ke versi patch terbaru, yang berisi mitigasi untuk kerentanan ini, segera setelah tersedia. Kami berharap aplikasi tersebut tersedia di semua zona pada rilis GKE berikutnya, sesuai dengan jadwal rilis.

Versi patch yang akan berisi mitigasi tercantum di bawah ini:

• 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

Buletin ini telah diperbarui sejak publikasi aslinya.

Baru-baru ini Kubernetes menemukan kerentanan, CVE-2019-11247, yang memungkinkan instance resource kustom dengan cakupan cluster untuk ditindaklanjuti seolah-olah instance 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 memanfaatkan kerentanan ini, penyerang harus memiliki hak istimewa untuk mengakses resource di namespace apa pun.

Apa yang harus saya lakukan?

Sebaiknya Anda mengupgrade cluster ke versi patch terbaru, yang berisi mitigasi untuk kerentanan ini, segera setelah tersedia. Kami berharap layanan tersebut tersedia di semua zona pada rilis GKE berikutnya. Versi patch yang akan berisi mitigasi tercantum di bawah ini:

• 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

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

Catatan: Patch tidak tersedia di kubectl 1.11.10.

Tinggi

CVE-2019-11246

Update 3 Juli 2019

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

Untuk 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 tidak akan digunakan lagi dalam waktu dekat dan dijadwalkan untuk diupgrade secara otomatis ke versi 1.12 pada pekan tanggal 8 Juli 2019. Anda dapat memilih salah satu tindakan yang disarankan berikut untuk memindahkan 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 1.11 node dan izinkan node tersebut di-upgrade saat master diupgrade ke versi 1.12.
• Upgrade secara manual master dan node ke versi 1.12 yang tetap.

Buletin asli dari 24 Juni 2019 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 Anda mengaktifkan upgrade otomatis node atau tidak, sebaiknya upgrade secara manual node dan master ke salah satu versi tersebut sesegera mungkin.

Versi yang di-patch:

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

Buletin asli dari 18 Juni 2019 sebagai berikut:

Netflix baru-baru ini mengungkapkan tiga kerentanan TCP di {i>kernel<i} Linux:

• CVE-2019-11477
• CVE-2019-11478
• CVE-2019-11479

CVE ini secara kolektif 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. Anda tidak perlu melakukan tindakan apa pun dari pelanggan.

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 Layanan 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 ke semua pelanggan GKE saat perbaikan permanen telah tersedia.

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

Apa yang harus saya lakukan?

Terapkan DaemonSet Kubernetes ke semua node di cluster Anda dengan menjalankan perintah berikut. Tindakan ini menambahkan aturan iptables ke aturan iptables yang ada pada 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
      

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

Catatan: Patch tidak tersedia di versi 1.11.10.

Kubernetes baru-baru ini menemukan kerentanan, CVE-2019-11246, yang memungkinkan penyerang memiliki akses ke operasi kubectl cp dan eksekusi kode di dalam container untuk mengubah file di host. Eksploit ini berpotensi memungkinkan penyerang mengganti atau membuat file dalam sistem file host. Untuk mengetahui detail selengkapnya, baca 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 container untuk mengubah file di host. Eksploit ini berpotensi memungkinkan penyerang untuk mengganti atau membuat file di sistem file {i>host<i}

Tinggi

CVE-2019-11246

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

Kerentanan ini memengaruhi semua node Google Kubernetes Engine (GKE) yang menjalankan Docker. Oleh karena itu, Anda sebaiknya 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 pada 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 akan cukup tidak biasa di lingkungan Kubernetes. Node yang menjalankan COS dengan containerd tidak terpengaruh.

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

Kami akan otomatis mengupgrade master cluster ke versi yang di-patch, 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 container untuk membajak operasi docker cp yang dimulai secara eksternal. Eksploit ini berpotensi memungkinkan penyerang mengubah tempat file ditulis, ke lokasi arbitrer dalam sistem file host.

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 terkena dampak. Karena regresi, semua versi 1.13.6.x kini terpengaruh. Jika Anda menjalankan versi 1.13.6, upgrade ke versi 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 dijalankan sebagai UID 0 (biasanya dipetakan ke pengguna root), meskipun pengguna lain ditentukan dalam image container. Jika container Anda dijalankan sebagai pengguna non-root dan Anda menjalankan node versi 1.13.6-gke.0 hingga 1.13.6-gke.6, sebaiknya tetapkan RunAsUser pada semua Pod dalam cluster yang container-nya tidak boleh berjalan sebagai UID 0.

Jika nilai USER non-root ditentukan (misalnya dengan menetapkan nilai USER di Dockerfile), perilaku yang tidak terduga akan terjadi. Saat dijalankan untuk pertama kalinya di node, container mengikuti UID yang ditentukan dengan benar. Namun, karena kerusakan ini, pada proses kedua (dan operasi berikutnya), container berjalan sebagai UID 0, terlepas dari UID yang ditentukan. Hal ini biasanya merupakan hak istimewa yang tidak diinginkan yang dieskalasi, 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 kubeletnya:

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 khusus saya terpengaruh?

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

• Pod yang menentukan nilai non-root yang valid untuk PodSecurityContext runAsUser tidak akan terpengaruh dan terus berfungsi seperti yang diharapkan.
• PodSecurityPolicies yang menerapkan setelan runAsUser juga tidak akan 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 RunAsUser Security Context pada semua Pod di cluster yang tidak boleh dijalankan sebagai UID 0. Anda dapat menerapkan konfigurasi ini menggunakan PodSecurityPolicy.

Update 11-06-2019: Patch ini tersedia dalam rilis 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-2018-12126
• CVE-2018-12127
• CVE-2018-12130
• CVE-2019-11091

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

Infrastruktur host yang menjalankan Kubernetes Engine mengisolasi workload pelanggan satu sama lain. Anda tidak akan terpengaruh, kecuali Anda menjalankan kode yang tidak tepercaya di dalam cluster GKE multi-tenant Anda sendiri.

Untuk pelanggan yang menjalankan kode tidak tepercaya pada layanan multi-tenant mereka sendiri di dalam Kubernetes Engine, hal ini merupakan kerentanan yang sangat parah. Untuk memitigasinya di Kubernetes Engine, nonaktifkan Hyper-Threading di node Anda. Kerentanan ini hanya terdampak oleh node Google Kubernetes Engine (GKE) yang menggunakan banyak CPU. Perlu diperhatikan bahwa VM n1-standard-1 (default GKE), g1-small, dan f1-micro hanya mengekspos 1 vCPU ke lingkungan tamu sehingga Anda tidak perlu menonaktifkan Hyper-Threading.

Perlindungan tambahan untuk mengaktifkan fungsi flush akan disertakan dalam versi patch mendatang. Kami akan otomatis 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 secara lokal, Anda mungkin terpengaruh, bergantung pada hardware yang Anda gunakan. Harap lihat 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 kumpulan node baru dengan menonaktifkan Hyper-Threading, lalu jadwalkan ulang workload Anda ke node baru.

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

Untuk membuat kumpulan node baru dengan Hyper-Threading dinonaktifkan:

1. Buat kumpulan node 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 pada 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 dalam status berjalan.

   kubectl get pods --selector=name=disable-smt -n kube-system

   Anda akan mendapatkan respons yang serupa dengan:

   NAME                READY     STATUS    RESTARTS   AGE
   
   disable-smt-2xnnc   1/1       Running   0          6m

4. Pastikan bahwa pesan "SMT telah dinonaktifkan" muncul di log pod.

   kubectl logs disable-smt-2xnnc disable-smt -n kube-system

Anda harus menjaga DaemonSet tetap berjalan di kumpulan node sehingga node baru yang dibuat dalam kumpulan akan menerapkan perubahan secara otomatis. Pembuatan node dapat dipicu oleh perbaikan otomatis node, upgrade manual atau otomatis, dan penskalaan otomatis.

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

Sebaiknya Anda juga mengupgrade node secara manual setelah patch tersedia. Untuk melakukan upgrade, Anda harus terlebih dahulu mengupgrade master ke versi terbaru. Master GKE akan otomatis di-upgrade dengan ritme upgrade reguler.

Kami akan memperbarui buletin ini dengan versi yang berisi tambalan 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-2018-11091

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

Istio menyematkan Envoy, dan kerentanan ini memungkinkan kebijakan Istio diabaikan 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 secepatnya, dan upgrade file bantuan Istio (petunjuk di bawah).

Apa yang harus saya lakukan?

Karena keparahan kerentanan ini, baik Anda mengaktifkan upgrade otomatis node atau tidak, sebaiknya Anda:

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

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

Patch ini akan tersedia pada versi GKE di bawah. Secara default, cluster baru akan menggunakan versi yang di-patch saat diumumkan di halaman buletin keamanan GKE, yang diperkirakan pada 15 April 2019. Jika sebelum itu, Anda harus menentukan versi yang di-patch untuk digunakan. Pelanggan GKE yang mengaktifkan upgrade otomatis node dan yang tidak mengupgrade secara manual, node akan diupgrade secara otomatis 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 hal tersebut lebih lanjut di blog Istio.

• CVE-2019-9900
• CVE-2019-9901.

Update 22-03-2019: Patch ini tersedia dalam rilis Kubernetes 1.11.8-gke.4, 1.13.4-gke.1, dan yang lebih baru. Patch 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 guna membuat permintaan "json-patch" berbahaya yang menghabiskan terlalu banyak CPU dan memori di server Kubernetes API, sehingga berpotensi mengurangi ketersediaan bidang kontrol cluster. Untuk mengetahui detail selengkapnya, baca pengungkapan Kubernetes. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh kerentanan ini. Versi patch mendatang akan menyertakan mitigasi untuk kerentanan ini. Kami akan otomatis mengupgrade master cluster ke versi yang di-patch dalam beberapa minggu mendatang, 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 tambalan. Perhatikan bahwa patch hanya akan tersedia dalam versi 1.11+, tidak juga dalam versi 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 menggunakan terlalu banyak CPU di server Kubernetes API, sehingga berpotensi mengurangi ketersediaan bidang kontrol cluster.

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

Node Ubuntu Google Kubernetes Engine (GKE) Anda terpengaruh oleh kerentanan ini, dan kami menyarankan Anda untuk mengupgrade ke versi patch terbaru sesegera mungkin, seperti yang kami jelaskan 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 versi baru runc telah meningkatkan penggunaan memori dan mungkin memerlukan update memori yang dialokasikan ke container jika Anda telah menetapkan batas memori 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'.

Update 25-02-2019: Patch tidak tersedia di 1.11.7-gke.4 seperti yang telah dikomunikasikan sebelumnya. Jika menjalankan versi 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 menyertakan 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 di-upgrade 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.

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 mengetahui detail selengkapnya, baca pengungkapan Kubernetes. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh kerentanan ini, dan kami telah mengupgrade cluster 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 memberikan otorisasi kepada pengguna untuk membuat permintaan yang dapat diupgrade guna mengeskalasi dan melakukan 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.

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 dijalankan dengan logging tingkat debug, plugin Calico CNI akan menulis konfigurasi klien Kubernetes API ke dalam log.
• Calico CNI juga akan menulis token Kubernetes API ke log pada level info jika kolom "k8s_auth_token" ditetapkan pada konfigurasi jaringan CNI.
• Selain itu, saat menjalankan logging tingkat debug, jika token akun layanan ditetapkan secara eksplisit, baik dalam file konfigurasi Calico yang dibaca oleh Calico, atau sebagai variabel lingkungan yang digunakan 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]
      

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")
      

Intel telah mengungkapkan CVE berikut:

• CVE-2018-3615 (untuk SGX)
• CVE-2018-3620 (untuk sistem operasi dan SMT)
• CVE-2018-3646 (untuk virtualisasi)

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 yang tidak mengaktifkan upgrade otomatis harus di-upgrade secara manual seiring tersedianya versi COS image yang di-patch tersedia.

• CVE-2018-3615
• CVE-2018-3620
• CVE-2018-3646

Update 05-09-2018

Baru-baru ini terungkap adanya kerentanan CVE-2018-5391. Seperti halnya 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.

• CVE-2018-5390
• CVE-2018-5391

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.

• CVE-2018-11235

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. CVE ini diidentifikasi 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 yang 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.

• CVE-2018-1000199
• CVE-2018-8897
• CVE-2018-1087

Project Kubernetes baru-baru ini mengungkapkan kerentanan keamanan baru, CVE-2017-1002101 dan CVE-2017-1002102, yang mengizinkan container mengakses file di 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 mungkin tersedia lebih cepat berdasarkan zona cluster 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 menyarankan Anda untuk 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.

• CVE-2017-1002101
• CVE-2017-1002102

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

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

Apa yang harus saya lakukan?

Sebaiknya upgrade cluster Anda 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

Baru-baru ini kami menemukan dan mengurangi kerentanan ketika proxy RBAC yang digunakan untuk mengamankan endpoint pemantauan tidak mengizinkan pengguna dengan benar. Akibatnya, metrik dari komponen tertentu tersedia bagi pengguna yang tidak berwenang 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

Baru-baru ini Kubernetes menemukan kerentanan, CVE-2019-11247, yang memungkinkan instance resource kustom dengan cakupan cluster untuk ditindaklanjuti seolah-olah instance 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 memanfaatkan kerentanan ini, penyerang harus memiliki hak istimewa untuk mengakses resource di namespace apa 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