Migración de CA in situ

Vista previa ,In-place CA migration

Esta función está cubierta por las Condiciones de las Ofertas Pre-DG de las Condiciones del Servicio de Google Cloud. Es posible que las funciones de fase previa a la disponibilidad general tengan asistencia limitada y que los cambios en estas funciones no sean compatibles con otras versiones de fase previa a la disponibilidad general. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Nota: En esta guía, se describe cómo migrar tu autoridad certificadora (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 una CA de Istio a Mesh con un enfoque basado en versiones canary que implica un tiempo de inactividad mínimo o nulo, consulta Migración basada en versiones canary a la CA de Mesh.

Si tu malla tiene varios clústeres con cargas de trabajo que envían solicitudes a cargas de trabajo en 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 Anthos Service Mesh v1.13 o posterior en el clúster con la CA de Mesh a Certificate Authority Service
• Migrar un plano de control de Anthos Service Mesh en un canal de versiones que se asigne a la versión 1.13 o posterior con la CA de Mesh al servicio de autoridad certificadora.

Limitaciones

Las migraciones y actualizaciones de CA locales solo son compatibles con la versión 1.13 o posterior de Anthos Service Mesh. Para las migraciones del plano de control administrado, asegúrate de que el canal elegido se asigne a la versión 1.13 o posterior.

Prerequisites

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

• Permisos de administrador de clústeres concedidos
• Configuraste gcloud

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

Herramientas requeridas

Durante la migración, ejecutas una herramienta que proporciona 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 Prepárate para la migración.

Descripción general de la migración

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

La herramienta de migración migrate_ca creará un mapa de configuración de Kubernetes para realizar un seguimiento del estado de la migración de CA por canal o revisión de Anthos Service Mesh instalado. Este es un recurso con privilegios 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 la malla de Istio antes de modificarla y, luego, intentará migrar la configuración de CA mediante la CRD ProxyConfig cuando sea posible.

A continuación, se muestra un esquema de la migración de la CA:

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

1. Prepárate para la migración.

2. Inicializa la CA nueva.

3. Agrega confianzaAnchor de toda la malla para todos los clústeres de la flota.

4. Migra la CA.

5. Realiza una reversión.

Prepárate para la migración

1. Descarga la herramienta bash migrate_ca:

   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. Configure 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 a la OUTPUT_DIR especificada en el paso anterior.

   cd OUTPUT_DIR
   

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

   ./migrate_ca check-prerequisites
   

6. Toma nota de la revisión (ASM_REVISION) del plano de control asociado con la CA anterior que se migrará. Los pasos necesarios dependen del tipo de plano de control, ya sea en el clúster o administrado.

   En el clúster

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

   Administrado

   Consulta el canal que ya está instalado.

7. Dado que la migración de CA local requiere que reinicies las cargas de trabajo, asegúrate de que el Presupuesto de interrupción del Pod esté configurado de forma correcta y que todas las aplicaciones cuya CA necesite 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 que la identidad de la carga de trabajo esté habilitada en el clúster. Luego, toma nota del ID del proyecto de flota como (FLEET_ID) para los próximos pasos.

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

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

     gcloud container clusters get-credentials CLUSTER_NAME
     

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

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

Inicializa la CA nueva

1. Los pasos necesarios para inicializar la CA nueva dependen de la CA nueva a la que migras. Realiza estos pasos en todos los clústeres de flotas en los que quieras migrar la CA.

   CA de Mesh

   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 CA

   a. Sigue los pasos necesarios para inicializar el servicio de autoridad certificadora. Toma nota de 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
   

Agrega "TrustAnchors" a 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 CA anterior en todos los clústeres que forman parte de la flota.

2. Descarga los anclajes de confianza de la CA:

   CA de Mesh

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

   Servicio de CA

   Almacene el certificado de CA en un archivo:

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

3. Se agregó el valor "TrustAnchors" de la CA:

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

4. Verifica que todas las cargas de trabajo de la flota hayan recibido las TrustedAnchors. En el argumento de espacios de nombres, pasa todos los espacios de nombres en los que se implementan las 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
   

Migra la CA

1. Migrar la configuración de CA El comando necesario depende de la CA nueva a la que migras.

   CA de Mesh

   ./migrate_ca migrate-ca --ca mesh_ca
   

   Servicio de CA

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

2. Reinicia todas las cargas de trabajo.

   Nota: Este paso es opcional si instalaste el plano de datos administrado. Esto se debe a que Google administra la vida útil del proxy y realiza este paso de forma automática durante una actualización administrada.

   Para minimizar el riesgo de tiempo de inactividad del tráfico TLS, este paso debería afectar primero a la menor cantidad de cargas de trabajo. Solo reinicia las cargas de trabajo que están asociadas con la revisión ASM_REVISION del plano de control. Por ejemplo, si todas las cargas de trabajo en el espacio de nombres de Kubernetes NAMESPACE están asociadas al mismo plano de control de Anthos Service Mesh.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Verifica que las conexiones de mTLS funcionen entre cargas de trabajo en el espacio de nombres reiniciado y otras cargas de trabajo antes de repetir los pasos 1 y 2 para todos los espacios de nombres y para todos los clústeres que forman parte de la flota. Si aparecen cargas de trabajo nuevas 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 forman parte de la flota. De lo contrario, realiza una reversión a fin de revertir la configuración de CA más reciente.

4. Verifica que todas las cargas de trabajo usen la nueva configuración de CA:

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

Cómo realizar una reversión

1. Revertir la configuración de CA y quitar los anclajes de confianza recién configurados:

   ./migrate-ca rollback
   

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

   kubectl rollout restart deployment -n NAMESPACES
   

3. Verifica que todas las cargas de trabajo usen la configuración de CA anterior (opcional).

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

4. Repite los pasos 1 a 3 para todos los clústeres de la flota en los que las cargas de trabajo usan el plano de control ASM_REVISION.

¡Felicitaciones! Realizaste correctamente una migración de CA local.