Arsip buletin keamanan

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

Google Kubernetes Engine (GKE)
GKE di VMware

Untuk melihat buletin keamanan terbaru, lihat halaman Buletin keamanan.

Buletin keamanan GKE

14 November 2019

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

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
Kubernetes telah mengungkapkan masalah keamanan di file bantuan kubernetes-csi `external-provisioner`, `external-snapshotter`, dan `external-resizer` yang memengaruhi sebagian besar versi file bantuan yang dipaketkan dalam driver Antarmuka Penyimpanan Container (CSI). Untuk mengetahui detail selengkapnya, lihat pengungkapan Kubernetes. Apa yang sebaiknya saya lakukan? Kerentanan ini tidak memengaruhi komponen GKE terkelola. Anda mungkin akan terpengaruh jika mengelola driver CSI sendiri di cluster GKE Alpha 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 file bantuan `kubernetes-csi` `external-provisioner`, `external-snapshotter`, dan `external-resizer` yang dapat mengizinkan akses atau mutasi data volume tanpa izin. Hal ini memengaruhi sebagian besar versi file bantuan yang dipaketkan dalam driver CSI.	Sedang	CVE-2019-11255

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

Apa yang sebaiknya saya lakukan?
Kerentanan ini tidak memengaruhi komponen GKE terkelola. Anda mungkin akan terpengaruh jika mengelola driver CSI sendiri di cluster GKE Alpha 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 file bantuan kubernetes-csi external-provisioner, external-snapshotter, dan external-resizer yang dapat mengizinkan akses atau mutasi data volume tanpa izin. Hal ini memengaruhi sebagian besar versi file bantuan yang dipaketkan dalam driver CSI.

Sedang

CVE-2019-11255

12 November 2019

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

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
Intel telah mengungkapkan CVE yang berpotensi mengizinkan interaksi antara eksekusi spekulatif dan status mikroarsitektur untuk mengekspos data. Untuk detail selengkapnya, lihat pengungkapan Intel. Infrastruktur host yang menjalankan Kubernetes Engine mengisolasi workload pelanggan. Kecuali jika Anda menjalankan kode tidak tepercaya di dalam cluster GKE multi-tenant multi-tenant Anda dan menggunakan node N2, M2, atau C2, Anda tidak perlu melakukan tindakan lebih lanjut. Untuk instance GKE pada node N1, Anda tidak perlu melakukan tindakan baru. Jika Anda menjalankan GKE di VMware, eksposur bergantung pada hardware. Harap bandingkan infrastruktur Anda dengan pengungkapan Intel. Apa yang sebaiknya saya lakukan? *Anda hanya akan terkena dampaknya jika menggunakan node pool dengan node N2, M2, atau C2 dan* node tersebut menjalankan kode tidak tepercaya di dalam cluster GKE multi-tenant Anda sendiri. Memulai ulang node akan menerapkan patch.** Cara termudah untuk memulai ulang semua node di kumpulan node Anda adalah dengan menggunakan operasi upgrade untuk memulai ulang secara paksa di semua kumpulan node yang terpengaruh. Catatan: Anda tidak perlu mengubah versi selama upgrade. Anda dapat memulai 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 cara lain untuk pemindahan data yang tidak sah menggunakan struktur data mikroarsitektur yang sama yang dieksploitasi oleh MicroArsitektur Data Sampling (MDS). CVE-2018-12207 Ini adalah kerentanan Denial of Service (DoS) yang memengaruhi host virtual machine yang memungkinkan tamu berbahaya menyebabkan error pada host yang tidak dilindungi. CVE ini juga dikenal sebagai "Machine Check Error pada Perubahan Ukuran Halaman". Hal ini tidak memengaruhi GKE.	Sedang	CVE-2019-11135 CVE-2018-12207

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

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

Jika Anda menjalankan GKE di VMware, eksposur bergantung pada hardware. Harap bandingkan infrastruktur Anda dengan pengungkapan Intel.

Apa yang sebaiknya saya lakukan?

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

Memulai ulang node akan menerapkan patch. Cara termudah untuk memulai ulang semua node di kumpulan node Anda adalah dengan menggunakan operasi upgrade untuk memulai ulang secara paksa di semua kumpulan node yang terpengaruh.

Catatan: Anda tidak perlu mengubah versi selama upgrade. Anda dapat memulai 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 cara lain untuk pemindahan data yang tidak sah menggunakan struktur data mikroarsitektur yang sama yang dieksploitasi oleh MicroArsitektur Data Sampling (MDS).

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

Sedang

CVE-2019-11135
CVE-2018-12207

22 Oktober 2019

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

Deskripsi	Keparahan	Notes
Baru-baru ini ditemukan kerentanan dalam bahasa pemrograman Go, yang dijelaskan dalam CVE-2019-16276. Kerentanan ini berpotensi memengaruhi konfigurasi Kubernetes yang menggunakan Proxy Autentikasi. Untuk mengetahui detail selengkapnya, lihat pengungkapan Kubernetes. Kubernetes Engine tidak mengizinkan konfigurasi Proxy Autentikasi, sehingga tidak terpengaruh oleh kerentanan ini.	Tidak ada	CVE-2019-16276

Deskripsi

Keparahan

Notes

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

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

Tidak ada

CVE-2019-16276

16 Oktober 2019

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

Deskripsi	Keparahan	Notes
Update 24-10-2019: Versi yang di-patch kini tersedia di semua zona. Baru-baru ini, sebuah kerentanan ditemukan di Kubernetes, yang dijelaskan dalam CVE-2019-11253, yang memungkinkan setiap pengguna yang diizinkan membuat permintaan POST untuk menjalankan serangan Denial-of-Service jarak jauh pada server Kubernetes API. Komite Keamanan Produk (PSC) Kubernetes merilis informasi tambahan tentang kerentanan ini yang dapat ditemukan di sini. Cluster GKE yang menggunakan Jaringan yang Diizinkan Master dan Cluster pribadi tanpa endpoint publik mengurangi kerentanan ini. Apa yang sebaiknya saya lakukan? Sebaiknya upgrade cluster Anda ke versi patch yang berisi perbaikan segera setelah tersedia. Kami berharap solusi tersebut akan tersedia di semua zona dengan rencana rilis GKE pada minggu 14 Oktober. Versi patch yang akan berisi mitigasi tercantum di bawah: 1.12.10-gke.15 1.13.11-gke.5 1.14.7-gke.10 1.15.4-gke.15 Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: CVE-2019-11253 adalah kerentanan Denial-of-Service (DoS).	Tinggi	CVE-2019-11253

Deskripsi

Keparahan

Notes

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

Baru-baru ini, sebuah kerentanan ditemukan di Kubernetes, yang dijelaskan dalam CVE-2019-11253, yang memungkinkan setiap pengguna yang diizinkan membuat permintaan POST untuk menjalankan serangan Denial-of-Service jarak jauh pada server Kubernetes API. Komite Keamanan Produk (PSC) Kubernetes merilis informasi tambahan tentang kerentanan ini yang dapat ditemukan di sini.

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

