Halaman ini menjelaskan kepercayaan pada cluster Google Kubernetes Engine (GKE), termasuk bagaimana bidang kontrol dan node mengautentikasi permintaan.
Komunikasi intracluster
Ada banyak koneksi dalam cluster untuk komunikasi antarkomponen Kubernetes.
- Bidang kontrol ke node
Bidang kontrol berkomunikasi dengan node untuk mengelola container. Saat bidang kontrol mengirimkan permintaan, misalnya,
kubectl logs, ke node dalam cluster publik, permintaan tersebut akan dikirim melalui tunnel Proxy Konnectivity. Permintaan ke node dalam cluster pribadi dikirim melalui Peering VPC. Permintaan yang dikirim oleh bidang kontrol dilindungi dengan TLS, yang menyediakan autentikasi, integritas, dan enkripsi. Saat sebuah node mengirim permintaan ke bidang kontrol, misalnya, dari kubelet ke server API, permintaan tersebut akan diautentikasi dan dienkripsi menggunakan TLS bersama.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.
- Node ke node
Node adalah VM Compute Engine tempat koneksi di dalam jaringan produksi Google diautentikasi dan dienkripsi. Untuk mengetahui detailnya, lihat bagian VM ke VM dalam laporan resmi Enkripsi dalam Transit.
- Pod ke Pod
Saat sebuah Pod mengirim permintaan ke Pod lain, traffic tersebut tidak diautentikasi secara default. GKE mengenkripsi traffic antar-Pod di node berbeda pada lapisan jaringan. Traffic antar-Pod di node yang sama tidak dienkripsi secara default. Untuk penjelasan tentang enkripsi lapisan jaringan, lihat Enkripsi dan autentikasi jaringan virtual Google Cloud.
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 sepertiAnthos Service Mesh atau metode enkripsi lapisan aplikasi yang berbeda.
- etcd ke etcd
Sebuah instance etcd dapat berkomunikasi dengan instance etcd lain untuk mempertahankan agar status selalu diperbarui. Saat sebuah instance etcd mengirim permintaan ke instance lain, permintaan tersebut akan diautentikasi dan dienkripsi menggunakan TLS bersama. Traffic tidak pernah meninggalkan jaringan milik GKE yang dilindungi oleh firewall.
- Bidang kontrol ke etcd
Pada GKE versi 1.23.6-gke.1100 dan yang lebih baru, komunikasi ini dienkripsi menggunakan TLS bersama.
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. - CA etcd per-cluster yang terpisah digunakan untuk memvalidasi sertifikat etcd.
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 Google 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 Nodes, Workload Identity Federation for GKE, atau penyembunyian metadata.
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.
etcd
Di GKE, etcd mengandalkan CA etcd per cluster terpisah untuk kepercayaan.
Kunci root untuk CA etcd didistribusikan ke metadata setiap virtual machine (VM) tempat bidang kontrol berjalan. Setiap kode yang dieksekusi di VM bidang kontrol, atau yang memiliki akses ke metadata komputasi untuk VM ini, dapat menandatangani sertifikat sebagai CA ini. Bahkan jika etcd di sebuah cluster disusupi, CA tidak dibagikan antar-cluster, sehingga tidak ada cluster lain yang terdampak.
Sertifikat etcd berlaku selama lima tahun.
Merotasi 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.