Este tutorial te enseña a montar un service mesh multicluster privado con Istio 1.5 y Service Mesh Hub para la federación de mallas. Para lograrlo, se utiliza un Internal Load Balancer (ILB) que conecta workloads de Istio corriendo en clusters privados multirregión de Google Kubernetes Engine (GKE).
Introducción
Istio 1.5 se lanzó el 5 de marzo y, con esta versión mayor, llegan varios cambios importantes; sin embargo, el soporte para Hashicorp Vault como CA externa aún está en desarrollo. Por eso empecé a investigar qué otras opciones hay para gestionar la CA raíz común de forma segura. Así llegué al proyecto open-source de solo.io, Service Mesh Hub. Service Mesh Hub es una solución que te ayuda a unificar la identidad raíz entre varias instalaciones de service mesh. Es decir, cualquier intermedio queda firmado por la misma CA raíz, y el mTLS de extremo a extremo entre clusters y servicios se establece correctamente.
Cómo funciona
En este tutorial:
vamos a construir la siguiente arquitectura:
Hay varias razones para aislar tus clusters de Google Kubernetes Engine (GKE) del acceso a internet, y la principal es la seguridad. En un cluster privado, los nodos solo tienen direcciones privadas RFC 1918 y se comunican con el endpoint privado del master a través de redes privadas. Esto bloquea cualquier acceso, autorizado o no, desde la internet pública.
El Internal Load Balancer TCP/UDP tiene una funcionalidad beta poco conocida llamada Global Access. Permite que clientes de cualquier región de tu red VPC accedan al Internal Load Balancer TCP/UDP. Sin Global Access, el tráfico que se origina en clientes de tu red VPC tiene que permanecer en la misma región que el load balancer. En tus clusters privados de Kubernetes, Global Access se habilita por Service mediante la siguiente anotación:
networking.gke.io/internal-load-balancer-allow-global-access:"true".
En la implementación de ejemplo, anotaremos directamente el Service de Kubernetes del ingressGateway para aprovisionar un ILB de GCP con Global Access. Una vez aplicado Global Access, ya tenemos conectividad de red entre nuestros clusters privados que corren en distintas regiones.
¡Listo! Observa que el servicio A (sleep.foo.cluster-1) necesita comunicarse con el servicio B (httpbin.bar.cluster-2) en otra malla. Cuando un servicio de una malla requiere un servicio de otra, hay que federar la identidad y la confianza entre ambas mallas. Para eso se intercambia el trust bundle entre las mallas.
Service Mesh Hub te permite agrupar varias mallas en un objeto llamado VirtualMesh. Al crear este recurso le indicas al Service Mesh que establezca una identidad raíz compartida entre los clusters del Virtual Mesh y que, además, federe los servicios.
Cómo funciona el proceso de raíz compartida
Al crear el recurso VirtualMesh:
- Service Mesh Hub arranca el proceso de unificar la identidad con una raíz compartida.
- Service Mesh Hub usa un agente de Certificate Signing Request (CSR) en cada uno de los clusters para crear un nuevo par clave/certificado que conformará una CA intermedia. La CA intermedia de cada cluster estará presente y será usada por la malla en ese cluster.
- Luego crea un Certificate Signing Request, representado por el CR VirtualMeshCertificateSigningRequest.
- A continuación, Service Mesh Hub firma el certificado con la CA raíz especificada en el VirtualMesh.
- Cuando este proceso termina, hay que reiniciar el control plane
istiod. Esto se debe a que el control plane de Istio toma la CA para Citadel y no la rota con suficiente frecuencia. Esto se mejorará en futuras versiones de Istio.
Una vez establecida la confianza, Service Mesh Hub empieza a federar los servicios y ¡crea automáticamente los service entries por ti!, para que sean accesibles entre clusters.
Para este tutorial, el flag enforceAccessControl está deshabilitado, y será tema de uno de mis próximos artículos. Allí veremos cómo Istio puede ofrecer funcionalidades de seguridad para una identidad robusta, políticas potentes y herramientas de autenticación, autorización y auditoría (AAA) que protejan tus servicios y datos.
Código del tutorial
Las instrucciones paso a paso de este tutorial están aquí:
Referencias
- Código de la implementación — https://github.com/palimarium/multicluster-istio-smh-private-gke
- GCP — Clusters privados de GKE — https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters
- GCP — Internal Load Balancer TCP/UDP — https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing
- Istio — Configurar el servicio de ejemplo — https://istio.io/docs/setup/install/multicluster/gateways/#configure-the-example-services
- Service Mesh Hub — Conceptos — https://docs.solo.io/service-mesh-hub/latest/concepts/
En este tutorial mostré lo sencillo que resulta implementar una solución de service mesh con comunicación intra-malla. La comunicación entre servicios ocurre internamente mediante tráfico mTLS seguro, sin salir de la red global de Google Cloud.