Apa yang sebaiknya saya lakukan?

Sebaiknya upgrade cluster Anda ke versi patch yang berisi perbaikan segera setelah tersedia. Kami berharap solusi tersebut akan tersedia di semua zona dengan rencana rilis GKE pada minggu 14 Oktober.

Versi patch yang akan berisi mitigasi tercantum di bawah:

1.12.10-gke.15
1.13.11-gke.5
1.14.7-gke.10
1.15.4-gke.15

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

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

Tinggi

CVE-2019-11253

16 September 2019

Dipublikasikan: 16-09-2019
Diperbarui: 2019-10-16

Deskripsi	Keparahan	Notes
Buletin ini telah diperbarui sejak publikasi aslinya. Bahasa pemrograman Go baru-baru ini menemukan kerentanan keamanan baru CVE-2019-9512 dan CVE-2019-9514, yang merupakan kerentanan Denial of Service (DoS). Di GKE, hal ini memungkinkan pengguna membuat permintaan berbahaya yang menghabiskan terlalu banyak CPU di server Kubernetes API, sehingga berpotensi mengurangi ketersediaan bidang kontrol cluster. Untuk detail selengkapnya, lihat pengungkapan bahasa pemrograman Go. Apa yang sebaiknya saya lakukan? Sebaiknya upgrade cluster Anda ke versi patch terbaru, yang berisi mitigasi terhadap kerentanan ini, segera setelah tersedia. Kami berharap solusi tersebut tersedia di semua zona dalam rilis GKE berikutnya, sesuai dengan jadwal rilis. Versi patch yang akan berisi mitigasi tercantum di bawah: Update 16 Oktober 2019: 1.12.10-gke.15 1.13.10-gke.0 1.14.6-gke.1 Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: CVE-2019-9512 dan CVE-2019-9514 adalah kerentanan Denial of Service (DoS).	Tinggi	CVE-2019-9512 CVE-2019-9514

Deskripsi

Keparahan

Notes

Buletin ini telah diperbarui sejak publikasi aslinya.

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

Apa yang sebaiknya saya lakukan?

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

Versi patch yang akan berisi mitigasi tercantum di bawah:

Update 16 Oktober 2019: 1.12.10-gke.15
1.13.10-gke.0
1.14.6-gke.1

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

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

Tinggi

CVE-2019-9512
CVE-2019-9514

5 September 2019

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

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

22 Agustus 2019

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

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

8 Agustus 2019

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

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

5 Agustus 2019

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

Deskripsi	Keparahan	Notes
Buletin ini telah diperbarui sejak publikasi aslinya. Baru-baru ini Kubernetes menemukan kerentanan, CVE-2019-11247, yang memungkinkan instance resource kustom cakupan cluster ditindaklanjuti seolah-olah instance tersebut adalah objek dengan namespace yang ada di semua Namespace. Artinya, akun pengguna dan layanan yang hanya memiliki izin RBAC tingkat namespace dapat berinteraksi dengan resource kustom cakupan cluster. Mengeksploitasi kerentanan ini mengharuskan penyerang memiliki hak istimewa untuk mengakses resource di namespace mana pun. Apa yang sebaiknya saya lakukan? Sebaiknya upgrade cluster Anda ke versi patch terbaru, yang berisi mitigasi terhadap kerentanan ini, segera setelah tersedia. Kami berharap solusi tersebut tersedia di semua zona dalam rilis GKE berikutnya. Versi patch yang akan berisi mitigasi tercantum di bawah: 1.11.10-gke.6 1.12.9-gke.13 1.13.7-gke.19 1.14.3-gke.10 (Saluran Cepat) Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi kerentanan berikut: CVE-2019-11247.	Sedang	CVE-2019-11247

Deskripsi

Keparahan

Notes

Buletin ini telah diperbarui sejak publikasi aslinya.

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

Apa yang sebaiknya saya lakukan?

1.11.10-gke.6
1.12.9-gke.13
1.13.7-gke.19
1.14.3-gke.10 (Saluran Cepat)

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

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

Sedang

CVE-2019-11247

3 Juli 2019

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

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
Versi `kubectl` yang di-patch untuk menangani CVE-2019-11246 kini tersedia dengan `gcloud` 253.0.0. Lihat buletin keamanan 25 Juni 2019 untuk informasi selengkapnya. Catatan: Patch tidak tersedia di `kubectl` 1.11.10.	Tinggi	CVE-2019-11246

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

Catatan: Patch tidak tersedia di kubectl 1.11.10.

Tinggi

CVE-2019-11246

3 Juli 2019

Dipublikasikan: 25-06-2019
Diperbarui: 2019-07-03

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
Update 3 Juli 2019 Pada saat update terakhir kami, patch untuk versi 1.11.9 dan 1.11.10 belum tersedia. Kami telah merilis 1.11.10-gke.5 sebagai target upgrade untuk kedua versi 1.11 tersebut. 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 diupgrade secara otomatis ke versi 1.12 pada minggu yang dimulai dari 8 Juli 2019. Anda dapat memilih salah satu tindakan yang disarankan berikut untuk memasukkan node ke versi yang di-patch: Lakukan upgrade node ke 1.11.10-gke.5 sebelum 8 Juli 2019. Setelah tanggal ini, versi 1.11 akan mulai dihapus dari daftar target upgrade yang tersedia. Aktifkan upgrade otomatis pada node 1.11 dan izinkan untuk diupgrade saat master diupgrade ke node 1.12. Upgrade secara manual master dan node ke versi 1.12 tetap. Buletin asli dari 24 Juni 2019 adalah sebagai berikut: Update 24 Juni 2019 Mulai 22-06-2019 pukul 21.40 UTC, kami telah menyediakan versi Kubernetes yang di-patch berikut. Master antara Kubernetes versi 1.11.0 dan 1.13.6 akan otomatis diupdate ke versi yang di-patch. Jika Anda tidak menjalankan versi yang kompatibel dengan patch ini, upgrade ke versi master yang kompatibel (tercantum di bawah ini) sebelum mengupgrade node Anda. Karena tingkat keparahan kerentanan ini, baik upgrade otomatis node telah diaktifkan atau belum, sebaiknya Anda mengupgrade node dan master secara manual ke salah satu versi ini sesegera mungkin. Verion 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 adalah 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 keseluruhan disebut sebagai NFLX-2019-001. Kernel Linux yang tidak di-patch mungkin rentan terhadap serangan denial of service yang dipicu dari jarak jauh. Node Google Kubernetes Engine yang mengirim atau menerima traffic jaringan yang tidak tepercaya akan terpengaruh. Sebaiknya ikuti langkah-langkah mitigasi berikut untuk melindungi workload Anda. Master Kubernetes Master Kubernetes yang menggunakan Jaringan Resmi untuk membatasi traffic ke jaringan tepercaya tidak akan terpengaruh. Master untuk cluster GKE, yang dikelola oleh Google, akan di-patch secara otomatis dalam beberapa hari mendatang. Pelanggan tidak perlu melakukan tindakan apa pun. Node Kubernetes Node yang membatasi traffic ke jaringan tepercaya tidak akan terpengaruh. Kumpulan ini akan berupa cluster dengan hal berikut: Node yang dilindungi firewall dari jaringan yang tidak tepercaya atau tanpa IP publik (Cluster pribadi) Cluster tanpa Layanan LoadBalancer publik Google sedang menyiapkan mitigasi permanen untuk kerentanan ini yang akan tersedia sebagai versi node baru. Kami akan memperbarui buletin ini dan mengirimkan email kepada semua pelanggan GKE saat perbaikan permanen tersedia. Sebelum perbaikan permanen tersedia, kami telah membuat DaemonSet Kubernetes yang menerapkan mitigasi dengan mengubah konfigurasi `iptables` host. Apa yang sebaiknya 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 mengurangi kerentanan. Jalankan perintah sekali per cluster per project Google Cloud. kubectl apply -f \ https://raw.githubusercontent.com/GoogleCloudPlatform\ /k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml Karena Ipv6 tidak didukung di GKE, aturan ip6tables tidak diperlukan. Setelah versi node yang di-patch tersedia dan Anda telah mengupgrade semua node yang berpotensi terpengaruh, Anda dapat menghapus DaemonSet menggunakan perintah berikut. Jalankan perintah sekali per cluster per project Google Cloud. kubectl delete -f \ https://raw.githubusercontent.com/GoogleCloudPlatform\ /k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml	Tinggi Sedang Sedang	CVE-2019-11477 CVE-2019-11478 CVE-2019-11479

