Halaman ini diterjemahkan oleh Cloud Translation API.

Arsip buletin keamanan

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

Google Kubernetes Engine (GKE)
Google Distributed Cloud

Untuk melihat buletin keamanan terbaru, lihat Buletin keamanan kami.

Buletin keamanan GKE

14 November 2019

Dipublikasikan: 14-11-2019
Diperbarui: 14-11-2019

Deskripsi Keparahan Catatan

Deskripsi	Keparahan	Catatan
Kubernetes telah mengungkapkan masalah keamanan di file kubernetes-csi `external-provisioner`, `external-snapshotter`, dan `external-resizer` file bantuan yang memengaruhi sebagian besar versi file bantuan yang dipaketkan dalam Penyimpanan Container Driver antarmuka (CSI). Untuk mengetahui detail selengkapnya, lihat Pengungkapan Kubernetes. Apa yang sebaiknya saya lakukan? Kerentanan ini tidak memengaruhi komponen GKE terkelola apa pun. Anda mungkin akan terpengaruh jika mengelola pengemudi CSI Anda sendiri di GKE Cluster alfa yang menjalankan GKE versi 1.12 atau yang lebih baru. Jika Anda terpengaruh, hubungi vendor driver CSI Anda untuk mendapatkan petunjuk upgrade. Kerentanan apa yang dapat diatasi oleh patch ini? CVE-2019-11255: CVE ini adalah kerentanan di `kubernetes-csi` `external-provisioner`, `external-snapshotter`, dan `external-resizer` file bantuan yang dapat memungkinkan akses atau mutasi data volume tanpa izin. Ini memengaruhi sebagian besar versi sespan yang dipaketkan dalam Driver CSI.	Sedang	CVE-2019-11255

Kubernetes telah mengungkapkan masalah keamanan di file kubernetes-csi external-provisioner, external-snapshotter, dan external-resizer file bantuan yang memengaruhi sebagian besar versi file bantuan yang dipaketkan dalam Penyimpanan Container Driver antarmuka (CSI). Untuk mengetahui detail selengkapnya, lihat Pengungkapan Kubernetes.

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

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

Sedang

CVE-2019-11255

12 November 2019

Dipublikasikan: 12-11-2019
Diperbarui: 12-11-2019

Deskripsi Keparahan Catatan

Deskripsi	Keparahan	Catatan
Intel telah mengungkapkan CVE yang berpotensi mengizinkan interaksi antar-layanan spekulatif dan keadaan mikroarsitektur untuk mengekspos data. Untuk detail lebih lanjut, lihat Intel pengungkapan. Infrastruktur host yang menjalankan Kubernetes Engine mengisolasi workload pelanggan. Kecuali Anda menjalankan kode tidak tepercaya di dalam milik Anda sendiri cluster GKE multi-tenant dan menggunakan node N2, M2, atau C2, tidak perlu tindakan diperlukan. Untuk instance GKE pada node N1, tidak ada tindakan baru tidak diperlukan. Jika Anda menjalankan Google Distributed Cloud, eksposur bergantung pada hardware. Memohon membandingkan infrastruktur Anda dengan Intel pengungkapan. Apa yang harus saya lakukan? *Anda hanya akan terpengaruh jika menggunakan kumpulan node dengan N2, M2, atau C2 dan* node tersebut menjalankan kode tidak tepercaya di dalam multi-tenant Anda GKE cluster. Memulai ulang node akan menerapkan patch.** Cara termudah untuk memulai ulang semua node dalam kumpulan node Anda adalah menggunakan upgrade untuk memaksa memulai ulang di semua kumpulan node yang terpengaruh. Catatan: Anda tidak perlu mengubah versi selama proses upgrade. Anda dapat mulai upgrade ke versi node yang sama dengan flag `cluster-version`. 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 jalan lain untuk pemindahan data yang tidak sah menggunakan struktur data mikroarsitektur yang sama dieksploitasi oleh Pengambilan Sampel Data Mikroarsitektur (MDS). CVE-2018-12207 Ini adalah kerentanan {i>Denial of Service<i} (DoS) yang memengaruhi mesin virtual yang memungkinkan tamu berbahaya untuk merusak {i>host<i} yang tidak dilindungi. CVE ini dikenal sebagai "Error Mesin Pemeriksaan pada Perubahan Ukuran Halaman." Hal ini dapat tidak memengaruhi GKE.	Sedang	CVE-2019-11135 CVE-2018-12207

Intel telah mengungkapkan CVE yang berpotensi mengizinkan interaksi antar-layanan spekulatif dan keadaan mikroarsitektur untuk mengekspos data. Untuk detail lebih lanjut, lihat Intel pengungkapan.

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

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

Apa yang harus saya lakukan?

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

Memulai ulang node akan menerapkan patch. Cara termudah untuk memulai ulang semua node dalam kumpulan node Anda adalah menggunakan upgrade untuk memaksa memulai ulang di semua kumpulan node yang terpengaruh.

Catatan: Anda tidak perlu mengubah versi selama proses upgrade. Anda dapat mulai upgrade ke versi node yang sama dengan flag cluster-version.

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 jalan lain untuk pemindahan data yang tidak sah menggunakan struktur data mikroarsitektur yang sama dieksploitasi oleh Pengambilan Sampel Data Mikroarsitektur (MDS).

CVE-2018-12207 Ini adalah kerentanan {i>Denial of Service<i} (DoS) yang memengaruhi mesin virtual yang memungkinkan tamu berbahaya untuk merusak {i>host<i} yang tidak dilindungi. CVE ini dikenal sebagai "Error Mesin Pemeriksaan pada Perubahan Ukuran Halaman." Hal ini dapat tidak memengaruhi GKE.

Sedang

CVE-2019-11135
CVE-2018-12207

22 Oktober 2019

Dipublikasikan: 22-10-2019
Diperbarui: 22-10-2019

Deskripsi	Keparahan	Catatan
Sebuah kerentanan baru-baru ini ditemukan dalam bahasa pemrograman Go, dijelaskan dalam CVE-2019-16276. Kerentanan ini berpotensi mempengaruhi konfigurasi Kubernetes menggunakan Proxy Autentikasi. Untuk mengetahui detail selengkapnya, lihat Pengungkapan Kubernetes. Kubernetes Engine tidak mengizinkan konfigurasi Proxy Autentikasi, sehingga yang terdampak oleh kerentanan ini.	Tidak ada	CVE-2019-16276

