A integração de microsserviços internos em diferentes provedores de nuvem apresenta desafios significativos em termos de verificação de identidade e criptografia de tráfego. Este guia técnico detalha a implementação de uma topologia de malha de serviços federada que abrange o Amazon EKS e o Azure AKS. Ao ancorar a identidade da carga de trabalho na estrutura SPIFFE/SPIRE e orquestrar o mTLS entre nuvens por meio de gateways Istio Multi-Primary, as equipes de engenharia estabelecem um plano de comunicação autenticado e de baixa latência que elimina os riscos de segredos compartilhados ou exposição pública da rede.

Introdução

Sistemas distribuídos modernos frequentemente distribuem cargas de trabalho por múltiplos ecossistemas de nuvem para aproveitar serviços gerenciados especializados ou impor redundância regional rigorosa. No entanto, estabelecer comunicação segura e de baixa latência entre um microsserviço em execução no Amazon Elastic Kubernetes Service (Amazon EKS) e uma carga de trabalho dependente no Azure Kubernetes Service (Azure AKS) expõe falhas arquitetônicas fundamentais em padrões de rede tradicionais. Depender de gateways de API públicos introduz latência desnecessária e expande a superfície de ataque externa, enquanto manter VPNs site-to-site permanentes ou circuitos expressos dedicados acarreta enorme complexidade operacional e não garante a segurança da camada de aplicação. Problematizamos essas abordagens tradicionais centradas na rede, refutando a suposição de que a segurança do perímetro da rede equivale à autorização da carga de trabalho.

Para alcançar uma verdadeira postura de confiança zero em todas as nuvens, as organizações precisam desacoplar a segurança da topologia de rede subjacente, implementando uma malha de serviços federada. Ao integrar arquiteturas Istio Multi-Primary em redes separadas com o Secure Production Identity Framework for Enterprise (SPIFFE) e sua implementação em tempo de execução (SPIRE), as equipes de engenharia podem estabelecer um plano de identidade criptográfica unificado. As cargas de trabalho na AWS e no Azure recebem identidades verificáveis ​​e de curta duração que lhes permitem iniciar conexões TLS mutuamente autenticadas (mTLS) diretamente entre os provedores, garantindo que cada solicitação entre nuvens seja criptografada, autenticada e autorizada, independentemente da rede de trânsito.

Pré-requisitos

A implantação de uma malha de serviços multicloud federada exige um conhecimento profundo dos princípios básicos de rede do Kubernetes, dos mecanismos de TLS mútuo e da geração de identidades criptográficas. A camada de infraestrutura é automatizada utilizando o Terraform versão 1.7.0 ou superior, aproveitando os provedores HashiCorp AWS, AzureRM e Helm. Os ambientes Kubernetes requerem o Amazon EKS e o Azure AKS executando a versão 1.29 ou posterior, com o Istio versão 1.21 ou superior instalado via Helm. A federação de identidades exige a implantação do SPIRE versão 1.9.0 em ambos os clusters, utilizando a federação OpenID Connect (OIDC) para estabelecer as relações de confiança iniciais entre os servidores SPIRE e os provedores de identidade nativos da nuvem.

Implementação passo a passo

Estabelecendo o Plano de Identidade Unificado SPIFFE/SPIRE

O requisito fundamental de uma arquitetura de confiança zero entre nuvens é a eliminação completa de chaves criptográficas compartilhadas ou credenciais estáticas de longa duração. Se um pod do EKS precisar apresentar uma chave de acesso do AWS IAM para verificar sua identidade a um consumidor do AKS, o sistema herda uma vulnerabilidade grave devido à sobrecarga de rotação de credenciais e aos riscos de exposição. Resolvemos esse desafio de identidade implementando o SPIRE como raiz de confiança em ambos os ambientes de nuvem.

