Migrasi CA yang diterapkan

Catatan: Panduan ini menjelaskan cara memigrasikan certificate authority (CA) Anda tanpa memigrasikan workload ke bidang kontrol baru (di tempat) dengan periode nonaktif menggunakan alat berbasis bash. Untuk bermigrasi dari Istio CA ke certificate authority Cloud Service Mesh dengan pendekatan berbasis canary yang melibatkan minimal atau tanpa periode nonaktif, lihat Certificate authority Migration to Cloud Service Mesh berbasis Canary.

Jika mesh Anda memiliki beberapa cluster dengan workload yang mengirim permintaan ke workload di cluster lain, lalu ikuti semua langkah dalam panduan ini untuk klaster.

Gunakan langkah-langkah dalam panduan ini untuk memigrasikan Cloud Service Mesh v1.13 dalam cluster atau bidang kontrol yang lebih baru dengan certificate authority Cloud Service Mesh ke Certificate Authority Service.

Batasan

Migrasi dan upgrade CA yang diterapkan hanya didukung dari Cloud Service Mesh v1.13 atau yang lebih baru.

Prasyarat

Sebelum mengikuti langkah-langkah dalam panduan ini, pastikan Anda telah:

• Memberikan izin admin cluster
• Mengonfigurasi gcloud

Selain itu, pastikan Anda menggunakan Cloud Service Mesh v1.13 atau yang lebih baru.

Alat yang diperlukan

Selama migrasi, Anda dapat menjalankan alat yang disediakan Google, migrate_ca. Alat ini memiliki dependensi berikut:

• awk
• grep
• jq
• kubectl
• head
• sed
• tr
• yq

Sebelum mendownload alat migrate_ca, ikuti langkah-langkah di Persiapkan migrasi Anda.

Ringkasan migrasi

Selama proses migrasi, otentikasi dan otorisasi sepenuhnya fungsional di antara workload yang menggunakan CA sebelumnya dan workload Kanada.

Alat migrasi migrate_ca akan membuat peta konfigurasi Kubernetes untuk melacak status migrasi CA per revisi/saluran Cloud Service Mesh yang terinstal. Ini adalah resource dengan hak istimewa yang diinstal di namespace istio-system.

apiVersion: v1
kind: ConfigMap
metadata:
  Name: asm-ca-migration-<revision>
Data:
  revision:
  start_time:
  state_update_time:
  current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
  old_ca:
  target_ca:

Alat migrasi akan mencadangkan peta konfigurasi Istio MeshConfig sebelum mengubah dan mencoba memigrasikan konfigurasi CA menggunakan ProxyConfig CRD jika memungkinkan.

Berikut adalah garis besar migrasi CA:

Catatan: Anda harus melakukan langkah-langkah migrasi pada setiap cluster di mesh Anda.

1. Persiapkan migrasi Anda.

2. Melakukan inisialisasi CA baru.

3. Menambahkan trustAnchors seluruh mesh untuk semua cluster dalam fleet.

4. Memigrasikan CA.

5. Melakukan rollback.

Mempersiapkan migrasi

1. Download alat bash migrate_ca:

   curl  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca
   

2. Jadikan alat ini dapat dieksekusi:

   chmod +x migrate_ca
   

3. Siapkan direktori kerja:

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Catatan: Jika Anda tidak menentukan direktori kerja, direktori sementara akan dibuat. Anda harus menggunakannya sebagai direktori kerja untuk semua langkah.

4. Mengubah direktori kerja ke OUTPUT_DIR yang ditentukan di langkah sebelumnya

   cd OUTPUT_DIR
   

5. Jalankan perintah berikut untuk memastikan bahwa semua prasyarat terpenuhi:

   ./migrate_ca check-prerequisites
   

6. Catat revisinya (ASM_REVISION) dari bidang kontrol yang terkait dengan CA sebelumnya yang sedang dimigrasikan.

   Dalam cluster

   asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
    "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
   

7. Karena migrasi CA yang diterapkan mengharuskan Anda memulai ulang beban kerja, memastikan bahwa Anggaran Gangguan Pod dikonfigurasi dengan benar dan semua aplikasi yang CA-nya perlu dimigrasikan memiliki lebih dari satu Pod yang berjalan.

8. Pastikan bahwa cluster sudah terdaftar ke fleet dan workload-identitas diaktifkan di cluster. Kemudian, perhatikan project ID fleet Anda (FLEET_ID) untuk masa mendatang langkah.

