Migrasi CA di tempat

Catatan: Panduan ini menjelaskan cara memigrasikan certificate authority (CA) tanpa memigrasikan beban kerja ke kontrol plane baru (in-place) dengan periode nonaktif minimal menggunakan alat berbasis bash. Untuk bermigrasi dari CA Istio ke CA Mesh dengan pendekatan berbasis canary yang melibatkan periode nonaktif minimal atau tidak ada, lihat Migrasi Berbasis Canary ke CA Mesh.

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

Gunakan langkah-langkah dalam panduan ini untuk kasus penggunaan berikut:

• Migrasikan bidang kontrol Cloud Service Mesh v1.13 atau yang lebih baru dalam cluster dengan Mesh CA ke Certificate Authority Service.
• Migrasikan bidang kontrol Cloud Service Mesh terkelola di saluran rilis yang dipetakan ke v1.13 atau yang lebih baru dengan Mesh CA ke Certificate Authority Service.

Batasan

Migrasi dan upgrade CA di tempat hanya didukung dari Cloud Service Mesh v1.13 atau yang lebih baru. Untuk migrasi control plane terkelola, pastikan saluran yang dipilih dikaitkan ke v1.13 atau yang lebih baru.

Prasyarat

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

• Memberikan izin admin cluster
• gcloud yang dikonfigurasi

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

Alat yang diperlukan

Selama migrasi, Anda 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 Bersiap untuk migrasi.

Ringkasan migrasi

Selama proses migrasi, autentikasi dan otorisasi sepenuhnya berfungsi antara workload yang menggunakan CA sebelumnya dan workload yang menggunakan CA baru.

Alat migrasi migrate_ca akan membuat peta konfigurasi Kubernetes untuk melacak status migrasi CA per revisi/saluran Cloud Service Mesh yang diinstal. 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 mengubahnya dan mencoba memigrasikan konfigurasi CA menggunakan CRD ProxyConfig jika memungkinkan.

Berikut adalah ringkasan migrasi CA:

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

1. Siapkan migrasi Anda.

2. Lakukan inisialisasi CA baru.

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

4. Migrasikan CA.

5. Lakukan rollback.

Bersiap untuk 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. Buat alat 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 berikutnya.

4. Ubah direktori kerja ke OUTPUT_DIR yang ditentukan pada langkah sebelumnya

   cd OUTPUT_DIR
   

5. Jalankan perintah berikut untuk memastikan semua prasyarat terpenuhi:

   ./migrate_ca check-prerequisites
   

6. Catat revisi (ASM_REVISION) bidang kontrol yang terkait dengan CA sebelumnya yang sedang dimigrasikan. Langkah-langkah yang diperlukan bergantung pada jenis bidang kontrol, baik dalam cluster maupun dikelola.

   Dalam cluster

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

   Terkelola

   Lihat saluran yang sudah diinstal.

7. Karena migrasi CA in-place mengharuskan Anda memulai ulang workload, pastikan Anggaran Gangguan Pod dikonfigurasi dengan benar dan semua aplikasi yang CA-nya perlu dimigrasikan memiliki lebih dari satu Pod yang berjalan.

8. Pastikan cluster sudah terdaftar ke fleet dan workload-identity diaktifkan di cluster. Kemudian, catat project ID fleet sebagai (FLEET_ID) untuk langkah-langkah berikutnya.

9. Alat ini menerima kubeConfig dan kubeContext untuk memilih cluster tempat operasi dilakukan. Jika argumen ini tidak diteruskan, 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 menjadi tujuan migrasi Anda. Lakukan langkah-langkah ini di setiap cluster fleet tempat Anda ingin memigrasikan CA.

   CA Mesh

   Panggil sub-perintah initialize alat utilitas.

   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 melakukan inisialisasi Certificate Authority Service. Catat CA_POOL.

   b. Panggil sub-perintah initialize alat utilitas:

   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 di bawah ini untuk CA baru dan CA lama untuk semua cluster yang merupakan bagian dari fleet.

2. Download trustAnchors CA:

   CA Mesh

   ./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 trustAnchors CA:

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

4. Pastikan trustAnchors telah diterima oleh semua workload dalam armada. Dalam 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. Migrasikan konfigurasi CA. Perintah yang diperlukan bergantung pada CA baru yang menjadi tujuan migrasi Anda.

   CA Mesh

   ./migrate_ca migrate-ca --ca mesh_ca
   

   CA Service

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

2. Mulai ulang semua beban kerja.

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

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

   kubectl rollout restart deployment -n NAMESPACE
   

3. Pastikan koneksi mTLS berfungsi di antara workload di namespace yang dimulai ulang dan workload lainnya sebelum mengulangi langkah 1 dan 2 untuk semua namespace dan untuk semua cluster yang merupakan bagian dari fleet. Jika workload yang lebih baru muncul dan traffic mesh tidak terganggu, ulangi langkah 1 dan 2 untuk semua namespace dan cluster yang merupakan bagian dari fleet. Jika tidak, lanjutkan ke melakukan rollback untuk melakukan rollback konfigurasi CA yang lebih baru.

4. Pastikan konfigurasi CA 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. Kembalikan konfigurasi CA dan hapus trustAnchors yang baru dikonfigurasi:

   ./migrate-ca rollback
   

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

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Opsional) Pastikan konfigurasi CA lama digunakan oleh semua beban kerja.

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

4. Ulangi langkah 1-3 untuk semua cluster dalam fleet tempat beban kerja menggunakan bidang kontrol ASM_REVISION.

Selamat! Anda telah berhasil melakukan migrasi CA di tempat.