Update 3 Juli 2019

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

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 diupgrade secara otomatis ke versi 1.12 pada minggu yang dimulai dari 8 Juli 2019. Anda dapat memilih salah satu tindakan yang disarankan berikut untuk memasukkan node ke versi yang di-patch:

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

Buletin asli dari 24 Juni 2019 adalah sebagai berikut:

Update 24 Juni 2019

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

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

Verion 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 adalah sebagai berikut:

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

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

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

Master Kubernetes

Master Kubernetes yang menggunakan Jaringan Resmi untuk membatasi traffic ke jaringan tepercaya tidak akan terpengaruh.
Master untuk cluster GKE, yang dikelola oleh Google, akan di-patch secara otomatis dalam beberapa hari mendatang. Pelanggan tidak perlu melakukan tindakan apa pun.

Node Kubernetes

Node yang membatasi traffic ke jaringan tepercaya tidak akan terpengaruh. Kumpulan ini akan berupa cluster dengan hal berikut:

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

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

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

Apa yang sebaiknya 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 mengurangi kerentanan. Jalankan perintah sekali per cluster per project Google Cloud.


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

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


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

Tinggi
Sedang
Sedang

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

25 Juni 2019

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
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 ini tidak tersedia di 1.11.10. Kubernetes baru-baru ini menemukan kerentanan, CVE-2019-11246, yang memungkinkan penyerang memiliki akses ke operasi `kubectl cp` dan eksekusi kode di dalam container untuk mengubah file di host. Eksploit ini berpotensi memungkinkan penyerang mengganti atau membuat file dalam sistem file host. Untuk mengetahui detail selengkapnya, lihat pengungkapan Kubernetes. Semua versi `gcloud` Google Kubernetes Engine (GKE) terpengaruh oleh kerentanan ini. Sebaiknya Anda mengupgrade ke versi patch terbaru `gcloud` saat tersedia. Versi patch mendatang akan mencakup mitigasi untuk kerentanan ini. Apa yang sebaiknya 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 dengan akses ke operasi `kubectl cp` dan eksekusi kode di dalam container untuk mengubah file di host. Eksploitasi ini berpotensi memungkinkan penyerang untuk mengganti atau membuat file dalam 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 ini tidak tersedia di 1.11.10.

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

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

Apa yang sebaiknya 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 dengan akses ke operasi kubectl cp dan eksekusi kode di dalam container untuk mengubah file di host. Eksploitasi ini berpotensi memungkinkan penyerang untuk mengganti atau membuat file dalam sistem file {i>host<i}

Tinggi

CVE-2019-11246

18 Juni 2019

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
Docker baru-baru ini menemukan kerentanan, CVE-2018-15664, yang memungkinkan penyerang yang dapat mengeksekusi kode di dalam container untuk membajak operasi `docker cp` yang dimulai secara eksternal. Eksploit ini berpotensi memungkinkan penyerang mengubah lokasi penulisan file, ke lokasi arbitrer dalam sistem file host. Semua node Google Kubernetes Engine (GKE) yang menjalankan Docker terpengaruh oleh kerentanan ini. Sebaiknya Anda mengupgrade ke versi patch terbaru setelah tersedia. Versi patch mendatang akan mencakup mitigasi untuk kerentanan ini. Semua master Google Kubernetes Engine (GKE) yang lebih lama dari versi 1.12.7 menjalankan Docker dan terpengaruh oleh kerentanan ini. Di GKE, pengguna tidak memiliki akses ke `docker cp` pada master, sehingga risiko kerentanan ini terbatas pada master GKE. Apa yang sebaiknya saya lakukan? Hanya node yang menjalankan Docker yang akan terpengaruh, dan hanya jika perintah `docker cp` (atau yang setara dengan API) yang dapat dibajak dikeluarkan. Hal ini diperkirakan akan cukup tidak biasa dalam lingkungan Kubernetes. Node yang menjalankan COS dengan container tidak terpengaruh. Untuk mengupgrade node, Anda harus mengupgrade master terlebih dahulu ke versi yang di-patch. Jika patch tersedia, Anda dapat memulai upgrade master atau menunggu Google mengupgrade master tersebut secara otomatis. Patch ini akan tersedia di Docker 18.09.7, yang disertakan dalam patch GKE mendatang. Patch ini hanya akan tersedia untuk GKE versi 1.13 dan yang lebih baru. Kami akan otomatis mengupgrade master cluster ke versi yang di-patch, dengan ritme upgrade reguler. Anda juga dapat memulai upgrade master sendiri setelah versi yang di-patch tersedia. Kami akan memperbarui buletin ini dengan versi yang berisi patch setelah tersedia. Lacak ketersediaan patch ini di catatan rilis. Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: Kerentanan CVE-2018-15664 memungkinkan penyerang yang dapat mengeksekusi kode di dalam container untuk membajak operasi `docker cp` yang dimulai secara eksternal. Eksploit ini berpotensi memungkinkan penyerang mengubah lokasi penulisan file, ke lokasi arbitrer dalam sistem file host.	Tinggi

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

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

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

Apa yang sebaiknya saya lakukan?

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

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

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

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

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

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

Tinggi