Deskripsi

Keparahan

Catatan

Sebuah kerentanan baru-baru ini ditemukan dalam bahasa pemrograman Go, dijelaskan dalam CVE-2019-16276. Kerentanan ini berpotensi mempengaruhi konfigurasi Kubernetes menggunakan Proxy Autentikasi. Untuk mengetahui detail selengkapnya, lihat Pengungkapan Kubernetes.

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

Tidak ada

CVE-2019-16276

16 Oktober 2019

Dipublikasikan: 16-10-2019
Diperbarui: 24-10-2019

Deskripsi	Keparahan	Catatan
Update 24-10-2019: Versi yang di-patch kini tersedia di semua zona. Baru-baru ini, kerentanan ditemukan di Kubernetes, CVE-2019-11253, yang memungkinkan setiap pengguna yang berwenang untuk membuat permintaan POST untuk mengeksekusi serangan Denial-of-Service jarak jauh pada server Kubernetes API. Tujuan Product Security Committee (PSC) Kubernetes merilis informasi tentang kerentanan ini yang dapat ditemukan di sini. Cluster GKE yang menggunakan Jaringan yang Diizinkan Master dan Cluster pribadi tanpa endpoint publik memitigasi kerentanan ini. Apa yang harus saya lakukan? Sebaiknya upgrade cluster Anda ke versi patch yang berisi perbaikan segera setelah tersedia. Kami berharap tersedia dalam semua zona dengan rilis GKE yang direncanakan pada minggu 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

Deskripsi

Keparahan

Catatan

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

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

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

Apa yang harus saya lakukan?

Sebaiknya upgrade cluster Anda ke versi patch yang berisi perbaikan segera setelah tersedia. Kami berharap tersedia dalam semua zona dengan rilis GKE yang direncanakan pada minggu 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

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 keamanan baru kerentanan CVE-2019-9512 dan CVE-2019-9514, yaitu kerentanan {i>Denial of Service<i} (DoS). Di GKE, hal ini memungkinkan pengguna membuat permintaan jahat yang mengonsumsi terlalu banyak CPU di server Kubernetes API, mengurangi ketersediaan bidang kontrol cluster. Untuk selengkapnya selengkapnya, lihat Pengungkapan bahasa pemrograman Go. Apa yang harus saya lakukan? Sebaiknya upgrade cluster Anda ke versi patch terbaru, yang berisi mitigasi terhadap kerentanan ini, segera setelah mereka yang tersedia. Kami berharap fitur tersebut tersedia di semua zona dengan GKE, sesuai dengan jadwal rilis Anda. 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 {i>Denial of Service<i} (DoS).	Tinggi	CVE-2019-9512 CVE-2019-9514

Deskripsi

Keparahan

Catatan

Buletin ini telah diperbarui sejak publikasi aslinya.

Bahasa pemrograman Go baru-baru ini menemukan keamanan baru kerentanan CVE-2019-9512 dan CVE-2019-9514, yaitu kerentanan {i>Denial of Service<i} (DoS). Di GKE, hal ini memungkinkan pengguna membuat permintaan jahat yang mengonsumsi terlalu banyak CPU di server Kubernetes API, mengurangi ketersediaan bidang kontrol cluster. Untuk selengkapnya selengkapnya, lihat Pengungkapan bahasa pemrograman Go.

Apa yang harus saya lakukan?

