Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Merotasi certificate authority cluster pengguna

Google Distributed Cloud 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 untuk menerbitkan sertifikat leaf 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 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, 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 (kubelet, pengontrol, penjadwal). CA ini ditandatangani sendiri.
CA proxy depan mengamankan komunikasi dengan API gabungan. CA ini ditandatangani sendiri.

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

Perhatikan batasan berikut dengan cluster lanjutan:
- Versi 1.31: Rotasi CA tidak didukung di cluster lanjutan.
- Versi 1.32 dan yang lebih tinggi: Rotasi CA didukung di cluster lanjutan, tetapi ada beberapa perbedaan kecil yang dicatat jika berlaku dalam dokumen ini.
Rotasi sertifikat CA terbatas pada CA etcd, cluster, dan proxy depan yang disebutkan sebelumnya.
Rotasi sertifikat CA terbatas pada sertifikat yang diterbitkan secara otomatis oleh Google Distributed Cloud. Sertifikat 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 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 harus memperkirakan periode singkat waktu nonaktif bidang kontrol 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 rotasi CA dimulai, rotasi 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

Mulai rotasi:
```
gkectl update credentials certificate-authorities rotate \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Ganti kode berikut:
- USER_CLUSTER_CONFIG: jalur file konfigurasi cluster pengguna
- ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin

Perilaku perintah berbeda-beda bergantung pada apakah cluster lanjutan diaktifkan atau tidak:

Tidak diaktifkan

Jika cluster lanjutan tidak diaktifkan di cluster, perintah akan bersifat asinkron dan memulai rotasi CA, lalu keluar. Anda tidak perlu melihat output perintah selama durasi rotasi CA. Sebagai gantinya, Anda dapat memeriksa progres secara berkala dengan menjalankan perintah gkectl update credentials certificate-authorities status.

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 yang mirip dengan berikut 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

Untuk melihat 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 secara otomatis ditingkatkan oleh sistem untuk membedakan CA yang digunakan sebelum dan sesudah rotasi. Perintah ini juga melaporkan status (True atau False) yang menunjukkan apakah rotasi CA telah selesai, dan pesan yang menjelaskan CAVersion mana 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

Di cluster yang tidak mengaktifkan cluster lanjutan, 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

Aktif

Jika cluster lanjutan diaktifkan, perintah gkectl update credentials certificate-authorities rotate akan bersifat sinkron. Perintah ini akan menampilkan pesan status ke workstation admin saat rotasi CA berlangsung.

Setelah CA berhasil dirotasi, perintah akan keluar dan file kubeconfig baru akan otomatis dibuat. Output perintah memberikan nama file kubeconfig baru, dan mirip dengan berikut ini:

Beginning CA rotation with generated CA
...
Successfully rotated CA for user cluster "USER_CLUSTER_NAME". The
kubeconfig file "/home/ubuntu"/USER_CLUSTER_NAME-kubeconfig" has
been updated.

Kubeconfig baru terletak di direktori yang sama dengan kubeconfig cluster admin yang Anda tentukan dalam perintah. Nama kubeconfig baru adalah USER_CLUSTER_NAME-kubeconfig.

Mendistribusikan file kubeconfig baru

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 bidang kontrol akan berakhir masa berlakunya lima tahun sejak tanggal cluster dibuat. Sertifikat bidang kontrol cluster pengguna akan otomatis dirotasi dalam waktu sepuluh jam setelah setiap upgrade cluster pengguna, tetapi CA tidak otomatis dirotasi. Artinya, rotasi CA harus dilakukan setidaknya sekali setiap lima tahun selain upgrade versi reguler.

Untuk mencegah cluster pengguna menjadi tidak tersedia, sertifikat bidang kontrol akan 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 yang telah diupgrade saat sertifikat bidang kontrol dirotasi:

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

Informasi ini akan muncul di akhir kolom message dalam waktu 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 mengetahui petunjuk 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.