31 Mei 2019

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
Buletin ini telah diperbarui sejak publikasi aslinya. Update 2 Agustus 2019 Pada saat buletin awal, hanya 1.13.6-gke.0 hingga 1.13.6-gke.5 yang terpengaruh. Karena regresi, semua versi 1.13.6.x sekarang terpengaruh. Jika Anda menjalankan upgrade 1.13.6 ke 1.13.7 sesegera mungkin. Project Kubernetes telah mengungkapkan CVE-2019-11245 di kubelet v1.13.6 dan v1.14.2, yang dapat menyebabkan container dijalankan sebagai UID 0 (biasanya dipetakan ke pengguna `root`), meskipun pengguna yang berbeda ditetapkan dalam image container. Jika penampung Anda dijalankan sebagai pengguna non-root dan Anda menjalankan node versi 1.13.6-gke.0 hingga 1.13.6-gke.6, sebaiknya tetapkan `RunAsUser` pada semua Pod dalam cluster yang container-nya tidak boleh berjalan sebagai UID 0. Jika nilai `USER` non-root ditentukan (misalnya, dengan menetapkan nilai `USER` di Dockerfile), perilaku yang tidak diharapkan akan terjadi. Saat container berjalan untuk pertama kalinya pada sebuah node, container akan mengikuti UID yang ditetapkan dengan benar. Namun, karena kerusakan ini, pada run kedua (dan operasi berikutnya), container akan berjalan sebagai UID 0, terlepas dari UID yang ditetapkan. Hal ini biasanya merupakan hak istimewa yang dieskalasikan yang tidak diinginkan, dan dapat menyebabkan perilaku aplikasi yang tidak diharapkan. 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 terkena dampak: v1.13.6 v1.14.2 Bagaimana cara mengetahui apakah konfigurasi tertentu saya terpengaruh? Jika penampung 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 dalam kasus berikut: Pod yang menentukan nilai non-root yang valid untuk PodSecurityContext `runAsUser` tidak akan terpengaruh dan terus berfungsi seperti yang diharapkan. PodSecurityPolicies yang menerapkan setelan `runAsUser` juga tidak terpengaruh dan terus berfungsi seperti yang diharapkan. Pod yang menentukan `mustRunAsNonRoot:true` tidak akan dimulai sebagai UID 0, tetapi akan gagal dimulai saat terpengaruh oleh masalah ini. Apa yang sebaiknya saya lakukan? Tetapkan RunAsUser Security Context pada semua Pod dalam cluster yang tidak boleh berjalan 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 hingga 1.13.6-gke.5 yang terpengaruh. Karena regresi, semua versi 1.13.6.x sekarang terpengaruh. Jika Anda menjalankan upgrade 1.13.6 ke 1.13.7 sesegera mungkin.

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

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

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 terkena dampak:

v1.13.6
v1.14.2

Bagaimana cara mengetahui apakah konfigurasi tertentu saya terpengaruh?

Jika penampung 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 dalam kasus berikut:

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

Apa yang sebaiknya saya lakukan?

Tetapkan RunAsUser Security Context pada semua Pod dalam cluster yang tidak boleh berjalan sebagai UID 0. Anda dapat menerapkan konfigurasi ini menggunakan PodSecurityPolicy.

Sedang

CVE-2019-11245

14 Mei 2019

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
Update 11-06-2019: Patch ini tersedia dalam 1.11.10-gke.4, 1.12.8-gke.6, dan 1.13.6-gke.5 yang dirilis pada 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 keseluruhan disebut sebagai Micro Architecture Data Sampling (MDS). Kerentanan ini berpotensi memungkinkan data terekspos melalui interaksi eksekusi spekulatif dengan keadaan mikroarsitektur. Untuk detail selengkapnya, lihat pengungkapan Intel. Infrastruktur host yang menjalankan Kubernetes Engine mengisolasi workload pelanggan satu sama lain. Jika Anda tidak menjalankan kode tidak tepercaya di dalam cluster GKE multi-tenant, Anda tidak akan terpengaruh. Bagi pelanggan yang menjalankan kode tidak tepercaya pada layanan multi-tenant mereka dalam Kubernetes Engine, ini merupakan kerentanan yang sangat serius. Untuk memitigasinya di Kubernetes Engine, nonaktifkan Hyper-Threading di node Anda. Kerentanan ini hanya memengaruhi node Google Kubernetes Engine (GKE) yang menggunakan banyak CPU. Perlu diperhatikan bahwa VM n1-standard-1 (default GKE), VM g1-small, dan f1-micro hanya mengekspos 1 vCPU ke lingkungan tamu sehingga Anda tidak perlu menonaktifkan Hyper-Threading. Perlindungan tambahan untuk mengaktifkan fungsi flush akan disertakan dalam versi patch mendatang. Kami akan mengupgrade master dan node secara otomatis ke versi yang di-patch dalam beberapa minggu mendatang, dengan ritme upgrade reguler. Patch saja tidak cukup untuk mengurangi paparan kerentanan ini. Lihat tindakan yang disarankan di bawah. Jika menjalankan GKE secara lokal, Anda mungkin akan terpengaruh, bergantung pada hardware yang digunakan. Lihat pengungkapan Intel. Apa yang sebaiknya saya lakukan? Kecuali jika Anda menjalankan kode tidak tepercaya di dalam cluster GKE multi-tenant Anda sendiri, Anda tidak akan terpengaruh. Untuk node di Kubernetes Engine, buat node pool baru dengan Hyper-Threading dinonaktifkan dan jadwalkan ulang workload ke node baru. Perlu diperhatikan bahwa VM n1-standard-1, g1-small, dan f1-micro hanya mengekspos 1 vCPU ke lingkungan tamu sehingga Anda tidak perlu menonaktifkan Hyper-Threading. Peringatan: Menonaktifkan Hyper-Threading mungkin berdampak buruk pada performa pada cluster dan aplikasi Anda. Pastikan bahwa nilai ini dapat diterima sebelum men-deploy ini ke cluster produksi Anda. Hyper-threading dapat dinonaktifkan pada level node pool GKE dengan men-deploy DaemonSet. Namun, men-deploy DaemonSet ini akan menyebabkan semua node Anda dalam kumpulan node di-reboot secara bersamaan. Oleh karena itu, sebaiknya buat kumpulan node baru di cluster Anda, deploy DaemonSet untuk menonaktifkan Hyper-Threading di kumpulan node tersebut, lalu migrasikan workload Anda ke kumpulan node 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 kumpulan node baru ini. DaemonSet hanya akan berjalan pada node dengan label `cloud.google.com/gke-smt-disabled=true`. Tindakan ini akan menonaktifkan Hyper-Threading, lalu memulai ulang node. kubectl create -f \ https://raw.githubusercontent.com/GoogleCloudPlatform/\ k8s-node-tools/master/disable-smt/gke/disable-smt.yaml Pastikan pod DaemonSet dalam status berjalan. kubectl get pods --selector=name=disable-smt -n kube-system Anda akan mendapatkan respons yang mirip dengan: NAME READY STATUS RESTARTS AGE disable-smt-2xnnc 1/1 Running 0 6m Periksa apakah "SMT has been disabled" muncul dalam log pod. kubectl logs disable-smt-2xnnc disable-smt -n kube-system Catatan: Opsi booting tidak dapat diubah jika node telah mengaktifkan fitur Secure Boot. Jika Secure Boot diaktifkan, ia harus dinonaktifkan sebelum DaemonSet dibuat. Anda harus terus menjalankan DaemonSet di kumpulan node sehingga perubahan yang dibuat akan otomatis diterapkan pada node baru yang dibuat dalam kumpulan tersebut. Pembuatan node dapat dipicu oleh perbaikan otomatis node, upgrade manual atau otomatis, dan penskalaan otomatis. Untuk mengaktifkan kembali Hyper-Threading, Anda harus membuat ulang kumpulan node tanpa men-deploy DaemonSet yang disediakan, dan memigrasikan workload Anda ke kumpulan node baru. Sebaiknya upgrade node Anda secara manual setelah patch tersedia. Untuk mengupgrade, Anda harus mengupgrade master terlebih dahulu ke versi terbaru. Master GKE akan otomatis diupgrade dengan ritme upgrade reguler. Kami akan memperbarui buletin ini dengan versi yang berisi patch setelah tersedia. Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091: Kerentanan ini mengeksploitasi eksekusi spekulatif. CVE ini secara keseluruhan disebut sebagai Sampling Data Mikroarsitektur. Kerentanan ini berpotensi memungkinkan data diekspos melalui interaksi eksekusi spekulatif dengan keadaan mikroarsitektur.	Sedang	CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2018-11091

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

