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 di-hardening keamanannya, arsitektur dan isolasi yang andal, akses platform kontrol yang aman, keamanan untuk database status cluster berbasis etcd atau Spanner, otoritas sertifikasi dan kepercayaan cluster, serta 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 objek Kubernetes API, dan pengontrol lainnya. Google bertanggung jawab mengamankan bidang kontrol, meskipun Anda mungkin dapat mengonfigurasi opsi tertentu berdasarkan persyaratan Anda. Anda bertanggung jawab untuk 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 database status cluster

Di Google Cloud, konten pelanggan mengenkripsi pada lapisan sistem file secara default. Enkripsi ini mencakup infrastruktur yang menghosting database berbasis etcd atau Spanner yang menyimpan status objek Kubernetes API di cluster Anda. Untuk mengetahui informasi selengkapnya tentang database status cluster, lihat arsitektur cluster GKE.

Database status cluster menyimpan konfigurasi setiap objek Kubernetes API di cluster Anda sebagai key-value pair. GKE menggunakan port TCP tertentu di VM bidang kontrol untuk jenis komunikasi berikut dengan database status cluster:

  • Klien API etcd: GKE menyalurkan API etcd di setiap VM bidang kontrol. Klien API etcd di bidang kontrol, seperti server Kubernetes API, menggunakan salah satu port berikut:

    • Port 2379: port ini digunakan saat GKE menyimpan status cluster di instance database etcd yang berjalan di setiap VM bidang kontrol.
    • Port 3379: port ini digunakan saat GKE menyimpan status cluster dalam database Spanner yang terpisah dari bidang kontrol.

    Port yang digunakan klien API etcd terikat dengan antarmuka jaringan loopback lokal dan hanya dapat diakses dari VM panel kontrol yang menjalankan server Kubernetes API.

  • Instance database etcd: jika VM bidang kontrol menjalankan instance database etcd, server API etcd di setiap VM akan menggunakan port 2380 untuk berkomunikasi satu sama lain. Traffic di port 2380 antara instance database etcd di beberapa VM bidang kontrol (seperti di cluster regional) dienkripsi oleh TLS bersama. Dengan TLS bersama, setiap server harus membuktikan identitasnya kepada server lainnya.

    Port 2380 tidak digunakan di cluster yang menyimpan status cluster di database Spanner karena database tidak berjalan di VM platform kontrol.

Certificate authority dan kepercayaan cluster

Setiap cluster memiliki root certificate authority (CA) sendiri. Layanan Google internal mengelola kunci root untuk CA ini. Kunci root untuk CA ini didistribusikan ke metadata VM yang menjalankan server Kubernetes API. Komunikasi antara node dan server Kubernetes API dilindungi oleh TLS. Setiap cluster juga memiliki CA sendiri untuk API etcd dan, jika cluster menjalankan instance database etcd, untuk traffic antar-instance etcd. Untuk 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 konsolGoogle 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 berikutnya