Migración de CA in situ

Nota: En esta guía se describe cómo migrar tu autoridad de certificación (CA) sin migrar cargas de trabajo a un nuevo plano de control (in situ) con un tiempo de inactividad mínimo mediante una herramienta basada en Bash. Para migrar de Istio CA a Mesh CA con un enfoque basado en canary que implique un tiempo de inactividad mínimo o nulo, consulta Migración basada en canary a Mesh CA.

Si tu malla tiene varios clústeres con cargas de trabajo que envían solicitudes a cargas de trabajo de otro clúster, sigue todos los pasos de esta guía para todos los clústeres.

Sigue los pasos que se indican en esta guía para el siguiente caso práctico:

• Migrar un plano de control de Cloud Service Mesh v1.13 o versiones posteriores en el clúster con Mesh CA a Servicio de Autoridades de Certificación.
• Migrar un plano de control de Cloud Service Mesh gestionado en un canal de lanzamiento que se corresponda con la versión 1.13 o posterior con Mesh CA a Servicio de Autoridades de Certificación.

Limitaciones

Las migraciones y las actualizaciones in situ de la AC solo se admiten a partir de Cloud Service Mesh v1.13. En el caso de las migraciones del plano de control gestionado, asegúrate de que el canal elegido se corresponda con la versión 1.13 o posterior.

Requisitos previos

Antes de seguir los pasos que se indican en esta guía, asegúrate de que tienes lo siguiente:

• Permisos de administrador de clúster concedidos
• Configurado gcloud

Además, asegúrate de que estás usando Cloud Service Mesh 1.13 o una versión posterior.

Herramientas necesarias

Durante la migración, ejecutas una herramienta proporcionada por Google, migrate_ca. Esta herramienta tiene las siguientes dependencias:

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

Antes de descargar la herramienta migrate_ca, sigue los pasos que se indican en el artículo Preparar la migración.

Información general sobre la migración

Durante el proceso de migración, la autenticación y la autorización funcionan correctamente entre las cargas de trabajo que usan la autoridad de certificación anterior y las que usan la nueva.

La herramienta de migración migrate_ca creará un mapa de configuración de Kubernetes para monitorizar el estado de la migración de la AC por revisión o canal de Cloud Service Mesh instalado. Se trata de un recurso privilegiado instalado en el espacio de nombres 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:

La herramienta de migración creará una copia de seguridad del mapa de configuración de Istio MeshConfig antes de modificarlo e intentará migrar la configuración de la CA mediante el CRD ProxyConfig cuando sea posible.

A continuación, se muestra un resumen de la migración de la autoridad certificadora:

Nota: Debes seguir los pasos de migración en cada clúster de tu malla.

1. Prepárate para la migración.

2. Inicializa la nueva AC.

3. Añade trustAnchors en toda la malla para todos los clústeres de la flota.

4. Migra la CA.

5. Realiza una restauración.

Preparar la migración

1. Descarga la herramienta migrate_cabash:

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

2. Haz que la herramienta sea ejecutable:

   chmod +x migrate_ca
   

3. Configura el directorio de trabajo:

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Nota: Si no especificas un directorio de trabajo, se creará uno temporal. Deberás usarlo como directorio de trabajo para todos los pasos posteriores.

4. Cambia el directorio de trabajo al OUTPUT_DIR especificado en el paso anterior.

   cd OUTPUT_DIR
   

5. Ejecuta el siguiente comando para asegurarte de que se cumplen todos los requisitos:

   ./migrate_ca check-prerequisites
   

6. Anota la revisión (ASM_REVISION) del plano de control asociado a la AC anterior que se está migrando. Los pasos necesarios dependen del tipo de plano de control, ya sea en clúster o gestionado.

   En el clúster

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

   gestionados

   Consulta el canal ya instalado.

7. Como la migración de la CA in situ requiere que reinicies tus cargas de trabajo, asegúrate de que el presupuesto de interrupción de pods esté configurado correctamente y de que todas las aplicaciones cuya CA deba migrarse tengan más de un pod en ejecución.

8. Asegúrate de que el clúster ya esté registrado en una flota y de que Workload Identity esté habilitado en el clúster. A continuación, anota el ID del proyecto de la flota (FLEET_ID) para los pasos posteriores.