O servidor SPIRE no AWS EKS está configurado para validar a identidade dos pods locais utilizando o atestador de carga de trabalho nativo do Kubernetes, verificando características como namespace, nome da conta de serviço e UUID do pod. Simultaneamente, o servidor SPIRE no Azure AKS realiza a atestação simétrica para cargas de trabalho locais. Fundamentalmente, federamos as duas instalações distintas do SPIRE estabelecendo uma troca de pacotes de confiança SPIFFE. Cada servidor SPIRE recupera e confia continuamente nas chaves criptográficas públicas de sua contraparte, permitindo que as cargas de trabalho na AWS validem os IDs SPIFFE emitidos pelo cluster do Azure de forma transparente.

# Helm deployment of the SPIRE Server on Amazon EKS with OIDC enabling trust federation
resource "helm_release" "spire_server_aws" {
  name             = "spire"
  repository       = "https://spiffe.github.io/helm-charts-hardened"
  chart            = "spire"
  namespace        = "spire-system"
  create_namespace = true

  set {
    name  = "server.configuration.trustDomain"
    value = "aws.enterprise.internal"
  }

  set {
    name  = "server.configuration.federation.azure.trustDomain"
    value = "azure.enterprise.internal"
  }

  set {
    name  = "server.configuration.federation.azure.bundleUrl"
    value = "https://spire.azure.enterprise.internal/v1/fedbundle"
  }
}

Uma vez que a infraestrutura SPIRE esteja federada e seja capaz de emitir identidades globalmente verificáveis, como integramos esse plano de identidade com a malha de serviços Istio para lidar com a rotação automática de certificados?

Configurando o Istio para utilizar certificados de carga de trabalho emitidos pelo SPIRE

Injetamos as identidades criptográficas geradas pelo SPIRE diretamente no plano de dados do Istio, modificando a configuração do sidecar do Envoy para se comunicar com o Agente SPIRE por meio da API do Serviço de Descoberta de Segredos (SDS) do Envoy. Por padrão, o Istio utiliza sua própria autoridade de certificação interna (Istiod) para emitir certificados de carga de trabalho. Em uma implantação multicloud, isso cria um cenário de “split-brain” (cérebro dividido) em que os proxies do AWS Envoy não conseguem validar certificados gerados pelo plano de controle do Azure Istiod sem uma sincronização complexa e manual da autoridade de certificação raiz.

Ao substituir a CA nativa do Istio pelo socket de domínio Unix do agente SPIRE, o Envoy ignora o Istiod para a geração de credenciais. Quando um pod é inicializado, o agente SPIRE atesta o contêiner, gera um certificado X.509 altamente efêmero e de curta duração contendo o ID SPIFFE exclusivo da carga de trabalho (como, por exemplo, `<ID_SPIFFE_ID> spiffe://aws.enterprise.internal/ns/core/sa/payment-service`) e o transmite para a memória do Envoy via SDS.

# IstioOperator configuration enforcing Envoy to use SPIRE SDS socket for identity
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: istio-spire-integration
spec:
  meshConfig:
    trustDomain: aws.enterprise.internal
  values:
    sidecarInjectorWebhook:
      injectedAnnotations:
        custom.spiffe.io/spire-agent-socket: "/run/spire/sockets/agent.sock"
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
    egressGateways:
    - name: istio-egressgateway
      enabled: true

Com os proxies do plano de dados utilizando certificados SPIRE federados, como configuramos as camadas de roteamento entre nuvens para transmitir com segurança esse tráfego mTLS pela internet pública ou interconexões privadas sem quebrar a correspondência TLS SNI?

Engenharia de roteamento de tráfego entre nuvens via gateways leste-oeste do Istio

Garantimos a segurança e o roteamento do tráfego entre nuvens implementando gateways Istio East-West dedicados em ambos os clusters, configurando-os para executar roteamento passthrough baseado em SNI. Expor os endpoints internos do cluster diretamente ao perímetro da rede externa introduz vulnerabilidades de segurança graves. Em vez disso, roteamos todas as solicitações de saída entre nuvens por meio de um Gateway de Saída no cluster de origem, que direciona o tráfego através do perímetro da rede para um Gateway de Entrada que atua como um ponto de entrada East-West no cluster de destino.

