Merotasi certificate authority cluster pengguna

GKE di VMware menggunakan sertifikat dan kunci pribadi untuk mengautentikasi dan mengenkripsi koneksi antarkomponen sistem dalam cluster pengguna. Cluster admin membuat kumpulan certificate authority (CA) baru untuk setiap cluster pengguna, dan menggunakan sertifikat CA untuk menerbitkan leaf certificate tambahan bagi komponen sistem. Cluster admin mengelola distribusi sertifikat CA publik dan pasangan kunci leaf certificate 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 sertifikat CA publik baru dan pasangan kunci leaf certificate ke komponen sistem cluster pengguna. Rotasi terjadi secara bertahap, sehingga komponen sistem dapat terus berkomunikasi selama rotasi. Namun, perhatikan bahwa beban kerja 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 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 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 menyalurkan Kubernetes API kepada klien di luar cluster. Anda mengelola CA ini dan membuat sertifikat SNI secara manual. Baik CA ini maupun sertifikat SNI tidak terpengaruh oleh fitur rotasi CA cluster pengguna.

Batasan

  • Rotasi sertifikat CA terbatas pada CA etcd, cluster, dan front-proxy yang disebutkan sebelumnya.

  • Rotasi sertifikat CA terbatas pada sertifikat yang diterbitkan secara otomatis oleh GKE di VMware. Sertifikat tersebut tidak memperbarui sertifikat yang dikeluarkan secara manual oleh administrator, meskipun sertifikat tersebut ditandatangani oleh CA sistem.

  • Rotasi CA akan 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 beban kerja akan dimulai ulang dan dijadwalkan ulang. Periode nonaktif bidang kontrol juga akan terjadi dalam waktu 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 dikarenakan sertifikat cluster lama dicabut, dan kredensial di file kubeconfig tidak diperlukan lagi.

  • Setelah dimulai, rotasi CA tidak dapat dijeda atau di-rollback.

  • 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 seperti 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 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 ditambahkan sistem secara otomatis untuk membedakan CA yang digunakan sebelum dan sesudah rotasi. Perintah tersebut juga melaporkan status (True atau False) yang menunjukkan apakah rotasi CA selesai, dan pesan yang menjelaskan CAVersion yang saat ini digunakan oleh setiap komponen sistem.

    Jika rotasi CA sudah selesai, Anda akan melihat pesan yang mirip seperti 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 yang 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 yang 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. Ikuti petunjuk yang ditautkan 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 lima tahun sejak tanggal pembuatan cluster. Sertifikat bidang kontrol cluster pengguna otomatis dirotasi dalam waktu sepuluh jam sejak 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 dirotasikan 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_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 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.