Merotasi certificate authority cluster pengguna

Google Distributed Cloud menggunakan sertifikat dan kunci pribadi untuk melakukan autentikasi dan mengenkripsi koneksi antar-komponen sistem di cluster pengguna. Cluster admin membuat kumpulan baru certificate authority (CA) untuk setiap cluster pengguna, dan menggunakan sertifikat CA untuk menerbitkan sertifikat daun tambahan untuk komponen sistem. Cluster admin mengelola distribusi sertifikat CA publik dan pasangan kunci sertifikat leaf ke komponen sistem untuk membuat komunikasi yang aman.

Fitur rotasi CA cluster pengguna memungkinkan Anda memicu rotasi sertifikat sistem inti di cluster pengguna. Selama rotasi, cluster admin akan mengganti CA sistem inti untuk cluster pengguna dengan CA yang baru dibuat, dan mendistribusikan sertifikat CA publik baru dan pasangan kunci sertifikat leaf ke komponen sistem cluster pengguna. Rotasi terjadi secara bertahap, sehingga komponen sistem dapat terus berkomunikasi selama rotasi. Namun, perlu diperhatikan bahwa workload dan node 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 antar-replika etcd. CA ini ditandatangani sendiri.
• CA cluster mengamankan komunikasi antara server API dan semua klien Kubernetes API internal (kubelet, pengontrol, penjadwal). CA ini ditandatangani sendiri.
• CA proxy depan mengamankan komunikasi dengan API gabungan. CA ini ditandatangani sendiri.

Selain itu, Anda mungkin menggunakan org CA untuk menandatangani sertifikat yang dikonfigurasi oleh opsi authentication.sni. CA ini dan sertifikat SNI digunakan untuk menayangkan Kubernetes API kepada 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

Peringatan: Rotasi CA akan mencabut CA lama di akhir operasi. Tindakan ini akan membatalkan file kubeconfig dan file konfigurasi autentikasi yang diterbitkan dan didistribusikan berdasarkan CA lama. Kredensial ini berhenti berfungsi setelah rotasi CA. Petunjuk berikut menyertakan detail tentang cara mendownload kubeconfig cluster pengguna baru dari cluster admin dan membuat ulang file konfigurasi autentikasi setelah rotasi CA selesai.

• Rotasi sertifikat CA dibatasi untuk CA etcd, cluster, dan front-proxy yang disebutkan sebelumnya.

• Rotasi sertifikat CA terbatas pada sertifikat yang dikeluarkan secara otomatis oleh Google Distributed Cloud. Tindakan ini tidak memperbarui sertifikat yang diterbitkan secara manual oleh administrator, meskipun sertifikat tersebut ditandatangani oleh CA sistem.

• Rotasi CA memulai ulang server API, proses bidang kontrol lainnya, dan setiap node di cluster beberapa kali. Setiap tahap rotasi CA berlangsung serupa dengan upgrade cluster. Meskipun cluster pengguna tetap beroperasi selama rotasi CA, Anda harus mengharapkan workload tersebut dimulai ulang dan dijadwalkan ulang. Anda juga akan mengalami periode nonaktif bidang kontrol singkat jika cluster pengguna tidak memiliki bidang kontrol ketersediaan tinggi.

• Anda harus memperbarui file kubeconfig cluster pengguna dan file konfigurasi autentikasi setelah rotasi CA. Hal ini karena sertifikat cluster lama dicabut, dan kredensial dalam file kubeconfig tidak lagi berfungsi.

• 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.

Melakukan rotasi CA

1. Mulai rotasi:

   gkectl update credentials certificate-authorities rotate \
       --config USER_CLUSTER_CONFIG \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

   Ganti kode berikut:

   • USER_CLUSTER_CONFIGE: jalur file konfigurasi cluster pengguna

   • ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin

   Jika rotasi CA berhasil dimulai, Anda akan melihat pesan yang mirip dengan 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 yang mirip dengan ini:

   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
   

2. Lihat status rotasi:

   gkectl update credentials certificate-authorities status \
       --config USER_CLUSTER_CONFIG \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

   Perintah sebelumnya melaporkan CAVersion, yang merupakan bilangan bulat yang ditingkatkan secara otomatis oleh sistem untuk membedakan CA yang digunakan sebelum dan setelah rotasi. Perintah ini juga melaporkan status (True atau False) yang menunjukkan apakah rotasi CA sudah selesai, dan pesan yang menjelaskan CAVersion yang saat ini digunakan oleh setiap komponen sistem.

   Jika rotasi CA telah selesai, Anda akan melihat pesan yang mirip dengan ini:

   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 yang mirip dengan ini:

   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, Anda harus mendapatkan file kubeconfig cluster pengguna baru dari cluster admin. Hal ini karena rotasi CA mencabut CA yang menjadi dasar file kubeconfig lama.

Dapatkan file kubeconfig baru:

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

Distribusikan file kubeconfig baru kepada semua orang yang menggunakan file kubeconfig untuk berinteraksi dengan cluster.

Memperbarui file konfigurasi autentikasi

Setelah rotasi CA selesai, file konfigurasi autentikasi harus diperbarui dan didistribusikan ulang. Untuk mengetahui informasi selengkapnya, lihat Mengelola identitas pengguna.

Rotasi sertifikat bidang kontrol

Tanpa rotasi, CA cluster pengguna dan sertifikat platform kontrol akan berakhir masa berlakunya lima tahun sejak tanggal cluster dibuat. Sertifikat panel kontrol cluster pengguna dirotasi secara otomatis dalam sepuluh jam setelah setiap upgrade cluster pengguna, tetapi CA tidak dirotasi secara otomatis. Artinya, rotasi CA harus dilakukan setidaknya sekali setiap lima tahun selain upgrade versi reguler.

Untuk mencegah cluster pengguna tidak tersedia, sertifikat control plane 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 yang diupgrade oleh cluster pengguna saat sertifikat control plane dirotasi:

gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG

Informasi ini muncul di akhir kolom message dalam sepuluh jam setelah upgrade. Contoh:

Last Leaf Certificates Rotation Version: 1.16.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 tentang cara menjalankan gkectl diagnose di cluster pengguna, lihat Mendiagnosis masalah cluster. Jika Anda mengalami masalah dengan rotasi CA, hubungi dukungan Google dan berikan output gkectl diagnose.

Catatan: Karena perintah ini memeriksa status akhir rotasi CA yang diharapkan, perintah ini diharapkan melaporkan bahwa beberapa sertifikat belum dirotasi saat dijalankan selama rotasi CA.