Halaman ini diterjemahkan oleh Cloud Translation API.

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. Admin cluster mengelola distribusi sertifikat CA publik dan pasangan kunci sertifikat leaf ke komponen sistem untuk membangun 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 pasangan kunci sertifikat CA publik dan sertifikat leaf baru ke komponen sistem cluster pengguna. Rotasi terjadi secara bertahap, sehingga komponen sistem dapat terus berkomunikasi selama rotasi. Namun, perlu diperhatikan 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 antar-replika etcd. CA ini ditandatangani sendiri.
CA cluster mengamankan komunikasi antara server API dan semua klien API Kubernetes internal (kubelet, pengontrol, scheduler). CA ini ditandatangani sendiri.
CA proxy depan mengamankan komunikasi dengan API gabungan. CA ini ditandatangani sendiri.

Selain itu, Anda mungkin menggunakan CA org 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 pada cluster lanjutan:
- Versi 1.31: Rotasi CA tidak didukung di cluster lanjutan.
- Versi 1.32 dan yang lebih baru: 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 front-proxy yang disebutkan sebelumnya.
Rotasi sertifikat CA terbatas pada sertifikat yang dikeluarkan secara otomatis oleh Google Distributed Cloud. Fitur ini tidak mengupdate 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 memperkirakan bahwa workload akan dimulai ulang dan dijadwalkan ulang. Anda juga harus memperkirakan periode singkat waktu nonaktif bidang kontrol jika cluster pengguna Anda 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 berfungsi lagi.
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 bergantung pada apakah cluster lanjutan diaktifkan:

Tidak diaktifkan

Jika cluster lanjutan tidak diaktifkan di cluster, perintah akan bersifat asinkron dan memulai rotasi CA, lalu keluar. Anda tidak perlu memantau 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:

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 dinaikkan 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 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 dalam proses, 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 membatalkan 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 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 berada 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

Bagikan 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 lima tahun sejak tanggal cluster dibuat. Sertifikat panel kontrol cluster pengguna dirotasi secara otomatis dalam waktu 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 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 yang diupgrade ke cluster pengguna saat sertifikat bidang kontrol dirotasi:

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

Informasi ini 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 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.