9. Alat ini menerima kubeConfig dan kubeContext untuk memilih cluster tempat operasi dilakukan. Jika argumen ini tidak diteruskan, maka konteks/konfigurasi default akan digunakan.

   • Untuk menambahkan kredensial cluster GKE ke kubeConfig, gunakan perintah berikut:

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Untuk mengubah konteks kubectl saat ini atau meneruskan konteks ke alat, gunakan perintah berikut:

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

Melakukan inisialisasi CA baru

1. Langkah-langkah yang diperlukan untuk melakukan inisialisasi CA baru bergantung pada CA baru yang bermigrasi. Lakukan langkah-langkah ini di setiap cluster fleet tempat Anda ingin memigrasikan CA.

   Jaring CA

   Panggil sub-perintah alat utilitas initialize.

   • Jika Anda menentukan konfigurasi Kubernetes kustom:

     ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
     --fleet_id FLEET_ID --revision ASM_REVISION
     

   • Atau:

     ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
     --fleet_id FLEET_ID --revision ASM_REVISION
     

   CA Service

   a. Ikuti langkah-langkah yang diperlukan untuk lakukan inisialisasi Certificate Authority Service. Catat CA_POOL.

   b. Panggil sub-perintah alat utilitas initialize:

   • Jika Anda menentukan konfigurasi Kubernetes kustom:

     ./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
     --fleet-id FLEET_ID --revision ASM_REVISION
     

   • Atau:

     ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
     --fleet-id FLEET_ID --revision ASM_REVISION
     

Menambahkan trustAnchors seluruh mesh untuk semua cluster dalam fleet

1. Ulangi langkah-langkah berikut untuk CA baru dan CA lama untuk semua cluster yang sebagian dari armada itu.

2. Download trustAnchor CA:

   Jaring CA

   ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
   

   CA Service

   Simpan sertifikat CA dalam file:

   gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
   

3. Tambahkan trustAnchor CA:

   ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
   

4. Memastikan bahwa trustAnchors telah diterima oleh semua workload di perangkat seluler. Pada argumen namespace, teruskan semua namespace tempat workload di-deploy:

   ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Output yang diharapkan:

   Check the CA cert in namespace nsa-1-24232                                                                                                                               
   a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
   

Memigrasikan CA

1. Memigrasikan konfigurasi CA. Perintah yang diperlukan tergantung pada CA baru untuk yang akan Anda migrasikan.

   Jaring CA

   ./migrate_ca migrate-ca --ca mesh_ca
   

   CA Service

   ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
   

2. Mulai ulang semua workload.

   Catatan: Langkah ini opsional jika Anda telah menginstal bidang data terkelola. Hal ini karena Google mengelola masa aktif proxy dan secara otomatis melakukan langkah ini selama upgrade terkelola.

   Untuk meminimalkan risiko periode nonaktif traffic TLS, langkah ini harus berdampak pada jumlah workload terkecil terlebih dahulu. Hanya memulai ulang beban kerja yang yang terkait dengan revisi bidang kontrol ASM_REVISION. Misalnya, jika semua workload di namespace kubernetes NAMESPACE dikaitkan dengan Cloud Service Mesh yang sama bidang kontrol.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Memastikan koneksi mTLS berfungsi antar-beban kerja saat dimulai ulang namespace dan beban kerja lainnya sebelum mengulangi langkah 1 dan 2 untuk semua untuk semua cluster yang merupakan bagian dari fleet. Jika lebih baru workload akan muncul dan traffic mesh tidak terganggu, ulangi langkah 1 dan 2 untuk semua namespace dan cluster yang merupakan bagian dari fleet. Jika tidak, lanjutkan untuk melakukan rollback untuk melakukan rollback konfigurasi CA yang lebih baru.

4. Pastikan konfigurasi CA yang baru digunakan oleh semua workload:

   ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Output yang diharapkan:

   Check the CA configuration in namespace nsb-2-76095
   b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
   

Melakukan rollback

1. Roll back konfigurasi CA dan hapus trustAnchors yang baru dikonfigurasi:

   ./migrate-ca rollback
   

2. Mulai ulang semua workload. Pastikan Anda hanya memulai ulang beban kerja yang yang terkait dengan revisi bidang kontrol ASM_REVISION. Misalnya, jika semua workload di namespace kubernetes NAMESPACES dikaitkan dengan Cloud Service Mesh yang sama bidang kontrol.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Opsional) Verifikasi bahwa konfigurasi CA lama digunakan oleh semua sebagian besar workload standar dan berbasis cloud.

   ./migrate-ca verify-ca --ca_cert older-root-cert.pem
   

4. Ulangi langkah 1-3 untuk semua cluster dalam fleet di mana workload menggunakan Bidang kontrol ASM_REVISION.

Selamat! Anda telah berhasil melakukan migrasi CA langsung.