Keamanan bidang kontrol

Halaman ini menjelaskan cara Google Kubernetes Engine (GKE) mengamankan komponen bidang kontrol cluster Anda. Pelajari fitur keamanan yang disertakan dalam GKE, yang mencakup OS yang diperkuat dengan keamanan, arsitektur dan isolasi yang andal, akses bidang kontrol yang aman, keamanan etcd, otoritas sertifikat dan kepercayaan cluster, pengelolaan patch dan kerentanan.

Halaman ini ditujukan bagi Spesialis keamanan yang ingin memahami cara Google mengelola komponen bidang kontrol GKE dan langkah-langkah keamanan yang diterapkan untuk menilai risiko secara efektif dan memastikan keamanan deployment GKE Anda. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.

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 agen layanan 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.

  • Log audit: Logging audit diaktifkan secara default. Logging audit ini menyediakan data mendetail, yang tersedia di Google Cloud Observability, terkait 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.

  • Integritas image VM panel kontrol: GKE menambahkan log mendetail untuk pembuatan VM node dan peristiwa booting ke Cloud Logging. Selain itu, kami memublikasikan VSA SLSA di GitHub yang sesuai dengan image mesin node pekerja dan bidang kontrol. Anda dapat memverifikasi bahwa VM menggunakan image OS yang memiliki VSA yang sesuai dan memverifikasi integritas booting setiap VM bidang kontrol.

    Untuk melakukan verifikasi integritas VM, lihat Memverifikasi integritas VM bidang kontrol GKE.

Yang dapat Anda konfigurasi

Meskipun GKE mengelola sebagian besar bidang kontrol untuk Anda, Anda dapat mengontrol hal berikut:

  • Akses ke bidang kontrol: Bidang kontrol memiliki dua jenis endpoint untuk akses cluster:

    • Endpoint berbasis DNS
    • Endpoint berbasis IP

    Secara default, server Kubernetes API menggunakan alamat IP eksternal. Anda dapat melindungi server Kubernetes API dengan mengaktifkan endpoint berbasis DNS untuk akses ke bidang kontrol. Anda dapat mengontrol siapa yang dapat mengakses endpoint DNS dengan Kontrol Layanan VPC yang memungkinkan Anda menentukan satu parameter keamanan untuk semua API Google di project Anda. Jika menggunakan endpoint berbasis IP untuk akses bidang kontrol, sebaiknya gunakan jaringan yang diizinkan dan nonaktifkan akses di endpoint eksternal bidang kontrol. Untuk mengetahui informasi selengkapnya tentang isolasi jaringan, lihat Tentang menyesuaikan isolasi jaringan.

  • Autentikasi: Anda dapat menangani autentikasi cluster di GKE menggunakan IAM sebagai penyedia identitas. Untuk keamanan autentikasi yang ditingkatkan, autentikasi dasar dan penerbitan sertifikat klien dinonaktifkan secara default.

  • Rotasi kredensial: Rotasi certificate authority (CA) cluster dan sertifikat TLS secara rutin dengan melakukan rotasi kredensial. GKE juga merotasi alamat IP server Kubernetes API Anda selama proses ini. Untuk mengetahui informasi selengkapnya, lihat rotasi kredensial.

Selain itu, jika organisasi Anda memiliki persyaratan kepatuhan atau kebijakan yang ketat terkait bidang kontrol, otoritas bidang kontrol GKE adalah serangkaian fitur yang memberi Anda visibilitas dan kontrol yang ditingkatkan atas aspek tertentu dari bidang kontrol, termasuk hal berikut:

  • Jalankan CA dan kunci Anda sendiri untuk penerbitan identitas menggunakan Cloud KMS dan Layanan CA.
  • Mengenkripsi disk booting etcd dan bidang kontrol menggunakan kunci Anda sendiri di Cloud KMS.

Untuk mengetahui detail tentang alasan Anda menggunakan fitur ini dan semua kemampuan yang tersedia, lihat Tentang otoritas bidang kontrol GKE.

Langkah selanjutnya