Merotasi certificate authority cluster pengguna

GKE di VMware menggunakan sertifikat dan kunci pribadi untuk mengautentikasi dan mengenkripsi koneksi antara komponen sistem di cluster pengguna. Cluster admin membuat kumpulan certificate authority (CA) baru untuk setiap cluster pengguna, dan menggunakan sertifikat CA ini untuk menerbitkan leaf certificate tambahan untuk komponen sistem. Cluster admin mengelola distribusi sertifikat CA publik dan pasangan kunci leaf certificate ke komponen sistem, untuk membangun komunikasi yang aman.

Dengan fitur rotasi CA cluster pengguna, Anda dapat memicu rotasi sertifikat sistem inti dalam cluster pengguna. Selama rotasi, cluster admin mengganti CA sistem inti untuk cluster pengguna dengan CA yang baru dibuat, dan mendistribusikan pasangan kunci sertifikat CA publik baru dan sertifikat leaf ke komponen sistem cluster pengguna. Rotasi terjadi secara bertahap sehingga komponen sistem dapat terus berkomunikasi selama rotasi. Namun, perhatikan bahwa workload dan node akan dimulai ulang selama rotasi.

Ada tiga CA sistem yang dikelola oleh cluster admin untuk setiap cluster pengguna:

CA etcd mengamankan komunikasi dari server API ke replika etcd dan juga traffic antara replika etcd. CA ini ditandatangani sendiri.
CA cluster mengamankan komunikasi antara server API dan semua klien Kubernetes API internal (kubelets, pengontrol, penjadwal). CA ini ditandatangani sendiri.
CA front-proxy mengamankan komunikasi dengan API agregat. CA ini ditandatangani sendiri.

Anda juga dapat menggunakan CA org untuk menandatangani sertifikat yang dikonfigurasi oleh opsi authentication.sni. CA ini dan sertifikat SNI digunakan untuk menyalurkan Kubernetes API ke klien di luar cluster. Anda mengelola CA ini dan membuat sertifikat SNI secara manual. CA ini maupun sertifikat SNI tidak terpengaruh oleh fitur rotasi CA cluster pengguna.

Batasan

Fitur rotasi CA cluster pengguna didukung di cluster Anthos di cluster VMware versi 1.8 dan yang lebih baru.
Fitur rotasi CA cluster pengguna secara khusus dibatasi untuk CA etcd, cluster, dan front-proxy yang disebutkan dalam ringkasan. Fitur ini tidak merotasi CA organisasi Anda. Fitur rotasi CA cluster pengguna juga terbatas pada sertifikat yang diterbitkan secara otomatis oleh cluster Anthos di VMware. API ini tidak mengupdate sertifikat yang diterbitkan secara manual oleh administrator, meskipun sertifikat tersebut ditandatangani oleh CA sistem.
Rotasi CA harus memulai ulang server API, proses bidang kontrol lainnya, dan setiap node dalam cluster beberapa kali. Setiap tahap rotasi CA berlangsung mirip dengan upgrade cluster. Meskipun cluster pengguna tetap beroperasi selama rotasi CA, Anda harus memperkirakan bahwa workload akan dimulai ulang dan dijadwalkan ulang. Anda juga akan mengalami periode singkat periode nonaktif jika tidak menggunakan konfigurasi HA.
File kubeconfig cluster pengguna dan file konfigurasi autentikasi agar terhubung ke cluster pengguna harus diperbarui dan didistribusikan ulang secara manual setelah rotasi CA. Hal ini karena rotasi CA tentu mencabut CA lama, sehingga kredensial ini tidak akan lagi mengautentikasi.
Setelah dimulai, rotasi CA tidak dapat dijeda atau di-roll back.
Rotasi CA mungkin memerlukan waktu yang cukup lama untuk diselesaikan, bergantung pada ukuran cluster pengguna.

Cara melakukan rotasi CA

Anda dapat memulai rotasi CA dan melihat status rotasi saat ini dengan menjalankan perintah gkectl di bawah ini.

Merotasi Sertifikat CA

Untuk memicu rotasi CA, jalankan perintah berikut.

gkectl update credentials certificate-authorities rotate \
--config USER_CONFIG_FILE \
--kubeconfig ADMIN_KUBECONFIG_FILE

Dengan keterangan:

USER_CONFIG_FILE adalah jalur ke file konfigurasi cluster pengguna dari cluster pengguna yang menjadi tujuan rotasi CA.
ADMIN_KUBECONFIG_FILE adalah jalur ke file kubeconfig untuk terhubung ke cluster admin yang mengelola cluster pengguna.

Jika rotasi CA berhasil dimulai, Anda akan melihat pesan yang mirip dengan berikut ini:

successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation

Jika rotasi CA sudah berlangsung, Anda akan melihat pesan error seperti berikut:

Exit with error:
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads

Melihat status rotasi CA

Untuk melihat status rotasi CA, jalankan perintah berikut. Perintah ini melaporkan CAVersion, bilangan bulat yang ditambahkan sistem secara otomatis untuk membedakan CA yang digunakan sebelum dan setelah setiap rotasi CA, status (True atau False) yang menunjukkan apakah rotasi CA selesai, dan pesan yang menjelaskan CAVersion mana yang saat ini digunakan oleh setiap komponen sistem.

gkectl update credentials certificate-authorities status \
--config USER_CONFIG_FILE \
--kubeconfig ADMIN_KUBECONFIG_FILE

Jika rotasi CA telah selesai, Anda akan melihat pesan seperti berikut:

State of CARotation with CAVersion 2 is -
status: True,
reason: CARotationCompleted,
message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.

Jika rotasi CA masih berlangsung, Anda akan melihat pesan seperti berikut:

State of CARotation with CAVersion 2 is -
status: False,
reason: CARotationProgressed,
message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.

Memperbarui Kredensial Cluster Pengguna

Setelah rotasi CA selesai, file kubeconfig cluster pengguna baru harus didownload dari cluster admin untuk menggantikan kubeconfig lama yang sebelumnya digunakan untuk terhubung ke cluster pengguna. Hal ini karena rotasi CA mencabut CA lama yang menjadi dasar file kubeconfig lama. Jalankan perintah berikut setelah rotasi CA selesai untuk mendownload file kubeconfig baru:

kubectl --kubeconfig ADMIN_KUBECONFIG_FILE get secret admin \
 -n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
 | base64 --decode > USER_CLUSTER_NAME-kubeconfig

Jika file kubeconfig tambahan diterbitkan secara manual kepada pengguna lain di cluster, file tersebut juga harus diperbarui.

Mengupdate File Konfigurasi Authentication

Setelah rotasi CA selesai, file konfigurasi autentikasi harus diupdate dan didistribusikan ulang. Ikuti petunjuk yang tertaut untuk memperbarui dan mendistribusikan ulang file ini setelah rotasi CA:

Rotasi Sertifikat Bidang Kontrol

Tanpa rotasi, CA cluster pengguna dan sertifikat bidang kontrol akan habis masa berlakunya dalam waktu 5 tahun sejak tanggal pembuatan cluster. Sertifikat bidang kontrol cluster pengguna otomatis dirotasi dalam waktu sepuluh jam sejak setiap upgrade cluster pengguna, tetapi CA tidak otomatis dirotasi. Artinya, rotasi CA harus dilakukan minimal 5 tahun sekali, selain upgrade versi reguler.

Untuk mencegah cluster pengguna menjadi tidak tersedia, sertifikat bidang kontrol dirotasi dalam waktu sepuluh jam setelah upgrade cluster pengguna. Jika hal ini terjadi, pesan akan muncul di status rotasi CA cluster pengguna.

Untuk melihat versi terakhir, cluster pengguna telah diupgrade saat sertifikat bidang kontrol dirotasi:

gkectl update credentials certificate-authorities status \
--config USER_CONFIG_FILE \
--kubeconfig ADMIN_KUBECONFIG_FILE

Jika cluster pengguna baru saja diupgrade ke versi 1.10 atau yang lebih baru, pesan akan muncul di akhir kolom message dalam waktu sepuluh jam. Contoh:

Last Leaf Certificates Rotation Version: 1.10.0-gke.0.

Memecahkan masalah rotasi CA

Perintah gkectl diagnose mendukung pemeriksaan status yang diharapkan dari rotasi CA yang telah selesai terhadap cluster pengguna. Untuk petunjuk cara menjalankan diagnosis gkectl pada cluster pengguna, lihat Mendiagnosis masalah cluster. Jika Anda mengalami masalah dengan rotasi CA, hubungi dukungan Google dan berikan output gkectl diagnose.