Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Merotasi CA dan kunci bidang kontrol yang dikelola pelanggan

Standard

Halaman ini menunjukkan kepada administrator cluster dan Security engineer cara merotasi certificate authority (CA) dan kunci penandatanganan akun layanan yang Anda konfigurasi untuk otoritas bidang kontrol GKE.

Anda harus memahami konsep berikut:

Merencanakan rotasi kredensial

Dokumen ini menunjukkan cara merotasi komponen kredensial berikut di bidang kontrol Anda:

Root CA cluster, root CA agregasi, root CA API etcd, dan root CA peer etcd.
Kunci penandatanganan dan verifikasi ServiceAccount Kubernetes.

Anda juga dapat merotasi kunci enkripsi yang dikelola pelanggan yang Anda gunakan untuk mengenkripsi boot disk bidang kontrol, disk etcd, dan cadangan internal etcd yang digunakan Google Cloud untuk disaster recovery. Untuk mengetahui informasi selengkapnya, lihat Merotasi kunci enkripsi boot disk etcd dan bidang kontrol.

Rotasikan kredensial Anda untuk menghindari masa berlaku CA, untuk mengurangi penyusupan versi kunci, dan sebagai bagian dari praktik keamanan organisasi Anda. Untuk merencanakan seberapa sering Anda merotasi resource otoritas bidang kontrol GKE tertentu, pertimbangkan hal berikut:

Secara default, sertifikat GKE yang ditandatangani oleh root CA di Certificate Authority Service (CA Service) akan berakhir masa berlakunya satu tahun setelah tanggal pembuatan.
Kunci di Cloud Key Management Service (Cloud KMS) tidak memiliki masa berlaku. Lakukan rotasi kunci manual hanya jika organisasi Anda memiliki persyaratan untuk rotasi kunci. Untuk meminimalkan gangguan pada workload yang sedang berjalan, jangan konfigurasikan rotasi kunci otomatis untuk kunci ini.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

Aktifkan Google Kubernetes Engine API.

Aktifkan Google Kubernetes Engine API

Untuk menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. Versi gcloud CLI yang lebih lama mungkin tidak mendukung menjalankan perintah dalam dokumen ini.
Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region. Jika Anda menggunakan cluster zona, tetapkan compute/zone. Dengan menetapkan lokasi default, Anda dapat menghindari error di gcloud CLI seperti berikut: One of [--zone, --region] must be supplied: Please specify location. Anda mungkin perlu menentukan lokasi dalam perintah tertentu jika lokasi cluster Anda berbeda dengan lokasi default yang Anda tetapkan.

Memiliki cluster yang sudah ada yang menggunakan CA dan kunci akun layanan yang dikelola sendiri dan menjalankan GKE versi 1.35.2-gke.1842000 atau yang lebih baru.
Identifikasi project ID dari project Google Cloud berikut:
- Project kunci: project yang berisi resource Cloud KMS dan CA Service Anda.
- Project cluster: project yang berisi cluster GKE Anda.
Untuk melakukan tugas validasi dalam dokumen ini, pastikan log audit Akses Data berikut diaktifkan:
- Cloud Key Management Service (KMS) API: DATA_READ
- Certificate Authority Service: ADMIN_READ
Untuk mengaktifkan jenis log ini, lihat Mengaktifkan log audit Akses Data.

Peran dan izin yang diperlukan

Untuk mendapatkan izin yang Anda perlukan untuk merotasi CA dan kunci yang dikelola pelanggan, minta administrator untuk memberi Anda peran IAM berikut:

Mengelola kunci atau versi kunci: Cloud KMS Admin (roles/cloudkms.admin) di project kunci Anda
Mengelola root CA: CA Service Admin (roles/privateca.admin) di project kunci Anda
Konfigurasikan cluster untuk menggunakan kredensial baru: Kubernetes Engine Cluster Admin (roles/container.clusterAdmin) pada project cluster Anda

Untuk mengetahui informasi selengkapnya tentang pemberian peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.

