Kepercayaan cluster

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, permintaan tersebut akan dikirim melalui tunnel proxy Konnectivity. Permintaan yang dikirim oleh bidang kontrol dilindungi dengan TLS, yang menyediakan autentikasi, integritas, dan enkripsi. Saat 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 Cloud 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 seperti Cloud 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

Komunikasi ini dienkripsi menggunakan TLS timbal balik.

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.io API, 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 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 DEGRADED tujuh 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.

Langkah berikutnya