Intel telah mengungkapkan CVE berikut:

CVE ini secara keseluruhan disebut sebagai Micro Architecture Data Sampling (MDS). Kerentanan ini berpotensi memungkinkan data terekspos melalui interaksi eksekusi spekulatif dengan keadaan mikroarsitektur. Untuk detail selengkapnya, lihat pengungkapan Intel.

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

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

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

Jika menjalankan GKE secara lokal, Anda mungkin akan terpengaruh, bergantung pada hardware yang digunakan. Lihat pengungkapan Intel.

Apa yang sebaiknya saya lakukan?

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

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

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

Peringatan:

Menonaktifkan Hyper-Threading mungkin berdampak buruk pada performa pada cluster dan aplikasi Anda. Pastikan bahwa nilai ini dapat diterima sebelum men-deploy ini ke cluster produksi Anda.
Hyper-threading dapat dinonaktifkan pada level node pool GKE dengan men-deploy DaemonSet. Namun, men-deploy DaemonSet ini akan menyebabkan semua node Anda dalam kumpulan node di-reboot secara bersamaan. Oleh karena itu, sebaiknya buat kumpulan node baru di cluster Anda, deploy DaemonSet untuk menonaktifkan Hyper-Threading di kumpulan node tersebut, lalu migrasikan workload Anda ke kumpulan node 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 kumpulan node baru ini. DaemonSet hanya akan berjalan pada node dengan label cloud.google.com/gke-smt-disabled=true. Tindakan ini akan menonaktifkan Hyper-Threading, lalu memulai ulang node.
```
kubectl create -f \
https://raw.githubusercontent.com/GoogleCloudPlatform/\
k8s-node-tools/master/disable-smt/gke/disable-smt.yaml
```

Pastikan pod DaemonSet dalam status berjalan.


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

Anda akan mendapatkan respons yang mirip dengan:


NAME                READY     STATUS    RESTARTS   AGE

disable-smt-2xnnc   1/1       Running   0          6m

Periksa apakah "SMT has been disabled" muncul dalam log pod.
```
kubectl logs disable-smt-2xnnc disable-smt -n kube-system
```

Anda harus terus menjalankan DaemonSet di kumpulan node sehingga perubahan yang dibuat akan otomatis diterapkan pada node baru yang dibuat dalam kumpulan tersebut. Pembuatan node dapat dipicu oleh perbaikan otomatis node, upgrade manual atau otomatis, dan penskalaan otomatis.

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

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

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

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

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

Sedang

5 April 2019

Deskripsi	Keparahan	Notes
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 Anda telah mengaktifkan Istio di Google Kubernetes Engine (GKE), Anda mungkin akan terpengaruh oleh kerentanan ini. Sebaiknya upgrade cluster Anda yang terpengaruh ke versi patch terbaru secepatnya, dan upgrade file bantuan Istio Anda (petunjuknya di bawah). Apa yang sebaiknya saya lakukan? Karena tingkat keparahan kerentanan ini, baik upgrade otomatis node Anda telah diaktifkan atau belum, sebaiknya Anda: Upgrade cluster Anda secara manual segera setelah patch tersedia. Upgrade file bantuan dengan mengikuti dokumentasi upgrade file bantuan. Versi yang di-patch akan tersedia untuk semua project GKE sebelum pukul 19.00 PDT hari ini. Patch ini akan tersedia di versi GKE di bawah. Cluster baru akan menggunakan versi yang di-patch secara default saat diumumkan di halaman buletin keamanan GKE, yang diperkirakan pada tanggal 15 April 2019; jika Anda membuat cluster baru sebelum tanggal tersebut, Anda harus menentukan versi yang di-patch agar dapat digunakan. Pelanggan GKE yang telah mengaktifkan upgrade node otomatis, dan yang tidak mengupgrade secara manual, akan diupgrade secara otomatis ke versi yang di-patch pada minggu berikutnya. Versi yang Di-patch: 1.10.12-gke.14 1.11.6-gke.16 1.11.7-gke.18 1.11.8-gke.6 1.12.6-gke.10 1.13.4-gke.10 Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: CVE-2019-9900 dan CVE-2019-9901. Anda dapat membaca selengkapnya di blog Istio.	Tinggi	CVE-2019-9900 CVE-2019-9901.

Deskripsi

Keparahan

Notes

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 Anda telah mengaktifkan Istio di Google Kubernetes Engine (GKE), Anda mungkin akan terpengaruh oleh kerentanan ini. Sebaiknya upgrade cluster Anda yang terpengaruh ke versi patch terbaru secepatnya, dan upgrade file bantuan Istio Anda (petunjuknya di bawah).

Apa yang sebaiknya saya lakukan?

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

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

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

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

Versi yang Di-patch:

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

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

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

Tinggi

1 Maret 2019

