Keamanan bidang kontrol

Dokumen ini menjelaskan cara Google Kubernetes Engine (GKE) mengamankan komponen bidang kontrol cluster Anda.

Google mengelola komponen bidang kontrol GKE untuk Anda di bagian Model Tanggung Jawab Bersama. Bidang kontrol mencakup server Kubernetes API, penyimpanan etcd, dan pengontrol lainnya. Google bertanggung jawab mengamankan bidang kontrol meskipun Anda mungkin dapat mengonfigurasi opsi tertentu berdasarkan persyaratan Anda. Anda bertanggung jawab mengamankan node, container, dan Pod.

Sistem operasi yang telah melalui proses hardening

Komponen bidang kontrol GKE dijalankan di Container-Optimized OS, yang merupakan sistem operasi yang diperkuat dengan keamanan yang dirancang oleh Google. Untuk deskripsi mendetail tentang fitur keamanan yang disertakan dalam Container-Optimized OS, lihat Ringkasan keamanan Container-Optimized OS.

Arsitektur dan isolasi

Di cluster GKE, komponen bidang kontrol berjalan pada instance Compute Engine milik Google, dalam project yang dikelola Google. Setiap instance menjalankan komponen ini hanya untuk satu cluster.

Untuk mengetahui detail cara komponen cluster melakukan autentikasi satu sama lain, lihat Kepercayaan cluster.

Mengakses bidang kontrol ke project Anda

GKE menggunakan akun layanan yang dikelola Google yang bernama Agen Layanan Kubernetes Engine untuk mengaktifkan resource cluster atas nama Anda, seperti node, disk, dan load balancer. Akun layanan diberi peran Agen Layanan Kubernetes Engine secara otomatis (roles/container.serviceAgent)di project Anda.

Agen Layanan Kubernetes Engine memiliki alamat email berikut:

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

Dalam alamat email ini, PROJECT_NUMBER adalah nomor project Anda.

Mengakses administratif ke cluster

Log audit pada sesi SSH oleh Google Site Reliability Engineer dilakukan melalui infrastruktur audit internal Google, yang tersedia untuk forensik dan respons keamanan. Untuk informasi selengkapnya, lihat Akses administratif di Laporan Resmi Keamanan Google.

keamanan etcd

Di Google Cloud, konten pelanggan dienkripsi pada lapisan sistem file secara default. Oleh karena itu, disk yang menghosting penyimpanan etcd untuk cluster GKE dienkripsi pada lapisan sistem file. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dalam penyimpanan.

dlld memproses dua porta TCP. Port 2379 ditujukan untuk klien etcd, seperti server Kubernetes API. Port 2379 terikat dengan antarmuka jaringan loopback lokal sehingga hanya dapat diakses dari VM yang menjalankan server Kubernetes API. Porta 2380 ditujukan untuk komunikasi server ke server. Traffic di porta 2380 dienkripsi oleh TLS bersama. Artinya, setiap server harus saling membuktikan identitasnya. Dalam cluster regional, komunikasi antara server dlld untuk menetapkan kuorum dienkripsi oleh TLS bersama.

Certificate authority dan kepercayaan cluster

Setiap cluster memiliki root certificate authority (CA) sendiri. Layanan Google internal mengelola kunci root untuk CA ini. Setiap cluster juga memiliki CA sendiri untuk etcd. Kunci root untuk CA etcd didistribusikan ke metadata VM yang menjalankan server Kubernetes API. Komunikasi antara node dan server Kubernetes API dilindungi oleh TLS. Untuk mengetahui informasi selengkapnya, lihat Kepercayaan cluster.

Kerentanan dan pengelolaan patch

GKE mematuhi standar Google dalam melakukan pengujian, kualifikasi, dan secara bertahap meluncurkan perubahan pada bidang kontrol. Penggunaan standar ini membantu mengurangi risiko ketidaktersediaan komponen bidang kontrol. GKE mematuhi perjanjian tingkat layanan yang mendefinisikan banyak aspek ketersediaan.

Komponen bidang kontrol GKE dikelola oleh tim Site Reliability Engineering Google, dan selalu diupdate dengan patch keamanan terbaru. Ini termasuk patch untuk sistem operasi host, komponen Kubernetes, dan container yang berjalan di VM bidang kontrol.

GKE akan segera menerapkan perbaikan level kernel, OS, dan Kubernetes baru untuk mengontrol VM bidang. Jika memuat perbaikan untuk kerentanan umum, informasi tambahan akan tersedia di buletin keamanan GKE. GKE memindai kerentanan di semua sistem Kubernetes dan container khusus GKE menggunakan Artifact Analysis, serta menjaga container tetap di-patch sehingga dapat memberikan manfaat bagi seluruh ekosistem Kubernetes.

Engineer Google ikut terlibat dalam menemukan, memperbaiki, dan mengungkapkan bug keamanan Kubernetes. Google juga membayar peneliti keamanan eksternal, melalui program reward kerentanan di seluruh Google untuk menemukan bug keamanan. Dalam beberapa kasus, seperti kerentanan dnsmasq pada Oktober 2017, GKE dapat mem-patch semua cluster yang berjalan sebelum kerentanan tersebut dipublikasikan.

Yang dapat Anda lihat

Fitur keamanan yang dibahas sebelumnya dalam topik ini dikelola oleh Google. Bagian ini dan bagian berikutnya membahas fitur keamanan yang dapat Anda pantau dan konfigurasi.

Logging audit diaktifkan secara default untuk cluster yang dibuat sejak GKE versi 1.8.3. Hal ini menyediakan data mendetail, yang tersedia di Kemampuan Observabilitas Google Cloud, tentang panggilan yang dilakukan ke server Kubernetes API. Anda dapat melihat entri log di Logs Explorer di konsol Google Cloud. Anda juga dapat menggunakan BigQuery untuk melihat dan menganalisis log ini.

Yang dapat Anda konfigurasi

Secara default, server Kubernetes API menggunakan alamat IP publik. Anda dapat melindungi server Kubernetes API menggunakan jaringan yang diizinkan dan cluster pribadi sehingga Anda dapat menetapkan alamat IP pribadi ke Kubernetes Server API dan menonaktifkan akses pada alamat IP publik.

Anda dapat menangani autentikasi cluster di GKE menggunakan IAM sebagai penyedia identitas. Untuk keamanan autentikasi yang disempurnakan, autentikasi dasar dan penerbitan sertifikat klien dinonaktifkan secara default untuk cluster yang dibuat menggunakan GKE versi 1.12 dan yang lebih baru.

Anda dapat meningkatkan keamanan bidang kontrol dengan rutin melakukan rotasi kredensial. Saat rotasi kredensial dimulai, sertifikat TLS dan certificate authority cluster akan otomatis dirotasi. GKE juga merotasi alamat IP server Kubernetes API. Untuk mengetahui informasi selengkapnya, lihat Role-Based Access Control (RBAC) dan Rotasi kredensial.