Sebaiknya upgrade cluster Anda ke versi patch terbaru, yang berisi mitigasi terhadap kerentanan ini, segera setelah mereka yang tersedia. Kami berharap fitur tersebut tersedia di semua zona dengan GKE, sesuai dengan jadwal rilis Anda.

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 {i>Denial of Service<i} (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 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 adalah tersedia.

8 Agustus 2019

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

Buletin untuk 5 Agustus 2019 telah diperbarui. Kami berharap perbaikan untuk kerentanan yang didokumentasikan dalam buletin itu menjadi yang tersedia di 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 sebuah kerentanan, CVE-2019-11247, yang memungkinkan cakupan cluster resource kustom untuk ditindaklanjuti seolah-olah mereka adalah objek dengan namespace yang ada di semua Namespace. Artinya, akun pengguna dan layanan hanya memiliki izin RBAC tingkat namespace dapat berinteraksi dengan kustom cakupan cluster Google Cloud Platform. Eksploitasi kerentanan ini mengharuskan penyerang untuk memiliki hak istimewa untuk mengakses sumber daya dalam namespace apa pun. Apa yang harus saya lakukan? Sebaiknya upgrade cluster Anda ke versi patch terbaru, yang berisi mitigasi untuk kerentanan ini, segera setelah tersedia. Kami berharap mereka menjadi yang tersedia di semua zona dengan rilis GKE berikutnya. Tujuan 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 mengurangi kerentanan berikut: CVE-2019-11247.	Sedang	CVE-2019-11247

Deskripsi

Keparahan

Catatan

Buletin ini telah diperbarui sejak publikasi aslinya.

Kubernetes baru-baru ini menemukan sebuah kerentanan, CVE-2019-11247, yang memungkinkan cakupan cluster resource kustom untuk ditindaklanjuti seolah-olah mereka adalah objek dengan namespace yang ada di semua Namespace. Artinya, akun pengguna dan layanan hanya memiliki izin RBAC tingkat namespace dapat berinteraksi dengan kustom cakupan cluster Google Cloud Platform. Eksploitasi kerentanan ini mengharuskan penyerang untuk memiliki hak istimewa untuk mengakses sumber daya dalam namespace apa pun.

Apa yang harus saya lakukan?

Sebaiknya upgrade cluster Anda ke versi patch terbaru, yang berisi mitigasi untuk kerentanan ini, segera setelah tersedia. Kami berharap mereka menjadi yang tersedia di semua zona dengan rilis GKE berikutnya. Tujuan 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 mengurangi kerentanan berikut: CVE-2019-11247.

Sedang

CVE-2019-11247

3 Juli 2019

Dipublikasikan: 03-07-2019
Diperbarui: 03-07-2019

Deskripsi Keparahan Catatan

Deskripsi	Keparahan	Catatan
Versi `kubectl` yang di-patch untuk mengatasi CVE-2019-11246 kini menjadi 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

Versi kubectl yang di-patch untuk mengatasi CVE-2019-11246 kini menjadi 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

Deskripsi	Keparahan	Catatan
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 upgrade target untuk kedua versi 1.11. Saat ini, master GKE telah di-patch, dan Infrastruktur Google yang menjalankan Kubernetes Engine telah di-patch dan terlindungi dari kerentanan ini. Master 1.11 tidak akan digunakan lagi dalam waktu dekat dan dijadwalkan untuk otomatis meningkatkan ke 1.12 pada minggu 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. Setelahnya tanggal, versi 1.11 akan mulai dihapus dari daftar yang tersedia target upgrade. Aktifkan upgrade otomatis pada 1,11 node dan memungkinkannya untuk di-upgrade ketika {i>master<i} master diupgrade ke versi 1.12. Mengupgrade secara manual baik {i>master<i} maupun {i>node<i} ke versi 1.12 yang telah diperbaiki. Buletin asli dari 24 Juni 2019 sebagai berikut: Update 24 Juni 2019 Pada 22-06-2019 21.40 UTC, kami membuat patch Kubernetes berikut versi yang tersedia. Master antara Kubernetes versi 1.11.0 dan 1.13.6 akan diupdate secara otomatis ke versi yang di-patch. Jika Anda tidak menjalankan versi yang kompatibel dengan patch ini, upgrade ke master yang kompatibel sebelum mengupgrade node Anda. Karena keparahan dari kerentanan ini, upgrade otomatis node diaktifkan atau tidak, sebaiknya secara manual mengupgrade node dan master ke salah satu versi ini sesegera mungkin 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 penolakan yang dipicu dari jarak jauh serangan layanan. Node Google Kubernetes Engine yang mengirim atau menerima lalu lintas jaringan yang tidak tepercaya terpengaruh, dan sebaiknya Anda mengikuti langkah-langkah mitigasi di bawah ini untuk melindungi workload Anda. Master Kubernetes Master Kubernetes menggunakan Jaringan yang Diizinkan membatasi lalu lintas data ke jaringan tepercaya tidak akan terpengaruh. Master untuk cluster GKE, yang dikelola oleh Google, akan di-patch otomatis dalam beberapa hari mendatang. Tidak ada pelanggan tindakan diperlukan. 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 mempersiapkan mitigasi permanen untuk kerentanan yang akan tersedia sebagai versi node baru. Kami akan memperbarui buletin ini dan mengirim email ke semua pelanggan GKE perbaikan permanen tersedia. Hingga perbaikan permanen tersedia, kita telah membuat Kubernetes DaemonSet yang menerapkan mitigasi dengan memodifikasi host Konfigurasi `iptables`. 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 pada node untuk memitigasi kerentanan. Jalankan perintah sekali per cluster per Google Cloud project ini. kubectl apply -f \ https://raw.githubusercontent.com/GoogleCloudPlatform\ /k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml Karena Ipv6 tidak didukung di GKE, aturan ip6tables tidak diperlukan. Setelah versi node yang di-patch tersedia dan Anda telah mengupgrade semua yang berpotensi terpengaruh, Anda dapat menghapus DaemonSet menggunakan perintah berikut. Jalankan perintah satu kali 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

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 upgrade target untuk kedua versi 1.11.

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

Master 1.11 tidak akan digunakan lagi dalam waktu dekat dan dijadwalkan untuk otomatis meningkatkan ke 1.12 pada minggu 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. Setelahnya tanggal, versi 1.11 akan mulai dihapus dari daftar yang tersedia target upgrade.
Aktifkan upgrade otomatis pada 1,11 node dan memungkinkannya untuk di-upgrade ketika {i>master<i} master diupgrade ke versi 1.12.
Mengupgrade secara manual baik {i>master<i} maupun {i>node<i} ke versi 1.12 yang telah diperbaiki.

Buletin asli dari 24 Juni 2019 sebagai berikut:

Update 24 Juni 2019

Pada 22-06-2019 21.40 UTC, kami membuat patch Kubernetes berikut versi yang tersedia. Master antara Kubernetes versi 1.11.0 dan 1.13.6 akan diupdate secara otomatis ke versi yang di-patch. Jika Anda tidak menjalankan versi yang kompatibel dengan patch ini, upgrade ke master yang kompatibel sebelum mengupgrade node Anda.

Karena keparahan dari kerentanan ini, upgrade otomatis node diaktifkan atau tidak, sebaiknya secara manual mengupgrade node dan master ke salah satu versi ini sesegera mungkin 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 ini secara kolektif disebut sebagai NFLX-2019-001.

Kernel Linux yang tidak di-patch mungkin rentan terhadap penolakan yang dipicu dari jarak jauh serangan layanan. Node Google Kubernetes Engine yang mengirim atau menerima lalu lintas jaringan yang tidak tepercaya terpengaruh, dan sebaiknya Anda mengikuti langkah-langkah mitigasi di bawah ini untuk melindungi workload Anda.

Master Kubernetes

Master Kubernetes menggunakan Jaringan yang Diizinkan membatasi lalu lintas data ke jaringan tepercaya tidak akan terpengaruh.
Master untuk cluster GKE, yang dikelola oleh Google, akan di-patch otomatis dalam beberapa hari mendatang. Tidak ada pelanggan tindakan diperlukan.

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 mempersiapkan mitigasi permanen untuk kerentanan yang akan tersedia sebagai versi node baru. Kami akan memperbarui buletin ini dan mengirim email ke semua pelanggan GKE perbaikan permanen tersedia.

Hingga perbaikan permanen tersedia, kita telah membuat Kubernetes DaemonSet yang menerapkan mitigasi dengan memodifikasi host Konfigurasi iptables.

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 pada node untuk memitigasi kerentanan. Jalankan perintah sekali per cluster per Google Cloud project ini.

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 yang berpotensi terpengaruh, Anda dapat menghapus DaemonSet menggunakan perintah berikut. Jalankan perintah satu kali 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

Deskripsi	Keparahan	Catatan
Update 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 tidak tersedia di versi 1.11.10. Kubernetes baru-baru ini menemukan kerentanan, CVE-2019-11246, yang memungkinkan penyerang mengakses operasi dan kode `kubectl cp` eksekusi di dalam kontainer untuk mengubah file di {i>host<i}. Eksploit ini berpotensi memungkinkan penyerang untuk mengganti atau membuat file di {i>host<i} sistem file. Untuk mengetahui detail selengkapnya, baca pengungkapan Kubernetes. Semua Versi `gcloud` Google Kubernetes Engine (GKE) terpengaruh oleh perubahan ini kerentanan, dan sebaiknya Anda mengupgrade ke patch terbaru. dari `gcloud` 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

Update 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 tidak tersedia di versi 1.11.10.

Kubernetes baru-baru ini menemukan kerentanan, CVE-2019-11246, yang memungkinkan penyerang mengakses operasi dan kode kubectl cp eksekusi di dalam kontainer untuk mengubah file di {i>host<i}. Eksploit ini berpotensi memungkinkan penyerang untuk mengganti atau membuat file di {i>host<i} sistem file. Untuk mengetahui detail selengkapnya, baca pengungkapan Kubernetes.

Semua Versi gcloud Google Kubernetes Engine (GKE) terpengaruh oleh perubahan ini kerentanan, dan sebaiknya Anda mengupgrade ke patch terbaru. dari gcloud 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

18 Juni 2019

Deskripsi Keparahan Catatan

Deskripsi	Keparahan	Catatan
Docker baru-baru ini menemukan kerentanan, CVE-2018-15664, yang memungkinkan penyerang yang dapat mengeksekusi kode di dalam container untuk membajak kode yang dimulai secara eksternal `docker cp`. Eksploit ini berpotensi memungkinkan sebuah penyerang untuk mengubah di mana file sedang ditulis, ke lokasi arbitrer dalam sistem file {i>host<i}. Semua node Google Kubernetes Engine (GKE) yang menjalankan Docker terpengaruh oleh kerentanan ini, dan sebaiknya Anda mengupgrade ke versi patch setelah tersedia. Versi {i>patch<i} mendatang akan menyertakan 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 sebuah Perintah `docker cp` (atau yang setara dengan API) yang dapat dibajak adalah diberikan. Hal ini diperkirakan akan cukup tidak biasa di lingkungan Kubernetes. Node yang menjalankan COS dengan containerd tidak akan terpengaruh. Untuk mengupgrade node, Anda harus mengupgrade master terlebih dahulu ke versi yang telah di-patch. Saat patch tersedia, Anda dapat memulai upgrade master atau menunggu hingga Google mengupgrade master secara otomatis. Patch akan tersedia di Docker 18.09.7, termasuk 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 tambalan satu kali yang 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. Eksploitasi ini berpotensi memungkinkan penyerang untuk mengubah tempat file ditulis, ke lokasi arbitrer dalam file host sistem file.	Tinggi

Docker baru-baru ini menemukan kerentanan, CVE-2018-15664, yang memungkinkan penyerang yang dapat mengeksekusi kode di dalam container untuk membajak kode yang dimulai secara eksternal docker cp. Eksploit ini berpotensi memungkinkan sebuah penyerang untuk mengubah di mana file sedang ditulis, ke lokasi arbitrer dalam sistem file {i>host<i}.

Semua node Google Kubernetes Engine (GKE) yang menjalankan Docker terpengaruh oleh kerentanan ini, dan sebaiknya Anda mengupgrade ke versi patch setelah tersedia. Versi {i>patch<i} mendatang akan menyertakan 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 sebuah Perintah docker cp (atau yang setara dengan API) yang dapat dibajak adalah diberikan. Hal ini diperkirakan akan cukup tidak biasa di lingkungan Kubernetes. Node yang menjalankan COS dengan containerd tidak akan terpengaruh.

Untuk mengupgrade node, Anda harus mengupgrade master terlebih dahulu ke versi yang telah di-patch. Saat patch tersedia, Anda dapat memulai upgrade master atau menunggu hingga Google mengupgrade master secara otomatis. Patch akan tersedia di Docker 18.09.7, termasuk 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 tambalan satu kali yang 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. Eksploitasi ini berpotensi memungkinkan penyerang untuk mengubah tempat file ditulis, ke lokasi arbitrer dalam file host sistem file.

Tinggi

31 Mei 2019

Deskripsi Keparahan Catatan

Deskripsi	Keparahan	Catatan
Buletin ini telah diperbarui sejak publikasi aslinya. Update 2 Agustus 2019 Pada saat buletin awal, hanya 1.13.6-gke.0 sampai 1.13.6-gke.5 terkena dampak. Karena regresi, semua versi 1.13.6.x terpengaruh. Jika Anda menjalankan 1.13.6, upgrade ke 1.13.7 segera 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 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 dijalankan sebagai UID 0. Jika nilai `USER` non-root ditentukan (misalnya, dengan menetapkan nilai `USER` di Dockerfile), tidak diharapkan perilaku model. Saat pertama kali container berjalan di node, container mengikuti UID yang ditentukan dengan benar. Namun, karena kerusakan ini, di proses kedua (dan proses berikutnya) container berjalan sebagai UID 0, terlepas dari UID yang ditentukan. Ini biasanya merupakan hak istimewa yang ditingkatkan yang 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 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 dijalankan sebagai pengguna non-root, dan Anda menjalankan node versi 1.13.6-gke.0 hingga 1.13.6-gke.6 Anda akan terdampak kecuali di kasus berikut: Pod yang menentukan nilai non-root yang valid untuk `runAsUser` PodSecurityContext tidak terpengaruh dan terus bekerja seperti yang diharapkan. PodSecurityPolicies yang menerapkan setelan `runAsUser` juga tidak terpengaruh dan terus bekerja seperti yang diharapkan. Pod yang menentukan `mustRunAsNonRoot:true` tidak akan dimulai sebagai UID 0, tetapi akan gagal dimulai jika terdampak oleh masalah ini. Apa yang harus saya lakukan? Setel Konteks Keamanan RunAsUser pada semua Pod di cluster yang seharusnya tidak dijalankan sebagai UID 0. Anda dapat menerapkan konfigurasi ini menggunakan PodSecurityPolicy.	Sedang	CVE-2019-11245

Buletin ini telah diperbarui sejak publikasi aslinya.

Update 2 Agustus 2019

Pada saat buletin awal, hanya 1.13.6-gke.0 sampai 1.13.6-gke.5 terkena dampak. Karena regresi, semua versi 1.13.6.x terpengaruh. Jika Anda menjalankan 1.13.6, upgrade ke 1.13.7 segera 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 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 dijalankan sebagai UID 0.

Jika nilai USER non-root ditentukan (misalnya, dengan menetapkan nilai USER di Dockerfile), tidak diharapkan perilaku model. Saat pertama kali container berjalan di node, container mengikuti UID yang ditentukan dengan benar. Namun, karena kerusakan ini, di proses kedua (dan proses berikutnya) container berjalan sebagai UID 0, terlepas dari UID yang ditentukan. Ini biasanya merupakan hak istimewa yang ditingkatkan yang 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 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 dijalankan sebagai pengguna non-root, dan Anda menjalankan node versi 1.13.6-gke.0 hingga 1.13.6-gke.6 Anda akan terdampak kecuali di kasus berikut:

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

Apa yang harus saya lakukan?

Setel Konteks Keamanan RunAsUser pada semua Pod di cluster yang seharusnya tidak dijalankan sebagai UID 0. Anda dapat menerapkan konfigurasi ini menggunakan PodSecurityPolicy.

Sedang

CVE-2019-11245

14 Mei 2019

Deskripsi Keparahan Catatan

Deskripsi	Keparahan	Catatan
Update 11-06-2019: Patch tersedia di 1.11.10-gke.4, 1.12.8-gke.6, dan 1.13.6-gke.5 merilis 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 Data Arsitektur Mikro Pengambilan Sampel (MDS). Kerentanan ini berpotensi memungkinkan data untuk diekspos melalui interaksi eksekusi spekulatif dengan keadaan mikroarsitektur. Untuk detail selengkapnya, lihat Pengungkapan Intel. Infrastruktur host yang menjalankan Kubernetes Engine mengisolasi workload pelanggan dari satu sama lain. Kecuali Anda menjalankan kode yang tidak tepercaya di dalam cluster GKE multi-tenant Anda sendiri, Anda tidak akan terpengaruh. Untuk pelanggan yang menjalankan kode tidak tepercaya di layanan mereka sendiri layanan multi-tenant dalam Kubernetes Engine, layanan ini terutama kerentanan yang sangat parah. Untuk memitigasinya di Kubernetes Engine, menonaktifkan Hyper-Threading di node Anda. Hanya Google Kubernetes Engine (GKE) yang menggunakan beberapa CPU terpengaruh oleh kerentanan ini. Perlu diperhatikan bahwa VM n1-standard-1 (default GKE), g1-small, dan f1-micro hanya mengekspos 1 vCPU ke lingkungan tamu sehingga tidak perlu nonaktifkan 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 patch secara otomatis dalam beberapa minggu mendatang, dengan upgrade rutin irama. Patch saja tidak cukup untuk memitigasi kerentanan terhadap kerentanan ini. Lihat tindakan yang disarankan di bawah. Jika menjalankan GKE secara lokal, Anda mungkin terpengaruh, bergantung pada hardware yang gunakan. Lihat Pengungkapan Intel. Apa yang harus saya lakukan? Kecuali jika Anda menjalankan kode yang tidak tepercaya di dalam cluster GKE multi-tenant, Anda tidak akan terpengaruh. Untuk node di Kubernetes Engine, buat node pool baru dengan Hyper-Threading dinonaktifkan dan jadwalkan ulang workload Anda ke versi baru node. Perlu diperhatikan 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 bahwa hal ini dapat diterima sebelum men-deploy ini ke cluster produksi. Hyper-threading dapat dinonaktifkan pada level node pool GKE dengan untuk men-deploy DaemonSet. Namun, men-deploy DaemonSet ini akan di semua {i>node<i} Anda dalam kumpulan node yang melakukan {i>reboot<i} secara bersamaan. Oleh karena itu, sebaiknya buat node pool baru di ke cluster terlebih dahulu, deploy DaemonSet untuk menonaktifkan Hyper-Threading node pool, lalu memigrasikan workload Anda ke node pool baru. Untuk membuat kumpulan node baru dengan Hyper-Threading dinonaktifkan: 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 Deploy DaemonSet ke node pool baru ini. DaemonSet hanya akan dapat dijalankan pada node dengan Label `cloud.google.com/gke-smt-disabled=true`. Materi ini akan nonaktifkan Hyper-Threading, lalu reboot node. kubectl create -f \ https://raw.githubusercontent.com/GoogleCloudPlatform/\ k8s-node-tools/master/disable-smt/gke/disable-smt.yaml 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 Periksa apakah "SMT telah dinonaktifkan" muncul di log pod. kubectl logs disable-smt-2xnnc disable-smt -n kube-system Catatan: Opsi booting tidak dapat dimodifikasi jika node memiliki Booting Aman mengaktifkan fitur ini. Jika {i>Secure Boot<i} diaktifkan, dinonaktifkan sebelum DaemonSet dibuat. Anda harus menjaga DaemonSet tetap berjalan pada kumpulan node agar node baru yang dibuat di dalam kumpulan tersebut, perubahan akan diterapkan secara otomatis. {i>Node<i} 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 upgrade node secara manual setelah patch menjadi yang tersedia. Untuk mengupgrade, Anda harus terlebih dahulu upgrade master Anda ke versi terbaru. Master GKE akan otomatis diupgrade sesuai 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-2019-11091: Kerentanan ini mengeksploitasi eksekusi spekulatif. CVE tersebut adalah secara kolektif disebut sebagai Pengambilan Sampel Data Microarchitectural. Ini kerentanan yang memungkinkan data diekspos melalui interaksi eksekusi spekulatif dengan kondisi arsitektur mikro.	Sedang	CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2018-11091

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

Intel telah mengungkapkan CVE berikut:

CVE ini secara kolektif disebut sebagai Data Arsitektur Mikro Pengambilan Sampel (MDS). Kerentanan ini berpotensi memungkinkan data untuk diekspos melalui interaksi eksekusi spekulatif dengan keadaan mikroarsitektur. Untuk detail selengkapnya, lihat Pengungkapan Intel.

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

Untuk pelanggan yang menjalankan kode tidak tepercaya di layanan mereka sendiri layanan multi-tenant dalam Kubernetes Engine, layanan ini terutama kerentanan yang sangat parah. Untuk memitigasinya di Kubernetes Engine, menonaktifkan Hyper-Threading di node Anda. Hanya Google Kubernetes Engine (GKE) yang menggunakan beberapa CPU terpengaruh oleh kerentanan ini. Perlu diperhatikan bahwa VM n1-standard-1 (default GKE), g1-small, dan f1-micro hanya mengekspos 1 vCPU ke lingkungan tamu sehingga tidak perlu nonaktifkan 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 patch secara otomatis dalam beberapa minggu mendatang, dengan upgrade rutin irama. Patch saja tidak cukup untuk memitigasi kerentanan terhadap kerentanan ini. Lihat tindakan yang disarankan di bawah.

Jika menjalankan GKE secara lokal, Anda mungkin terpengaruh, bergantung pada hardware yang gunakan. Lihat Pengungkapan Intel.

Apa yang harus saya lakukan?

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

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

Perlu diperhatikan 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 bahwa hal ini dapat diterima sebelum men-deploy ini ke cluster produksi.
Hyper-threading dapat dinonaktifkan pada level node pool GKE dengan untuk men-deploy DaemonSet. Namun, men-deploy DaemonSet ini akan di semua {i>node<i} Anda dalam kumpulan node yang melakukan {i>reboot<i} secara bersamaan. Oleh karena itu, sebaiknya buat node pool baru di ke cluster terlebih dahulu, deploy DaemonSet untuk menonaktifkan Hyper-Threading node pool, lalu memigrasikan workload Anda ke node pool baru.

Untuk membuat kumpulan node baru dengan Hyper-Threading dinonaktifkan:

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

Deploy DaemonSet ke node pool baru ini. DaemonSet hanya akan dapat dijalankan pada node dengan Label cloud.google.com/gke-smt-disabled=true. Materi ini akan nonaktifkan Hyper-Threading, lalu reboot node.
```
kubectl create -f \
https://raw.githubusercontent.com/GoogleCloudPlatform/\
k8s-node-tools/master/disable-smt/gke/disable-smt.yaml
```

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

Periksa apakah "SMT telah dinonaktifkan" muncul di log pod.
```
kubectl logs disable-smt-2xnnc disable-smt -n kube-system
```

Anda harus menjaga DaemonSet tetap berjalan pada kumpulan node agar node baru yang dibuat di dalam kumpulan tersebut, perubahan akan diterapkan secara otomatis. {i>Node<i} 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 upgrade node secara manual setelah patch menjadi yang tersedia. Untuk mengupgrade, Anda harus terlebih dahulu upgrade master Anda ke versi terbaru. Master GKE akan otomatis diupgrade sesuai 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-2019-11091: Kerentanan ini mengeksploitasi eksekusi spekulatif. CVE tersebut adalah secara kolektif disebut sebagai Pengambilan Sampel Data Microarchitectural. Ini kerentanan yang memungkinkan data diekspos melalui interaksi eksekusi spekulatif dengan kondisi arsitektur mikro.

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 diabaikan dalam beberapa kasus. Jika telah mengaktifkan Istio di Google Kubernetes Engine (GKE), Anda mungkin yang terdampak oleh kerentanan ini. Sebaiknya upgrade cluster yang terdampak ke versi patch terbaru sesegera mungkin, dan mengupgrade file bantuan Istio (petunjuk di bawah). Apa yang harus saya lakukan? Karena keparahan dari kerentanan ini, mengaktifkan atau tidak mengaktifkan upgrade otomatis node, sebaiknya Anda: Upgrade secara manual cluster Anda segera setelah patch tersedia. Upgrade file bantuan Anda 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. Cluster baru akan menggunakan versi yang di-patch secara default saat diumumkan di GKE halaman buletin keamanan, diharapkan pada 15 April 2019; jika Anda membuat cluster baru sebelum itu, Anda harus menentukan versi yang di-patch untuk gunakan. Pelanggan GKE yang memiliki upgrade otomatis node yang sudah diaktifkan, dan yang tidak mengupgrade secara manual, node-nya 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	CVE-2019-9900 CVE-2019-9901.

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 diabaikan dalam beberapa kasus.

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

Apa yang harus saya lakukan?

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

Upgrade secara manual cluster Anda segera setelah patch tersedia.
Upgrade file bantuan Anda 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. Cluster baru akan menggunakan versi yang di-patch secara default saat diumumkan di GKE halaman buletin keamanan, diharapkan pada 15 April 2019; jika Anda membuat cluster baru sebelum itu, Anda harus menentukan versi yang di-patch untuk gunakan. Pelanggan GKE yang memiliki upgrade otomatis node yang sudah diaktifkan, dan yang tidak mengupgrade secara manual, node-nya 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
Update 20-03-2019: Patch ini tersedia di Kubernetes 1.11.8-gke.4, 1.13.4-gke.1, dan rilis yang lebih baru. Patch belum tersedia di versi 1.12. Lacak ketersediaan {i>patch<i} ini dalam catatan rilis. Kubernetes baru-baru ini menemukan kerentanan denial of service baru CVE-2019-1002100, memungkinkan pengguna yang diberi otorisasi untuk membuat permintaan {i>patch<i} untuk membuat "json-patch" permintaan yang mengonsumsi terlalu banyak CPU dan memori di server Kubernetes API, yang berpotensi mengurangi ketersediaan bidang kontrol cluster. Untuk mengetahui detail selengkapnya, lihat Pengungkapan Kubernetes. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh dampak kerentanan. Versi {i>patch<i} yang akan datang akan menyertakan mitigasi untuk kerentanan ini. Kami akan mengupgrade master cluster ke versi yang di-patch secara otomatis 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 mengupgrade master terlebih dahulu, Anda dapat mulai upgrade master secara manual. Kami akan memperbarui buletin ini dengan versi yang berisi tambalan. Catatan bahwa {i>patch<i} itu hanya akan tersedia dalam versi 1.11+, tidak 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 jenis "json-patch" secara khusus sehingga menggunakan terlalu banyak CPU di server Kubernetes API, dan berpotensi mengurangi ketersediaan bidang kontrol cluster.	Sedang	CVE-2019-1002100

Deskripsi

Keparahan

Catatan

Update 20-03-2019: Patch ini tersedia di Kubernetes 1.11.8-gke.4, 1.13.4-gke.1, dan rilis yang lebih baru. Patch belum tersedia di versi 1.12. Lacak ketersediaan {i>patch<i} ini dalam catatan rilis.

Kubernetes baru-baru ini menemukan kerentanan denial of service baru CVE-2019-1002100, memungkinkan pengguna yang diberi otorisasi untuk membuat permintaan {i>patch<i} untuk membuat "json-patch" permintaan yang mengonsumsi terlalu banyak CPU dan memori di server Kubernetes API, yang berpotensi mengurangi ketersediaan bidang kontrol cluster. Untuk mengetahui detail selengkapnya, lihat Pengungkapan Kubernetes. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh dampak kerentanan. Versi {i>patch<i} yang akan datang akan menyertakan mitigasi untuk kerentanan ini. Kami akan mengupgrade master cluster ke versi yang di-patch secara otomatis 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 mengupgrade master terlebih dahulu, Anda dapat mulai upgrade master secara manual.

Kami akan memperbarui buletin ini dengan versi yang berisi tambalan. Catatan bahwa {i>patch<i} itu hanya akan tersedia dalam versi 1.11+, tidak 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 jenis "json-patch" secara khusus sehingga menggunakan terlalu banyak CPU di server Kubernetes API, dan berpotensi mengurangi ketersediaan bidang kontrol cluster.

Sedang

CVE-2019-1002100

11 Februari 2019 (runc)

Deskripsi	Keparahan	Catatan
Open Containers Initiative (OCI) baru-baru ini ditemukan keamanan baru kerentanan CVE-2019-5736 di runc, yang memungkinkan escape container untuk mendapatkan hak istimewa {i>root<i} pada node host. Node Ubuntu Google Kubernetes Engine (GKE) Anda terpengaruh oleh kerentanan ini, dan sebaiknya Anda upgrade 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 perlu memperbarui memori yang dialokasikan ke kontainer jika Anda telah menetapkan batas memori (< 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

Deskripsi

Keparahan

Catatan

Open Containers Initiative (OCI) baru-baru ini ditemukan keamanan baru kerentanan CVE-2019-5736 di runc, yang memungkinkan escape container untuk mendapatkan hak istimewa {i>root<i} pada node host.

Node Ubuntu Google Kubernetes Engine (GKE) Anda terpengaruh oleh kerentanan ini, dan sebaiknya Anda upgrade 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 perlu memperbarui memori yang dialokasikan ke kontainer jika Anda telah menetapkan batas memori (< 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
Update 25-02-2019: Patch tidak tersedia di 1.11.7-gke.4 seperti yang dikomunikasikan sebelumnya. Jika Anda menjalankan 1.11.7, Anda can: downgrade ke 1.11.6, upgrade ke 1.12, atau tunggu hingga 1.11.7 berikutnya patch tersedia minggu 2019-03-04. 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 mengetahui detail selengkapnya, lihat Pengungkapan bahasa pemrograman Go. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh dampak Kerentanan jaringan. Tujuan 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 diupgrade sesuai rangkaian langkah penjualan reguler kami. Jika ingin mengupgrade master terlebih dahulu, Anda dapat mulai 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

Deskripsi

Keparahan

Catatan

Update 25-02-2019: Patch tidak tersedia di 1.11.7-gke.4 seperti yang dikomunikasikan sebelumnya. Jika Anda menjalankan 1.11.7, Anda can: downgrade ke 1.11.6, upgrade ke 1.12, atau tunggu hingga 1.11.7 berikutnya patch tersedia minggu 2019-03-04.

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 mengetahui detail selengkapnya, lihat Pengungkapan bahasa pemrograman Go.

Semua master Google Kubernetes Engine (GKE) terpengaruh oleh dampak Kerentanan jaringan. Tujuan 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 diupgrade sesuai rangkaian langkah penjualan reguler kami. Jika ingin mengupgrade master terlebih dahulu, Anda dapat mulai 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 mengetahui detail selengkapnya, lihat Pengungkapan Kubernetes. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh dampak ini kerentanan, 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 kerentanan yang relatif rendah hak istimewa untuk mengabaikan otorisasi ke API kubelet. Cara ini memberikan pengguna berwenang untuk membuat permintaan yang dapat diupgrade untuk mengeskalasi dan panggilan arbitrer ke API kubelet. Ini dinilai sebagai Kritis kerentanan 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

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 mengetahui detail selengkapnya, lihat Pengungkapan Kubernetes. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh dampak ini kerentanan, 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 kerentanan yang relatif rendah hak istimewa untuk mengabaikan otorisasi ke API kubelet. Cara ini memberikan pengguna berwenang untuk membuat permintaan yang dapat diupgrade untuk mengeskalasi dan panggilan arbitrer ke API kubelet. Ini dinilai sebagai Kritis kerentanan 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 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 mencatat log di tingkat info jika "k8s_auth_token" ditetapkan di CNI konfigurasi jaringan. Selain itu, saat dijalankan dengan logging tingkat debug, token akun layanan secara eksplisit, baik di Calico file konfigurasi yang dibaca oleh Calico, atau sebagai variabel lingkungan yang digunakan oleh Calico, lalu komponen Calico (calico/node, felix, CNI) akan menulis informasi ini ke file log. Token-token tersebut memiliki izin sebagai berikut:

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 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 mencatat log di tingkat info jika "k8s_auth_token" ditetapkan di CNI konfigurasi jaringan.
Selain itu, saat dijalankan dengan logging tingkat debug, token akun layanan secara eksplisit, baik di Calico file konfigurasi yang dibaca oleh Calico, atau sebagai variabel lingkungan yang digunakan oleh Calico, lalu 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 apa pun tidak diperlukan. (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-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. Node pool Kubernetes Engine yang tidak memiliki upgrade otomatis diaktifkan harus upgrade manual saat gambar COS versi yang di-patch tersedia.	Tinggi	CVE-2018-3615 CVE-2018-3620 CVE-2018-3646

Deskripsi

Keparahan

Catatan

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.

Node pool Kubernetes Engine yang tidak memiliki upgrade otomatis diaktifkan harus upgrade manual saat gambar COS versi 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. Seperti halnya dengan CVE-2018-5390, adalah kerentanan jaringan tingkat {i> kernel<i} yang meningkatkan efektivitas serangan denial of service (DoS) terhadap kerentanan yang berbeda. 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	CVE-2018-5390 CVE-2018-5391

Deskripsi

Keparahan

Catatan

Update 05-09-2018

Baru-baru ini terungkap adanya kerentanan CVE-2018-5391. Seperti halnya dengan CVE-2018-5390, adalah kerentanan jaringan tingkat {i> kernel<i} yang meningkatkan efektivitas serangan denial of service (DoS) terhadap kerentanan yang berbeda. 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

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 class Daftar `volumes` yang diizinkan 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	CVE-2018-11235

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 class Daftar volumes yang diizinkan 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

CVE-2018-11235

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. CVE berikut teridentifikasi dengan tag CVE-2018-1000199, CVE-2018-8897, dan CVE-2018-1087. Kerentanan ini memengaruhi semua node Kubernetes Engine. sebaiknya Anda upgrade ke versi {i>patch<i} 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.	Tinggi	CVE-2018-1000199 CVE-2018-8897 CVE-2018-1087

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. CVE berikut teridentifikasi dengan tag CVE-2018-1000199, CVE-2018-8897, dan CVE-2018-1087. Kerentanan ini memengaruhi semua node Kubernetes Engine. sebaiknya Anda upgrade ke versi {i>patch<i} 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.

Tinggi

12 Maret 2018

Deskripsi	Keparahan	Catatan
Project Kubernetes diungkapkan baru-baru ini kerentanan keamanan baru, CVE-2017-1002101 dan CVE-2017-1002102, yang mengizinkan kontainer mengakses file di luar kontainer. 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 menjadi tersedia untuk semua pelanggan mulai 16 Maret, tetapi mungkin tersedia untuk lebih cepat berdasarkan zona tempat cluster Anda berada, menurut jadwal rilis Anda. 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, sebaiknya Anda upgrade manual {i>node<i} Anda segera setelah {i> patch<i} itu tersedia untuk Anda. 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	CVE-2017-1002101 CVE-2017-1002102

Deskripsi

Keparahan

Catatan

Project Kubernetes diungkapkan baru-baru ini kerentanan keamanan baru, CVE-2017-1002101 dan CVE-2017-1002102, yang mengizinkan kontainer mengakses file di luar kontainer. 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 menjadi tersedia untuk semua pelanggan mulai 16 Maret, tetapi mungkin tersedia untuk lebih cepat berdasarkan zona tempat cluster Anda berada, menurut jadwal rilis Anda.

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, sebaiknya Anda upgrade manual {i>node<i} Anda segera setelah {i> patch<i} itu tersedia untuk Anda.

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, kerentanan ditemukan di Kubernetes, CVE-2019-11253, yang memungkinkan setiap pengguna yang berwenang membuat permintaan POST untuk mengeksekusi remote Serangan Denial-of-Service pada server Kubernetes API. Kubernetes Product Security Committee (PSC) merilis informasi tambahan tentang kerentanan 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 {i>patch<i} 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 mengurangi kerentanan berikut: CVE-2019-11253.	Tinggi	CVE-2019-11253

Deskripsi

Keparahan

Catatan

Baru-baru ini, kerentanan ditemukan di Kubernetes, CVE-2019-11253, yang memungkinkan setiap pengguna yang berwenang membuat permintaan POST untuk mengeksekusi remote Serangan Denial-of-Service pada server Kubernetes API. Kubernetes Product Security Committee (PSC) merilis informasi tambahan tentang kerentanan 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 {i>patch<i} 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 mengurangi kerentanan berikut: CVE-2019-11253.

Tinggi

CVE-2019-11253

23 Agustus 2019

Deskripsi Keparahan Catatan

Deskripsi	Keparahan	Catatan
Baru-baru ini kita menemukan dan mengurangi kerentanan di mana {i>proxy<i} RBAC yang digunakan untuk mengamankan endpoint pemantauan tidak memberikan otorisasi kepada pengguna dengan benar. Akibatnya, metrik dari komponen tertentu tersedia untuk pengguna 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 upgrade cluster Anda ke versi 1.0.2-gke.3, yang mencakup {i>patch<i} untuk kerentanan tersebut, sesegera mungkin.	Sedang	Rilis Google Distributed Cloud

Baru-baru ini kita menemukan dan mengurangi kerentanan di mana {i>proxy<i} RBAC yang digunakan untuk mengamankan endpoint pemantauan tidak memberikan otorisasi kepada pengguna dengan benar. Akibatnya, metrik dari komponen tertentu tersedia untuk pengguna 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 upgrade cluster Anda ke versi 1.0.2-gke.3, yang mencakup {i>patch<i} untuk kerentanan tersebut, sesegera mungkin.

Sedang

Rilis Google Distributed Cloud

22 Agustus 2019

Deskripsi	Keparahan	Catatan
Kubernetes baru-baru ini menemukan sebuah kerentanan, CVE-2019-11247, yang memungkinkan cakupan cluster resource kustom untuk ditindaklanjuti seolah-olah mereka adalah objek dengan namespace yang ada di semua Namespace. Artinya, akun pengguna dan layanan hanya memiliki izin RBAC tingkat namespace dapat berinteraksi dengan kustom cakupan cluster Google Cloud Platform. Eksploitasi kerentanan ini mengharuskan penyerang untuk memiliki hak istimewa untuk mengakses sumber daya dalam namespace apa pun. Apa yang harus saya lakukan? Sebaiknya Anda upgrade cluster Anda ke versi 1.0.2-gke.3, yang mencakup {i>patch<i} untuk kerentanan tersebut, sesegera mungkin. Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch mengurangi kerentanan berikut: CVE-2019-11247.	Sedang	CVE-2019-11247

Deskripsi

Keparahan

Catatan

Apa yang harus saya lakukan?

Sebaiknya Anda upgrade cluster Anda ke versi 1.0.2-gke.3, yang mencakup {i>patch<i} untuk kerentanan tersebut, sesegera mungkin.

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch mengurangi kerentanan berikut: CVE-2019-11247.

Sedang

CVE-2019-11247