Deskripsi	Keparahan	Notes
Update 22-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 1.12. Lacak ketersediaan beberapa patch ini di catatan rilis. Baru-baru ini Kubernetes menemukan kerentanan baru denial of service CVE-2019-1002100, yang memungkinkan pengguna yang diizinkan membuat permintaan patch untuk membuat permintaan "json-patch" berbahaya yang menghabiskan terlalu banyak CPU dan memori di server Kubernetes API, sehingga berpotensi mengurangi ketersediaan bidang kontrol cluster. Untuk mengetahui detail selengkapnya, lihat pengungkapan Kubernetes. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh kerentanan ini. Versi patch mendatang akan mencakup mitigasi untuk kerentanan ini. Kami akan otomatis mengupgrade master cluster ke versi yang di-patch dalam beberapa minggu mendatang dengan ritme upgrade reguler. Apa yang sebaiknya saya lakukan? Anda tidak perlu melakukan tindakan apa pun. Master GKE akan otomatis diupgrade dengan ritme upgrade reguler. Jika ingin meng-upgrade master lebih cepat, Anda dapat memulai upgrade master secara manual. Kami akan memperbarui buletin ini dengan versi yang berisi patch. Perhatikan bahwa patch hanya akan tersedia dalam versi 1.11+, bukan juga dalam versi 1.10. Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: Kerentanan CVE-2019-1002100 memungkinkan pengguna untuk secara khusus membuat patch jenis "json-patch" yang menghabiskan terlalu banyak CPU di server Kubernetes API, sehingga berpotensi mengurangi ketersediaan bidang kontrol cluster.	Sedang	CVE-2019-1002100

Deskripsi

Keparahan

Notes

Update 22-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 1.12. Lacak ketersediaan beberapa patch ini di catatan rilis.

Baru-baru ini Kubernetes menemukan kerentanan baru denial of service CVE-2019-1002100, yang memungkinkan pengguna yang diizinkan membuat permintaan patch untuk membuat permintaan "json-patch" berbahaya yang menghabiskan terlalu banyak CPU dan memori di server Kubernetes API, sehingga berpotensi mengurangi ketersediaan bidang kontrol cluster. Untuk mengetahui detail selengkapnya, lihat pengungkapan Kubernetes. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh kerentanan ini. Versi patch mendatang akan mencakup mitigasi untuk kerentanan ini. Kami akan otomatis mengupgrade master cluster ke versi yang di-patch dalam beberapa minggu mendatang dengan ritme upgrade reguler.

Apa yang sebaiknya saya lakukan?

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

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

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

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

Sedang

CVE-2019-1002100

11 Februari 2019 (runc)

Deskripsi	Keparahan	Notes
Open Containers Initiative (OCI) baru-baru ini menemukan kerentanan keamanan baru CVE-2019-5736 di runc, yang memungkinkan container escape mendapatkan hak istimewa root di node host. Node Ubuntu Google Kubernetes Engine (GKE) Anda terpengaruh oleh kerentanan ini. Sebaiknya Anda mengupgrade ke patch versi terbaru secepatnya, 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 runc versi baru telah meningkatkan penggunaan memori dan mungkin memerlukan update memori yang dialokasikan ke container jika Anda telah menetapkan batas memori rendah (< 16 MB). Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: CVE-2019-5736 merupakan kerentanan di runc yang mengizinkan container berbahaya (dengan interaksi pengguna minimal dalam bentuk exec) menimpa biner runc host sehingga mendapatkan eksekusi kode level root pada node host. Kerentanan ini tidak memengaruhi container yang tidak dijalankan sebagai root. Kerentanan ini dinilai sebagai kerentanan keparahan 'Tinggi'.	Tinggi	CVE-2019-5736

Deskripsi

Keparahan

Notes

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

Node Ubuntu Google Kubernetes Engine (GKE) Anda terpengaruh oleh kerentanan ini. Sebaiknya Anda mengupgrade ke patch versi terbaru secepatnya, 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 runc versi baru telah meningkatkan penggunaan memori dan mungkin memerlukan update memori yang dialokasikan ke container jika Anda telah menetapkan batas memori rendah (< 16 MB).

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

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

Tinggi

CVE-2019-5736

11 Februari 2019 (Go)

Deskripsi	Keparahan	Notes
Update 25-02-2019: Patch tidak tersedia di 1.11.7-gke.4 seperti yang telah dikomunikasikan sebelumnya. Jika menjalankan versi 1.11.7, Anda dapat: mendowngrade ke 1.11.6, mengupgrade ke 1.12, atau menunggu hingga patch 1.11.7 berikutnya tersedia pada minggu 04-03-2019. Bahasa pemograman Go baru-baru ini menemukan kerentanan keamanan baru CVE-2019-6486, yang merupakan kerentanan Denial of Service (DoS) dalam penerapan crypto/elliptic dari elliptic curve P-521 dan P-384. Pada Google Kubernetes Engine (GKE), kerentanan ini mengizinkan pengguna membuat permintaan berbahaya yang dapat menghabiskan terlalu banyak CPU di server Kubernetes API sehingga berpotensi mengurangi ketersediaan bidang kontrol kluster. Untuk detail selengkapnya, lihat pengungkapan bahasa pemrograman Go. Semua master Google Kubernetes Engine (GKE) terpengaruh oleh Kerentanan ini. Versi patch terbaru mencakup mitigasi untuk kerentanan ini. Secara otomatis kami akan meng-upgrade master kluster ke versi yang sudah di-patch dalam beberapa minggu ke depan dengan ritme upgrade reguler. Apa yang harus saya lakukan? Anda tidak perlu melakukan tindakan apa pun. Master GKE akan otomatis diupgrade dengan ritme upgrade reguler. Jika ingin meng-upgrade master lebih cepat, Anda dapat memulai upgrade master secara manual. Patch ini tersedia dalam GKE 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5, dan rilis yang lebih baru. Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: CVE-2019-6486 adalah kerentanan dalam penerapan crypto/elliptic dari elliptic curve P-521 dan P-384. Dengan kerentanan ini, pengguna dapat membuat input yang menghabiskan terlalu banyak CPU.	Tinggi	CVE-2019-6486

Deskripsi

Keparahan

Notes

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

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

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

Apa yang harus saya lakukan?

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) terkena dampak kerentanan ini, dan kami telah meng-upgrade cluster ke versi patch terbaru. Anda tidak perlu melakukan tindakan apa pun. Apa yang harus saya lakukan? Anda tidak perlu melakukan tindakan apa pun. Master GKE telah diupgrade. Patch ini tersedia dalam GKE 1.9.7-gke.11, 1.10.6-gke.11, 1.10.7-gke.11, 1.10.9-gke.5, and 1.11.2-gke.18 dan rilis yang lebih baru. Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: Kerentanan CVE-2018-1002105 memungkinkan pengguna dengan hak istimewa yang relatif rendah untuk mengabaikan otorisasi ke API kubelet. Hal ini akan memberi pengguna otorisasi untuk membuat permintaan yang dapat diupgrade guna melakukan eskalasi dan melakukan panggilan arbitrer ke API kubelet. Kerentanan ini dinilai sebagai kerentanan kritis di Kubernetes. Mengingat beberapa detail dalam.implementasi GKE yang dapat mencegah lokasi eskalasi yang tidak terautentikasi, kerentanan ini dinilai sebagai kerentanan Tinggi.	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) terkena dampak kerentanan ini, dan kami telah meng-upgrade cluster ke versi patch terbaru. Anda tidak perlu melakukan tindakan apa pun.