9. La herramienta acepta kubeConfig y kubeContext para seleccionar el clúster en el que se realizan las operaciones. Si no se incluyen estos argumentos, se utilizará el contexto o la configuración predeterminados.

   • Para añadir las credenciales de un clúster de GKE a kubeConfig, usa el siguiente comando:

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Para cambiar el contexto kubectl actual o pasar contexto a la herramienta, usa el siguiente comando:

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

Inicializa la nueva AC

1. Los pasos necesarios para inicializar la nueva CA dependen de la nueva CA a la que vayas a migrar. Sigue estos pasos en cada clúster de la flota en el que quieras migrar la CA.

   Mesh CA

   Llama al subcomando initialize de la herramienta de utilidad.

   Si especificas configuraciones personalizadas de Kubernetes:

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

   En caso contrario:

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

   Servicio de autoridades de certificación

   a. Sigue los pasos necesarios para inicializar el servicio de autoridad de certificación. Anota el CA_POOL.

   b. Llama al subcomando initialize de la herramienta de utilidad:

   Si especificas configuraciones personalizadas de Kubernetes:

    ./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
   

   En caso contrario:

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

Añadir trustAnchors en toda la malla para todos los clústeres de la flota

1. Repite los pasos que se indican a continuación para la CA nueva y la antigua en todos los clústeres que formen parte de la flota.

2. Descarga los trustAnchors de la CA:

   Mesh CA

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

   Servicio de autoridades de certificación

   Almacena el certificado de AC en un archivo:

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

3. Añade los elementos TrustAnchor de la AC:

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

4. Verifica que todas las cargas de trabajo de la flota hayan recibido los elementos TrustAnchor. En el argumento namespaces, pasa todos los espacios de nombres en los que se hayan desplegado cargas de trabajo:

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

   Resultado esperado:

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

Migrar la CA

1. Migra la configuración de la autoridad de certificación. El comando necesario depende de la nueva CA a la que estés migrando.

   Mesh CA

   ./migrate_ca migrate-ca --ca mesh_ca
   

   Servicio de autoridades de certificación

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

2. Reinicia todas las cargas de trabajo.

   Nota: Este paso es opcional si has instalado el plano de datos gestionado. Esto se debe a que Google gestiona los tiempos de vida de los proxies y realiza este paso automáticamente durante una actualización gestionada.

   Para minimizar el riesgo de que el tráfico TLS deje de funcionar, este paso debe afectar primero al menor número de cargas de trabajo posible. Solo reinicia las cargas de trabajo asociadas a la revisión del plano de control ASM_REVISION. Por ejemplo, si todas las cargas de trabajo del espacio de nombres de Kubernetes NAMESPACE están asociadas al mismo plano de control de Cloud Service Mesh.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Verifica que las conexiones mTLS funcionen entre las cargas de trabajo del espacio de nombres reiniciado y otras cargas de trabajo antes de repetir los pasos 1 y 2 para todos los espacios de nombres y todos los clústeres que formen parte de la flota. Si se van a implementar cargas de trabajo más recientes y el tráfico de la malla no se interrumpe, repite los pasos 1 y 2 para todos los espacios de nombres y clústeres que formen parte de la flota. De lo contrario, realiza una reversión para revertir la configuración de la AC más reciente.

4. Verifica que todas las cargas de trabajo estén usando la nueva configuración de la AC:

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

   Resultado esperado:

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

Restaurar una versión anterior

1. Deshace la configuración de la AC y elimina los elementos TrustAnchor recién configurados:

   ./migrate-ca rollback
   

2. Reinicia todas las cargas de trabajo. Asegúrate de reiniciar solo las cargas de trabajo asociadas a la revisión del plano de control ASM_REVISION. Por ejemplo, si todas las cargas de trabajo del espacio de nombres de Kubernetes NAMESPACES están asociadas al mismo plano de control de Cloud Service Mesh.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Opcional) Verifica que todas las cargas de trabajo estén usando la configuración de la autoridad de certificación anterior.

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

4. Repite los pasos del 1 al 3 en todos los clústeres de la flota en los que las cargas de trabajo usen el plano de control ASM_REVISION.

¡Enhorabuena! Has realizado correctamente una migración de CA in situ.