Veja neste tutorial como montar uma solução privada de service mesh multicluster, com Istio 1.5 e Service Mesh Hub para federação de mesh. Para isso, usamos um Internal Load Balancer (ILB) que conecta workloads do Istio rodando em clusters privados do Google Kubernetes Engine (GKE) em múltiplas regiões.
Introdução
O Istio 1.5 foi lançado em 05/03 e, junto dessa versão importante, vieram várias mudanças relevantes. No entanto, o suporte ao Hashicorp Vault como CA externa ainda está em desenvolvimento. Por isso, comecei a investigar quais outras opções existem para gerenciar a CA raiz comum de forma segura. Foi aí que encontrei o projeto open source da solo.io, o Service Mesh Hub. O Service Mesh Hub é uma solução que ajuda a unificar a identidade raiz entre várias instalações de service mesh. Ou seja, todos os intermediários são assinados pela mesma CA raiz, e o mTLS de ponta a ponta entre clusters e serviços pode ser estabelecido corretamente.
Como funciona
Neste tutorial:
vamos construir a seguinte arquitetura:
Há vários motivos para isolar seus clusters do Google Kubernetes Engine (GKE) do acesso à internet, e o principal deles é a segurança. Em um cluster privado, os nós só têm endereços privados RFC 1918 e se comunicam com o endpoint privado do master por uma rede privada, o que bloqueia qualquer acesso, autorizado ou não, vindo da internet externa.
O Internal Load Balancer TCP/UDP tem um recurso beta menos conhecido, chamado Global Access. Esse recurso permite que clientes de qualquer região da sua rede VPC acessem o internal load balancer TCP/UDP. Sem o global access, o tráfego originado de clientes na sua rede VPC precisa ficar na mesma região do load balancer. Nos seus clusters Kubernetes privados, o global access é habilitado por Service, com a seguinte anotação:
networking.gke.io/internal-load-balancer-allow-global-access:"true".
Na implementação de exemplo, vamos anotar diretamente o Service do Kubernetes do ingressGateway para provisionar um ILB do GCP com global access. Depois que o global access é aplicado, já temos conectividade de rede entre os clusters privados rodando em regiões diferentes.
Pronto! Repare que temos o serviço A (sleep.foo.cluster-1), que precisa se comunicar com o serviço B (httpbin.bar.cluster-2) em outro mesh. Quando um serviço de um mesh precisa de um serviço de outro, é necessário federar identidade e confiança entre os dois meshes. Para isso, é preciso trocar o trust bundle entre eles.
O Service Mesh Hub permite agrupar vários meshes em um objeto chamado VirtualMesh. Ao criar esse recurso, o Service Mesh é instruído a estabelecer uma identidade raiz compartilhada entre os clusters do Virtual Mesh, além de federar os serviços.
Entendendo o processo de raiz compartilhada
Com a criação do recurso VirtualMesh:
- O Service Mesh Hub dispara o processo de unificação da identidade com uma raiz compartilhada.
- O Service Mesh Hub usa um agente de Certificate Signing Request (CSR) em cada cluster para criar um novo par chave/certificado, que vai formar uma CA intermediária. A CA intermediária de cada cluster fica disponível e é usada pelo mesh daquele cluster.
- Em seguida, cria uma Certificate Signing Request, representada pelo CR VirtualMeshCertificateSigningRequest.
- O Service Mesh Hub então assina o certificado com a CA raiz definida no VirtualMesh.
- Concluído esse processo, é preciso reiniciar o control plane do
istiod. Isso porque o control plane do Istio carrega a CA do Citadel e não a rotaciona com a frequência necessária. Esse comportamento vai ser aprimorado em versões futuras do Istio.
Estabelecida a confiança, o Service Mesh Hub começa a federar os serviços, gerando automaticamente os service entries para você! deixando-os acessíveis entre os clusters.
Neste tutorial, a flag enforceAccessControl está desabilitada, e esse será o tema de um dos meus próximos artigos. Nele, vamos ver como o Istio oferece recursos de segurança para uma identidade forte, políticas robustas e ferramentas de autenticação, autorização e auditoria (AAA) para proteger seus serviços e dados.
Código do tutorial
O passo a passo deste tutorial está disponível aqui:
Referências
- Código da implementação — https://github.com/palimarium/multicluster-istio-smh-private-gke
- GCP — Clusters GKE privados — 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 — Configurando o serviço de exemplo — https://istio.io/docs/setup/install/multicluster/gateways/#configure-the-example-services
- Service Mesh Hub — Conceitos — https://docs.solo.io/service-mesh-hub/latest/concepts/
Neste tutorial, mostrei como é simples implementar uma solução de service mesh com comunicação intra-mesh. A comunicação entre serviços pode acontecer internamente via tráfego mTLS seguro, sem sair da Global Network do Google Cloud.