Os gateways são configurados para ler o cabeçalho Server Name Indication (SNI) durante o handshake TLS, buscando correspondência com o nome de domínio totalmente qualificado do serviço de destino (como, por exemplo, `example.com` order-service.core.svc.azure.enterprise.internal). Fundamentalmente, os gateways não encerram a conexão TLS; eles atuam como proxies reversos de camada 4, passando os bytes criptografados diretamente para o pod de destino, onde a descriptografia mTLS final e a validação de identidade SPIFFE ocorrem.

# Istio Gateway configuration for East-West cross-cloud routing
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cross-cloud-gateway
  namespace: istio-system
spec:
  selector:
    istio: eastwestgateway
  servers:
  - port:
      number: 15443
      name: tls
      protocol: TLS
    tls:
      mode: AUTO_PASSTHROUGH
    hosts:
    - "*.azure.enterprise.internal"
---
# DestinationRule enforcing mTLS and targeting the Azure infrastructure gateway
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: route-to-azure-mesh
  namespace: core
spec:
  host: "*.azure.enterprise.internal"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
      sni: "cross-cloud-mesh-routing"

Solução de problemas comuns

O modo de falha mais comum em malhas de serviço multicloud federadas é o desalinhamento dos pacotes de confiança entre as instâncias isoladas do servidor SPIRE. Se um microsserviço em execução na AWS tentar se conectar a uma carga de trabalho do Azure e os logs do sidecar do Envoy exibirem `SSPIRE_FALSE` CERT_SIGNING_FAILEDou ` TLS_ERR_BAD_CERTIFICATESSPIRE_FALSE`, os servidores SPIRE falharam na troca de seus pacotes de confiança criptográficos. Os operadores devem verificar se o endpoint público que expõe o pacote de federação SPIRE (o /v1/fedbundlecaminho) é totalmente acessível em todo o perímetro da nuvem e protegido por certificados válidos e globalmente confiáveis. Se o loop de sincronização automatizado falhar devido a regras de firewall rigorosas, os operadores devem estabelecer um pipeline de automação fora da banda usando o Terraform para exportar periodicamente as chaves de assinatura públicas do servidor SPIRE da AWS e adicioná-las manualmente ao repositório de confiança do servidor SPIRE do Azure.

Outra complicação operacional grave envolve limites rígidos de MTU em redes entre nuvens. Quando o Envoy encapsula o tráfego em mTLS e anexa grandes cadeias de identidade criptográfica SPIFFE ao handshake TLS, o tamanho do pacote frequentemente excede a Unidade Máxima de Transmissão (MTU) padrão de 1500 bytes das redes de trânsito da internet genéricas ou gateways privados virtuais. Essa discrepância resulta em truncamento silencioso de pacotes, fazendo com que os handshakes TCP travem e expirem durante a fase inicial de negociação mTLS, embora testes básicos de ping sejam bem-sucedidos. Para remediar esse problema, os engenheiros devem configurar explicitamente EnvoyFilterou modificar as configurações de rede CNI subjacentes do Kubernetes para limitar o Tamanho Máximo do Segmento (MSS) do TCP a 1300 bytes, garantindo que pacotes criptográficos com muitas camadas de criptografia atravessem os nós de roteamento multicloud sem fragmentação ou descarte.

Conclusão

A federação do Istio e do SPIFFE/SPIRE entre o Amazon EKS e o Azure AKS estabelece um plano de comunicação excepcionalmente robusto e independente de rede, que exemplifica perfeitamente os paradigmas arquitetônicos de confiança zero. O desacoplamento da autorização da topologia de rede garante que a total violação de um roteador intermediário, balanceador de carga ou configuração de rede na nuvem não permita que um invasor falsifique a identidade da carga de trabalho ou intercepte payloads transacionais confidenciais. À medida que a escala da plataforma se expande, as equipes de engenharia devem avaliar a implementação de plugins WebAssembly (WASM) nos proxies Envoy. Essa estratégia permite a injeção dinâmica de políticas complexas e localizadas de conformidade e mascaramento de dados diretamente no perímetro da malha, otimizando os controles de segurança antes mesmo que o payload entre nuvens cruze o limite da rede.