Apa yang harus saya lakukan?

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

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

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

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

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 level debug, plugin Calico CNI akan menulis konfigurasi klien Kubernetes API ke dalam log. Calico CNI juga akan menulis token Kubernetes API ke log di level info jika kolom "k8s_auth_token" ditetapkan pada konfigurasi jaringan CNI. Selain itu, saat dijalankan dengan logging level debug, jika token akun layanan ditetapkan secara eksplisit, baik dalam file konfigurasi Calico yang dibaca oleh Calico, maupun sebagai variabel lingkungan yang digunakan oleh Calico, komponen Calico (calico/node, felix, CNI) akan menuliskan 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 level debug, plugin Calico CNI akan menulis konfigurasi klien Kubernetes API ke dalam log.
Calico CNI juga akan menulis token Kubernetes API ke log di level info jika kolom "k8s_auth_token" ditetapkan pada konfigurasi jaringan CNI.
Selain itu, saat dijalankan dengan logging level debug, jika token akun layanan ditetapkan secara eksplisit, baik dalam file konfigurasi Calico yang dibaca oleh Calico, maupun sebagai variabel lingkungan yang digunakan oleh Calico, komponen Calico (calico/node, felix, CNI) akan menuliskan 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. (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. Kumpulan node Kubernetes Engine dengan konfigurasi upgrade otomatis yang belum diaktifkan harus di-upgrade secara manual saat tersedianya versi COS image yang di-patch tersedia.	Tinggi	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.

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

Tinggi

6 Agustus 2018; terakhir diperbarui: 5 September 2018

Deskripsi	Keparahan	Notes
Update 05-09-2018 Baru-baru ini terungkap adanya kerentanan CVE-2018-5391. Seperti halnya CVE-2018-5390, kerentanan ini merupakan kerentanan jaringan tingkat kernel yang meningkatkan efektivitas serangan denial of service (DoS) terhadap sistem yang rentan. Perbedaan utamanya adalah bahwa CVE-2018-5391 dapat dieksploitasi melalui koneksi IP. Kami memperbarui buletin ini untuk mencakup kedua kerentanan ini. Deskripsi CVE-2018-5390 ("SegmentSmack") merupakan kerentanan jaringan tingkat kernel yang meningkatkan efektivitas serangan Denial of Service (DoS) terhadap sistem yang rentan melalui koneksi TCP. CVE-2018-5391 ("FragmentSmack") merupakan kerentanan jaringan tingkat kernel yang meningkatkan efektivitas serangan Denial of Service (DoS) terhadap sistem yang rentan melalui koneksi IP. Dampak Google Kubernetes Engine Mulai 11-08-2018, semua master Kubernetes Engine dilindungi dari kedua kerentanan tersebut. Selain itu, semua kluster Kubernetes Engine dengan konfigurasi upgrade otomatis juga dilindungi dari kedua kerentanan. Kumpulan node Kubernetes Engine yang tidak dikonfigurasi untuk mengupgrade otomatis dan terakhir di-upgrade secara manual sebelum 11-08-2018, terpengaruh oleh kedua kerentanan. Versi yang di-patch Karena keparahan kerentanan ini, kami sarankan untuk mengupgrade node secara manual segera setelah patch tersedia.	Tinggi	CVE-2018-5390 CVE-2018-5391

Deskripsi

Keparahan

Notes

Update 05-09-2018

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

Deskripsi

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

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

Dampak Google Kubernetes Engine

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

Versi yang di-patch

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

Tinggi

30 Mei 2018

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
Baru-baru ini ditemukan kerentanan di Git yang dapat mengizinkan eskalasi hak istimewa dalam Kubernetes jika pengguna yang tidak memiliki hak istimewa diizinkan untuk membuat Pod dengan volume gitRepo. CVE teridentifikasi dengan tag CVE-2018-11235. Apakah saya terpengaruh? Kerentanan akan memengaruhi Anda jika hal-hal berikut ini terjadi: Pengguna tidak tepercaya dapat membuat Pod (atau memicu pembuatan Pod). Pod yang dibuat oleh pengguna tidak tepercaya memiliki batasan yang mencegah akses root host (misalnya, melalui PodSecurityPolicy). Pod yang dibuat oleh pengguna tidak tepercaya diizinkan menggunakan jenis volume gitRepo. Kerentanan ini memengaruhi semua Kubernetes Engine yang rentan. Apa yang harus saya lakukan? Larang penggunaan jenis volume gitRepo. Untuk melarang volume gitRepo dengan PodSecurityPolicy, hapus `gitRepo` dari daftar `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 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	Notes
Baru-baru ini ditemukan beberapa kerentanan di kernel Linux yang dapat mengizinkan eskalasi hak istimewa atau Denial of Service (melalui crash kernel) dari proses yang tidak memiliki hak istimewa. CVE ini diidentifikasi dengan tag CVE-2018-1000199, CVE-2018-8897, dan CVE-2018-1087. Semua node Kubernetes Engine terpengaruh oleh kerentanan ini, dan sebaiknya Anda mengupgrade ke versi patch terbaru, seperti dijelaskan di bawah ini. Apa yang harus saya lakukan? Agar dapat mengupgrade, pertama-tama upgrade master ke versi terbaru. Patch ini tersedia dalam Kubernetes Engine 1.8.12-gke.1, Kubernetes Engine 1.9.7-gke.1, dan Kubernetes Engine 1.10.2-gke.1. Rilis ini mencakup Container-Optimized OS dan Ubuntu image. Jika sebelumnya telah membuat kluster baru, Anda harus menetapkan versi yang di-patch agar kluster dapat digunakan. Pelanggan dengan konfigurasi upgrade node otomatis yang aktif dan pelanggan yang tidak meng-upgrade secara manual, node-nya akan diupgrade menjadi versi yang di-patch dalam beberapa minggu mendatang. Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi jenis kerentanan berikut: CVE-2018-1000199: Kerentanan ini memengaruhi kernel Linux. Kerentanan ini memungkinkan pengguna atau proses yang tidak memiliki hak istimewa menyebabkan eror pada sistem kernel, yang mengarah ke serangan DoS atau eskalasi akses. Kerentanan ini dinilai sebagai kerentanan Tinggi dengan CVSS sebesar 7,8. CVE-2018-8897: Kerentanan ini memengaruhi kernel Linux. Kerentanan ini mengizinkan pengguna atau proses yang tidak memiliki hak istimewa menyebabkan eror pada sistem kernel dan mengarah ke serangan DoS. Kerentanan ini dinilai sebagai kerentanan Sedang, dengan CVSS sebesar 6,5. CVE-2018-1087: Kerentanan ini memengaruhi hypervisor KVM kernel Linux. Kerentanan ini mengizinkan proses yang tidak memiliki hak istimewa menyebabkan error pada kernel tamu atau untuk mendapatkan hak istimewa. Kerentanan ini di-patch di dalam infrastruktur tempat dijalankannya Kubernetes Engine, sehingga Kubernetes Engine tidak terpengaruh. Kerentanan ini dinilai sebagai kerentanan Tinggi, dengan skor CVSS seebsar 8,0.	Tinggi	CVE-2018-1000199 CVE-2018-8897 CVE-2018-1087

Deskripsi

Keparahan

Notes

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

Apa yang harus saya lakukan?

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

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

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch ini mengurangi jenis kerentanan berikut:

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

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

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

Tinggi

12 Maret 2018

Deskripsi	Keparahan	Notes
Project Kubernetes baru-baru ini mengungkapkan kerentanan keamanan baru, CVE-2017-1002101 dan CVE-2017-1002102, yang mengizinkan container mengakses file di luar container. Kerentanan ini memengaruhi semua node Kubernetes Engine. Kami sarankan untuk mengupgrade ke versi patch terbaru secepatnya, seperti dijelaskan di bawah ini: Apa yang harus saya lakukan? Baik upgrade node otomatis telah diaktifkan atau belum, karena keparahan kerentanan ini, kami sarankan untuk mengupgrade node secara manual segera setelah patch tersedia. Patch ini akan tersedia untuk semua pelanggan pada 16 Maret, tetapi dapat tersedia lebih cepat berdasarkan zona cluster Anda, sesuai dengan jadwal rilis. Agar dapat mengupgrade, pertama-tama upgrade master ke versi terbaru. Patch ini tersedia dalam Kubernetes Engine 1.9.4-gke.1, Kubernetes 1.8.9-gke.1, dan Kubernetes 1.7.14-gke.1. Kluster baru akan menggunakan versi yang di-patch secara default pada 30 Maret, jika sebelumnya Anda telah membuat kluster baru, tetapkan versi yang di-patch agar kluster dapat digunakan. Pelanggan Kubernetes Engine yang telah mengaktifkan konfigurasi upgrade node otomatis dan yang tidak mengupgrade secara manual, node-nya akan di-upgrade menjadi versi yang di-patch pada 23 April. Namun, karena sifat kerentanan, sebaiknya Anda mengupgrade node secara manual segera setelah patch tersedia. Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch mengurangi dua kerentanan berikut: Kerentanan CVE-2017-1002101 mengizinkan container menggunakan pemasangan volume sublokasi guna mengakses file di luar volume. Artinya, jika Anda memblokir akses container ke volume hostpath dengan PodSecurityPolicy, penyerang dengan kemampuan memperbarui atau membuat pod dapat memasang hostpath apa pun menggunakan jenis volume lainnya. Kerentanan CVE-2017-1002102 mengizinkan container menggunakan jenis volume tertentu - termasuk rahasia, config map, volume terproyeksi, atau volume downward API - untuk menghapus file di luar volume. Artinya, jika container yang menggunakan salah satu jenis volume ini disusupi atau jika Anda mengizinkan pengguna tidak tepercaya untuk membuat pod, penyerang dapat menggunakan container tersebut untuk menghapus file arbitrer di host. Untuk mempelajari selengkapnya tentang perbaikan, baca entri blog Kubernetes.	Tinggi	CVE-2017-1002101 CVE-2017-1002102

Deskripsi

Keparahan

Notes

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

Apa yang harus saya lakukan?

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

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

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

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

Patch mengurangi dua kerentanan berikut:

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

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

Untuk mempelajari selengkapnya tentang perbaikan, baca entri blog Kubernetes.

Tinggi

GKE di buletin keamanan VMware

16 Oktober 2019

Deskripsi	Keparahan	Notes
Baru-baru ini, sebuah kerentanan ditemukan di Kubernetes, yang dijelaskan dalam CVE-2019-11253, yang memungkinkan setiap pengguna yang diizinkan membuat permintaan POST untuk mengeksekusi serangan Denial-of-Service jarak jauh pada server Kubernetes API. Komite Keamanan Produk (PSC) Kubernetes merilis informasi tambahan tentang kerentanan ini yang dapat ditemukan di sini. Anda dapat memitigasi kerentanan ini dengan membatasi klien yang memiliki akses jaringan ke server Kubernetes API Anda. Apa yang sebaiknya saya lakukan? Sebaiknya upgrade cluster Anda ke versi patch yang berisi perbaikan segera setelah perbaikan tersedia. Versi patch yang akan berisi perbaikan tercantum di bawah ini: GKE Enterprise 1.1.1, yang menjalankan Kubernetes versi 1.13.7-gke.30 Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi kerentanan berikut: CVE-2019-11253.	Tinggi	CVE-2019-11253

Deskripsi

Keparahan

Notes

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

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

Apa yang sebaiknya saya lakukan?

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

Versi patch yang akan berisi perbaikan tercantum di bawah ini:

GKE Enterprise 1.1.1, yang menjalankan Kubernetes versi 1.13.7-gke.30

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

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

Tinggi

CVE-2019-11253

23 Agustus 2019

Deskripsi Keparahan Notes

Deskripsi	Keparahan	Notes
Baru-baru ini kami menemukan dan melakukan mitigasi kerentanan saat proxy RBAC yang digunakan untuk mengamankan endpoint pemantauan tidak memberikan otorisasi dengan benar kepada pengguna. Akibatnya, metrik dari komponen tertentu tersedia bagi pengguna yang tidak sah 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 sebaiknya saya lakukan? Sebaiknya upgrade cluster Anda ke versi 1.0.2-gke.3, yang menyertakan patch untuk kerentanan ini, sesegera mungkin.	Sedang	Rilis GKE di VMware

Baru-baru ini kami menemukan dan melakukan mitigasi kerentanan saat proxy RBAC yang digunakan untuk mengamankan endpoint pemantauan tidak memberikan otorisasi dengan benar kepada pengguna. Akibatnya, metrik dari komponen tertentu tersedia bagi pengguna yang tidak sah 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 sebaiknya saya lakukan?

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

Sedang

Rilis GKE di VMware

22 Agustus 2019

Deskripsi	Keparahan	Notes
Baru-baru ini Kubernetes menemukan kerentanan, CVE-2019-11247, yang memungkinkan instance resource kustom cakupan cluster ditindaklanjuti seolah-olah instance tersebut adalah objek dengan namespace yang ada di semua Namespace. Artinya, akun pengguna dan layanan yang hanya memiliki izin RBAC tingkat namespace dapat berinteraksi dengan resource kustom cakupan cluster. Mengeksploitasi kerentanan ini mengharuskan penyerang memiliki hak istimewa untuk mengakses resource di namespace mana pun. Apa yang sebaiknya saya lakukan? Sebaiknya upgrade cluster Anda ke versi 1.0.2-gke.3, yang menyertakan patch untuk kerentanan ini, sesegera mungkin. Jenis kerentanan apa yang dapat diatasi oleh patch ini? Patch ini mengurangi kerentanan berikut: CVE-2019-11247.	Sedang	CVE-2019-11247

Deskripsi

Keparahan

Notes

Apa yang sebaiknya saya lakukan?

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

Jenis kerentanan apa yang dapat diatasi oleh patch ini?

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

Sedang

CVE-2019-11247