Halaman ini menjelaskan model kepercayaan di cluster Google Kubernetes Engine (GKE), termasuk komunikasi dalam cluster dan cara permintaan diautentikasi untuk komponen seperti bidang kontrol.
Dokumen ini ditujukan untuk Spesialis keamanan yang ingin memahami model kepercayaan cluster GKE. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud , lihat Tugas dan peran pengguna GKE Enterprise umum.
Sebelum membaca halaman ini, pastikan Anda memahami hal-hal berikut:
Komunikasi intracluster
GKE menerapkan berbagai mekanisme keamanan ke traffic antar-komponen cluster, sebagai berikut:
Traffic antara bidang kontrol dan node: bidang kontrol berkomunikasi dengan node untuk mengelola penampung. Saat bidang kontrol mengirimkan permintaan, (misalnya,
kubectl logs) ke node, permintaan tersebut akan dikirim melalui tunnel proxy Konnectivity. Permintaan yang dikirim oleh bidang kontrol diautentikasi dan dilindungi oleh TLS. Saat node mengirim permintaan ke bidang kontrol, misalnya, dari kubelet ke server API, permintaan tersebut akan diautentikasi dan dienkripsi menggunakan TLS bersama (mTLS).Semua cluster yang baru dibuat dan diperbarui menggunakan TLS 1.3 untuk komunikasi bidang kontrol ke node. TLS 1.2 adalah versi minimum yang didukung untuk komunikasi bidang kontrol ke node.
Traffic antar-node: node adalah VM Compute Engine. Koneksi antara node di dalam jaringan produksi Google Cloud diautentikasi dan dienkripsi. Untuk mengetahui detailnya, lihat bagian VM ke VM dalam laporan resmi Enkripsi dalam Transit.
Traffic antar-Pod: saat Pod mengirim permintaan ke Pod lain, traffic tersebut tidak diautentikasi secara default. GKE mengenkripsi traffic antar-Pod di node yang berbeda pada lapisan jaringan. Traffic antar-Pod di node yang sama tidak dienkripsi secara default. Untuk mengetahui detail tentang enkripsi lapisan jaringan, lihat Google Cloud enkripsi dan autentikasi jaringan virtual.
Anda dapat membatasi traffic Pod ke Pod dengan NetworkPolicy, dan Anda dapat mengenkripsi semua traffic Pod ke Pod, termasuk traffic di node yang sama, dengan menggunakan mesh layanan seperti Cloud Service Mesh atau metode enkripsi lapisan aplikasi yang berbeda.
Traffic antara komponen bidang kontrol: traffic antara berbagai komponen yang berjalan di bidang kontrol diautentikasi dan dienkripsi menggunakan TLS. Traffic tidak pernah meninggalkan jaringan milik Google yang dilindungi oleh firewall.
Root of trust
GKE memiliki konfigurasi berikut:
- Cluster root Certificate Authority (CA) digunakan untuk memvalidasi
server API dan sertifikat klien kubelet. Hal ini berarti bidang kontrol dan node memiliki root of trust yang sama. Setiap kubelet dalam node pool cluster dapat meminta sertifikat dari CA ini menggunakan
certificates.k8s.ioAPI, dengan mengirim permintaan penandatanganan sertifikat. Root CA memiliki masa berlaku terbatas seperti yang dijelaskan di bagian Masa aktif root CA cluster. - Di cluster yang menjalankan instance database etcd di VM bidang kontrol, CA peer etcd per cluster yang terpisah digunakan untuk membangun kepercayaan di antara instance etcd.
- Di semua cluster GKE, CA etcd API terpisah digunakan untuk membangun kepercayaan antara server Kubernetes API dan etcd API.
Server API dan kubelet
Server API dan kubelet mengandalkan root CA cluster untuk kepercayaan. Di GKE, sertifikat API bidang kontrol ditandatangani oleh root CA cluster. Setiap cluster menjalankan CA-nya sendiri, sehingga jika CA di satu cluster disusupi, CA di cluster lain tidak akan terpengaruh.
Layanan internal mengelola kunci root untuk CA ini, dan kunci tersebut tidak dapat diekspor. Layanan ini menerima permintaan penandatanganan sertifikat, termasuk yang berasal dari kubelet di setiap cluster GKE. Meskipun server API di sebuah cluster disusupi, CA tidak akan disusupi, sehingga tidak ada cluster lain yang akan terpengaruh.
Setiap node dalam cluster diinjeksi dengan rahasia bersama pada saat pembuatan, yang dapat digunakan untuk mengirim permintaan penandatanganan sertifikat ke root CA cluster dan mendapatkan sertifikat klien kubelet. Sertifikat ini kemudian digunakan oleh kubelet untuk mengautentikasi permintaannya ke server API. Rahasia bersama ini dapat dijangkau oleh Pod di node, kecuali jika Anda mengaktifkan Shielded GKE Node atau Workload Identity Federation for GKE.
Masa aktif root CA cluster
CA root cluster memiliki masa berlaku terbatas. Setelah masa berlaku tersebut, sertifikat yang ditandatangani oleh CA akan menjadi tidak valid. Periksa perkiraan tanggal habis masa berlaku CA cluster dengan mengikuti petunjuk di Memeriksa masa berlaku kredensial.
Sebaiknya Anda merotasi kredensial secara manual sebelum root CA yang ada berakhir. Jika CA berakhir dan Anda tidak merotasi kredensial, cluster dapat memasuki status yang tidak dapat dipulihkan. GKE memiliki mekanisme berikut untuk mencoba dan mencegah agar cluster tidak memasuki status tidak dapat dipulihkan:
- Cluster Anda memasuki status
DEGRADEDtujuh hari sebelum masa berlaku CA habis GKE mencoba melakukan rotasi kredensial otomatis 30 hari sebelum masa berlaku CA habis. Rotasi otomatis ini mengabaikan masa pemeliharaan dan dapat menyebabkan gangguan saat GKE membuat ulang node untuk menggunakan kredensial baru. Klien eksternal, seperti kubectl di lingkungan lokal, tidak akan berfungsi sebelum Anda memperbaruinya untuk menggunakan kredensial baru.
Untuk mempelajari cara melakukan rotasi, lihat Merotasi kredensial cluster.
Penyimpanan status cluster
Cluster GKE menyimpan status objek Kubernetes API sebagai pasangan nilai kunci dalam database. Server Kubernetes API di bidang kontrol Anda berinteraksi dengan database ini menggunakan etcd API. GKE menggunakan salah satu teknologi berikut untuk menjalankan database status cluster:
- etcd: cluster menggunakan instance etcd yang berjalan di VM bidang kontrol.
- Spanner: cluster menggunakan database Spanner yang berjalan di luar VM bidang kontrol.
Terlepas dari teknologi database yang digunakan cluster, setiap cluster GKE menayangkan etcd API di bidang kontrol. Untuk mengenkripsi traffic yang melibatkan database status cluster, GKE menggunakan satu atau kedua CA per cluster berikut:
- CA etcd API: digunakan untuk menandatangani sertifikat untuk traffic ke dan dari endpoint etcd API. CA etcd API berjalan di setiap cluster GKE.
- CA peer etcd: digunakan untuk menandatangani sertifikat untuk traffic antar-instance database etcd di bidang kontrol. CA peer etcd berjalan di cluster apa pun yang menggunakan database etcd. Cluster yang menggunakan database Spanner tidak menggunakan CA peer etcd.
Kunci root untuk CA etcd API didistribusikan ke metadata setiap instance Compute Engine tempat bidang kontrol berjalan. CA etcd API tidak dibagikan antar-cluster.
Sertifikat CA etcd berlaku selama lima tahun. GKE secara otomatis merotasi sertifikat ini sebelum masa berlakunya habis.
Rotasi sertifikat
Untuk merotasi semua sertifikat server API dan kubelet cluster Anda, jalankan rotasi kredensial. Anda tidak dapat memicu rotasi sertifikat etcd; rotasi ini dikelola di GKE.