Batasan

Kunci Cloud KMS asimetris yang Anda gunakan untuk penandatanganan dan verifikasi akun layanan tidak mendukung rotasi kunci otomatis.

Merotasi kunci penandatanganan dan verifikasi akun layanan

Saat menyiapkan otoritas bidang kontrol GKE, Anda menambahkan kunci penandatanganan akun layanan dan kunci verifikasi akun layanan ke cluster. GKE menggunakan kunci ini untuk menandatangani dan memvalidasi token pemilik untuk ServiceAccount Kubernetes. Selama rotasi, Anda menambahkan kunci baru ke daftar kunci verifikasi akun layanan, menunggu perubahan diterapkan, lalu mengganti kunci penandatanganan akun layanan dengan kunci baru.

Untuk merotasi kunci akun layanan, ikuti langkah-langkah berikut:

Dapatkan nama resource lengkap dari versi kunci asli kunci penandatanganan akun layanan:
```
gcloud container clusters describe CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(userManagedKeysConfig.serviceAccountSigningKeys)"
```
Ganti kode berikut:
- CLUSTER_NAME: nama cluster Anda.
- CONTROL_PLANE_LOCATION: lokasi cluster.
- CLUSTER_PROJECT_ID: project ID dari project cluster.
Outputnya mirip dengan hal berikut ini:
```
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/ORIGINAL_SIGNING_KEY_VERSION
```
Dalam output ini, SIGNING_KEY_NAME adalah nama kunci dan ORIGINAL_SIGNING_KEY_VERSION adalah nomor versi kunci penandatanganan asli.
Buat versi kunci baru untuk kunci penandatanganan akun layanan:
```
gcloud kms keys versions create \
    --key=SIGNING_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID
```
Ganti kode berikut:
- SIGNING_KEY_NAME: nama kunci penandatanganan akun layanan.
- KEYRING_NAME: nama key ring yang menyimpan kunci.
- CONTROL_PLANE_LOCATION: lokasi Google Cloud key ring.
- KEY_PROJECT_ID: project ID dari project kunci Anda.

Dapatkan nama resource lengkap dari versi kunci baru:

gcloud kms keys versions list \
    --key=SIGNING_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

Outputnya mirip dengan hal berikut ini:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/NEW_SIGNING_KEY_VERSION

Dalam output ini, SIGNING_KEY_NAME adalah nama kunci dan NEW_SIGNING_KEY_VERSION adalah nomor versi kunci penandatanganan baru.

Tambahkan versi kunci baru ke kumpulan kunci verifikasi akun layanan untuk cluster:
```
gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=ORIGINAL_KEY_VERSION_PATH,NEW_KEY_VERSION_PATH
```
Ganti kode berikut:
- ORIGINAL_KEY_VERSION_PATH: nama resource lengkap versi kunci penandatanganan asli dari output langkah pertama di bagian ini. Contoh, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/1.
- NEW_KEY_VERSION_PATH: nama resource lengkap dari versi kunci penandatanganan baru dari output langkah sebelumnya. Contoh, projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2.
Setelah operasi update cluster selesai, mungkin perlu waktu hingga 10 menit agar jalur versi kunci baru diterapkan ke Server API Kubernetes dan setiap endpoint API GKE.

Untuk mengonfirmasi bahwa jalur versi kunci baru telah diterapkan sepenuhnya, lakukan hal berikut:

Dapatkan komponen publik kunci penandatanganan cluster dari GKE API sebagai JSON Web Key Set (JWKS):

curl https://container.googleapis.com/v1/projects/CLUSTER_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/jwks

Outputnya mirip dengan hal berikut ini:

{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}

Output ini harus memiliki dua entri kunci, yang menunjukkan bahwa kedua versi kunci tersedia di GKE API. Jika Anda hanya melihat satu entri kunci, tunggu selama 10 menit dan coba lagi perintah tersebut.

Hubungkan ke cluster agar Anda dapat menjalankan perintah kubectl:

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Dapatkan komponen publik kunci penandatanganan cluster dari server Kubernetes API sebagai JWKS:

kubectl get --raw /openid/v1/jwks | jq

Outputnya mirip dengan hal berikut ini:

{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}

Output ini harus memiliki dua entri kunci, yang menunjukkan bahwa kedua versi kunci tersedia di server Kubernetes API. Jika Anda hanya melihat satu entri kunci, tunggu selama 10 menit dan coba lagi perintah tersebut.

Update cluster untuk menggunakan versi kunci baru sebagai kunci penandatanganan akun layanan:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-signing-keys=NEW_KEY_VERSION_PATH

Pastikan token akun layanan baru menggunakan versi kunci baru:

Buat ServiceAccount:

kubectl create serviceaccount test-sa-1

Buat token untuk ServiceAccount:
```
kubectl create token test-sa-1
```

Ekstrak ringkasan yang baru saja ditandatangani dari Logging:

export SIGNED_DIGEST=$(gcloud logging read \
    'resource.type="gke_cluster"
    AND resource.labels.cluster_name="CLUSTER_NAME"
    AND protoPayload.methodName="google.cloud.gkeauth.v1.Auth.SignServiceAccountJWT"
    AND protoPayload.metadata.subject="system:serviceaccount:default:test-sa-1"' \
    --freshness=1h \
    --bucket=_Required \
    --location=global \
    --view=_AllLogs \
    --order=DESC \
    --limit=1 \
    --format="value(protoPayload.metadata.toBeSignedDigest)")

Pastikan versi kunci penandatanganan baru sedang digunakan:

gcloud logging read \
    'resource.type="cloudkms_cryptokeyversion" 
    AND protoPayload.methodName="AsymmetricSign"
    AND protoPayload.request.digest.sha256="'${SIGNED_DIGEST}'"' \
    --freshness=1h \
    --bucket=_Default \
    --location=global \
    --view=_AllLogs \
    --order=DESC \
    --limit=1 \
    --format="value(protoPayload.resourceName)"

Output-nya adalah jalur resource versi kunci penandatanganan baru.

Tunggu hingga setiap token di cluster yang menggunakan versi kunci penandatanganan akun layanan asli habis masa berlakunya. Secara default, masa berlaku token adalah satu jam, dengan maksimum 24 jam yang dapat dikonfigurasi. Untuk memeriksa masa berlaku token yang dikonfigurasi di cluster Anda, jalankan perintah berikut:
```
kubectl get pods -A -o json | jq -r '.items[]?.spec?.volumes[]?.projected?.sources[]?.serviceAccountToken?.expirationSeconds | select(. != null)' | sort -nr | head -n 1
```
Catatan: jika Anda menyimpan token ServiceAccount di Secret, buat ulang Secret agar Kubernetes membuat token baru yang ditandatangani oleh versi kunci baru.
Tunggu hingga masa aktif token yang dikonfigurasi dari output langkah sebelumnya berakhir. Setelah jangka waktu ini berlalu, semua token terikat di cluster Anda akan menggunakan versi kunci penandatanganan akun layanan yang baru.

Hapus versi kunci asli dari daftar kunci verifikasi untuk cluster:

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=NEW_KEY_VERSION_PATH

Opsional: Nonaktifkan versi kunci asli. Setelah Anda memverifikasi bahwa versi kunci asli tidak digunakan dan cluster responsif, hancurkan versi kunci tersebut.

Kecuali jika Anda merotasi kunci sebagai respons terhadap peristiwa penting, sebaiknya tunggu beberapa hari sebelum menghancurkan versi kunci asli. Untuk mengetahui informasi selengkapnya, lihat Menghancurkan dan memulihkan versi kunci.

Setelah Anda menyelesaikan langkah-langkah ini, setiap token akun layanan baru dan yang sudah ada di cluster Anda akan ditandatangani oleh versi kunci baru. Server API menolak permintaan apa pun yang menggunakan token pemilik dengan versi kunci asli, karena versi kunci asli tidak ada dalam konfigurasi cluster.

Merotasi CA otoritas bidang kontrol GKE

Bagian berikut menunjukkan cara merotasi root CA yang digunakan cluster untuk otoritas bidang kontrol GKE.

Membuat versi kunci baru untuk CA

Buat versi kunci baru untuk kunci CA root cluster:
```
gcloud kms keys versions create \
    --key=CLUSTER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID
```
Ganti kode berikut:
- CLUSTER_CA_KEY_NAME: nama kunci root CA cluster untuk cluster.
- KEYRING_NAME: nama key ring yang menyimpan kunci.
- CONTROL_PLANE_LOCATION: lokasi Google Cloud key ring. Lokasi ini sama dengan lokasi cluster Anda.
- KEY_PROJECT_ID: project ID dari project kunci Anda.

Buat versi kunci baru untuk kunci CA root agregasi:

gcloud kms keys versions create \
    --key=AGGREGATION_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ganti AGGREGATION_CA_KEY_NAME dengan nama kunci root CA agregasi untuk cluster.

Buat versi kunci baru untuk kunci CA root API etcd:

gcloud kms keys versions create \
    --key=ETCD_API_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ganti ETCD_API_CA_KEY_NAME dengan nama kunci root CA API etcd untuk cluster.

Buat versi kunci baru untuk kunci root CA peer etcd:

gcloud kms keys versions create \
    --key=ETCD_PEER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ganti ETCD_PEER_CA_KEY_NAME dengan nama kunci root CA peer etcd untuk cluster.

Membuat root CA baru

Dapatkan nama resource lengkap versi kunci root CA cluster baru:

gcloud kms keys versions list \
    --key=CLUSTER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

Outputnya mirip dengan hal berikut ini:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/CLUSTER_CA_KEY_NAME/cryptoKeyVersions/VERSION

Dalam output ini, VERSION adalah nomor versi kunci baru.

Buat CA root cluster baru di kumpulan CA cluster:
```
gcloud privateca roots create CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=CLUSTER_CA_KEY_PATH \
    --subject="CN=cluster-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
Ganti kode berikut:
- CLUSTER_ROOT_CA_NAME: nama untuk root CA baru Anda.
- CLUSTER_CA_POOL_NAME: nama kumpulan CA cluster.
- CLUSTER_CA_KEY_PATH: nama resource lengkap versi kunci baru dari output langkah sebelumnya.
- ORGANIZATION: nama organisasi Anda.

Dapatkan nama resource lengkap dari versi kunci root CA agregasi yang baru:

gcloud kms keys versions list \
    --key=AGGREGATION_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

Outputnya mirip dengan hal berikut ini:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/AGGREGATION_CA_KEY_NAME/cryptoKeyVersions/VERSION

Buat CA root agregasi baru di kumpulan CA agregasi:

gcloud privateca roots create AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=AGGREGATION_CA_KEY_PATH \
    --subject="CN=aggregation-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID

Ganti kode berikut:

AGGREGATION_ROOT_CA_NAME: nama untuk CA root agregasi baru Anda.
AGGREGATION_CA_POOL_NAME: nama kumpulan CA agregasi.
AGGREGATION_CA_KEY_PATH: nama resource lengkap versi kunci baru dari output langkah sebelumnya.

Dapatkan nama resource lengkap dari versi kunci root CA API etcd yang baru:

gcloud kms keys versions list \
    --key=ETCD_API_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

Outputnya mirip dengan hal berikut ini:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_API_CA_KEY_NAME/cryptoKeyVersions/VERSION

Buat CA root API etcd baru di kumpulan CA API etcd:

gcloud privateca roots create ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_API_CA_KEY_PATH \
    --subject="CN=etcd-api-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID

Ganti kode berikut:

ETCD_API_ROOT_CA_NAME: nama untuk root CA API etcd baru Anda.
ETCD_API_CA_POOL_NAME: nama kumpulan CA API etcd.
ETCD_API_CA_KEY_PATH: nama resource lengkap versi kunci baru dari output langkah sebelumnya.

Dapatkan nama resource lengkap dari versi kunci root CA peer etcd yang baru:

gcloud kms keys versions list \
    --key=ETCD_PEER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

Outputnya mirip dengan hal berikut ini:

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_PEER_CA_KEY_NAME/cryptoKeyVersions/VERSION

Buat CA root peer etcd baru di kumpulan CA peer etcd:

gcloud privateca roots create ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_PEER_CA_KEY_PATH \
    --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID

Ganti kode berikut:

ETCD_PEER_ROOT_CA_NAME: nama untuk root CA peer etcd baru Anda.
ETCD_PEER_CA_POOL_NAME: nama kumpulan CA peer etcd.
ETCD_PEER_CA_KEY_PATH: nama resource lengkap versi kunci baru dari output langkah sebelumnya.

Sebelum melanjutkan, propagasikan perubahan root CA ke paket kepercayaan cluster dengan mengikuti petunjuk di bagian Memulai ulang bidang kontrol dan node.

Mengganti root CA asli dengan root CA baru

Setelah Anda memulai ulang bidang kontrol dan node, ikuti langkah-langkah berikut:

Aktifkan CA root cluster baru:

gcloud privateca roots enable CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Aktifkan CA root agregasi baru:

gcloud privateca roots enable AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Aktifkan CA root API etcd baru:

gcloud privateca roots enable ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Aktifkan root CA peer etcd baru:

gcloud privateca roots enable ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Nonaktifkan root CA cluster asli:

gcloud privateca roots disable ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ganti ORIGINAL_CLUSTER_ROOT_CA dengan nama root CA cluster asli yang Anda rotasi.

Nonaktifkan root CA agregasi asli:

gcloud privateca roots disable ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ganti ORIGINAL_AGGREGATION_ROOT_CA dengan nama root CA agregasi asli yang Anda rotasi.

Nonaktifkan CA root API etcd asli:

gcloud privateca roots disable ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ganti ORIGINAL_ETCD_API_ROOT_CA dengan nama root CA API etcd asli yang Anda rotasi.

Nonaktifkan root CA peer etcd asli:

gcloud privateca roots disable ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

Ganti ORIGINAL_ETCD_PEER_ROOT_CA dengan nama root CA peer etcd asli yang Anda rotasi.

Pada tahap ini, root CA baru akan menerbitkan semua sertifikat baru di cluster. Untuk menerbitkan sertifikat baru untuk kubelet di setiap node, Mulai ulang bidang kontrol dan node. Langkah ini diperlukan karena sertifikat kubelet memiliki masa aktif yang lama.

Setelah beberapa hari cluster tetap dalam status responsif, Anda dapat menghapus root CA asli, seperti yang dijelaskan di bagian berikutnya.

Menghapus root CA asli

Bagian ini menunjukkan cara menghapus root CA asli Anda. Sebelum mengikuti langkah-langkah ini, verifikasi hal berikut:

Cluster tetap dalam status responsif selama beberapa hari setelah Anda mengganti root CA asli dengan root CA baru.
Anda telah mengganti semua sertifikat yang diterbitkan oleh root CA asli dengan sertifikat baru.

Untuk menghapus root CA asli, gunakan perintah gcloud privateca roots delete, seperti yang dijelaskan dalam langkah-langkah berikut. Dalam perintah ini, flag --ignore-active-certificates akan menghapus CA setelah masa tenggang, meskipun CA memiliki sertifikat yang belum dicabut atau belum habis masa berlakunya.

Hapus root CA cluster asli:

gcloud privateca roots delete ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Ganti ORIGINAL_CLUSTER_ROOT_CA dengan nama root CA cluster asli yang Anda rotasi.

Hapus root CA agregasi asli:

gcloud privateca roots delete ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Ganti ORIGINAL_AGGREGATION_ROOT_CA dengan nama root CA agregasi asli yang Anda rotasi.

Hapus CA root API etcd asli:

gcloud privateca roots delete ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Ganti ORIGINAL_ETCD_API_ROOT_CA dengan nama root CA API etcd asli yang Anda rotasi.

Hapus root CA peer etcd asli:

gcloud privateca roots delete ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

Ganti ORIGINAL_ETCD_PEER_ROOT_CA dengan nama root CA peer etcd asli yang Anda rotasi.

Opsional: Sebarkan perubahan pada root CA ke paket kepercayaan cluster. Untuk mengetahui petunjuknya, lihat bagian Memulai ulang bidang kontrol dan node. Jika Anda melewati langkah ini, root CA asli akan dihapus selama upgrade versi node dan bidang kontrol berikutnya.

Memulai ulang bidang kontrol dan node

Saat Anda membuat perubahan pada konfigurasi root CA cluster, seperti mengaktifkan root CA, menonaktifkan root CA, atau mencabut sertifikat, Anda harus menerapkan perubahan tersebut ke paket kepercayaan cluster. Untuk menerapkan perubahan pada paket kepercayaan untuk cluster, Anda memulai ulang bidang kontrol dan (dalam beberapa skenario) node.

Upgrade bidang kontrol cluster ke versi yang sama dengan yang sudah digunakan.

Perhatian: Di cluster zona, bidang kontrol menjadi tidak tersedia hingga operasi upgrade selesai. Dalam cluster Autopilot dan cluster Standard regional, bidang kontrol tetap tersedia.
1. Temukan versi GKE yang sudah digunakan bidang kontrol:
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(currentMasterVersion)"
```
  Ganti kode berikut:
  - CLUSTER_NAME: nama cluster GKE Anda.
  - CLUSTER_VERSION: versi GKE yang sudah dijalankan cluster.
  - CLUSTER_PROJECT_ID: project ID dari project cluster Anda.
2. Upgrade bidang kontrol:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID
```
Khusus untuk rotasi root CA cluster, picu pembuatan ulang node dengan mengupgrade setiap node pool ke versi yang sama dengan yang sudah digunakan.

Perhatian: GKE akan segera mulai membuat ulang node untuk perubahan ini menggunakan strategi upgrade node, terlepas dari kebijakan pemeliharaan yang aktif. GKE bergantung pada ketersediaan resource untuk perubahan tersebut. Menonaktifkan upgrade otomatis node tidak akan mencegah perubahan ini. Siapkan workload yang berjalan di node Anda untuk menghadapi gangguan sebelum Anda memulai perubahan ini.
1. Temukan versi GKE yang digunakan node pool:
```
gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(version)"
```
  Ganti NODE_POOL_NAME dengan nama node pool yang akan diupgrade.
2. Upgrade node pool:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID
```
Setelah bidang kontrol dan node Anda selesai diupgrade, update semua klien Kubernetes API seperti kubectl CLI untuk menggunakan paket kepercayaan yang telah diupdate. Jika Anda membuat sertifikat secara manual menggunakan CertificateSigningRequests Kubernetes, terbitkan ulang semua sertifikat tersebut dan berikan sertifikat baru kepada klien API.

Jika Anda melakukan langkah-langkah di bagian ini selama rotasi CA, lanjutkan ke fase rotasi berikutnya, yang merupakan salah satu bagian berikut dalam dokumen ini:

Ganti root CA asli dengan root CA baru.
Hapus root CA asli.

Merotasi CA dan kunci bidang kontrol yang dikelola pelanggan Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Merencanakan rotasi kredensial

Sebelum memulai

Peran dan izin yang diperlukan

Batasan

Merotasi kunci penandatanganan dan verifikasi akun layanan

Merotasi CA otoritas bidang kontrol GKE

Membuat versi kunci baru untuk CA

Membuat root CA baru

Mengganti root CA asli dengan root CA baru

Menghapus root CA asli

Memulai ulang bidang kontrol dan node

Langkah berikutnya

Merotasi CA dan kunci bidang kontrol yang dikelola pelanggan