Topologias rígidas de segregação de rede e segurança de perímetro localizada falham ao tentar unificar a comunicação entre microsserviços distribuídos em múltiplos provedores de nuvem. Quando engenheiros de infraestrutura estendem barramentos de comunicação entre a Amazon Web Services (AWS) e o Microsoft Azure, a confiança implícita baseada em blocos CIDR expõe o tráfego a graves vulnerabilidades de interceptação. Depender exclusivamente de túneis IPsec ou conexões dedicadas não mitiga o risco de movimentação lateral caso um único contêiner seja comprometido. A segurança em ambientes multicloud exige uma Service Mesh federada, fundamentada estritamente no paradigma Zero Trust. Ao implementar uma federação de identidades baseada na especificação Secure Production Identity Framework for Everyone (SPIFFE), gerenciada pela SPIRE, as organizações substituem a validação de endereços de rede pela atestação criptográfica de cargas de trabalho. Essa topologia garante que cada microsserviço possua uma identidade universalmente verificável, permitindo a execução de TLS mútuo (mTLS) de ponta a ponta em limites de nuvem isolados, sem depender de perímetros de rede vulneráveis.

Pré-requisitos

A construção de uma infraestrutura de identidade federada exige conformidade com as especificações modernas de infraestrutura como código e paradigmas de gerenciamento de contêineres. O ambiente de orquestração requer clusters do Amazon Elastic Kubernetes Service (EKS) e do Azure Kubernetes Service (AKS) executando a versão 1.29 ou superior. A automação da infraestrutura utiliza o Terraform versão 1.7.0 ou posterior, integrado ao provedor AWS da HashiCorp versão 5.40.0 e ao provedor AzureRM versão 3.90.0. A camada de federação de identidades requer a implantação do SPIRE (SPIFFE Runtime Environment) versão 1.9.0, complementada pela pyspiffebiblioteca versão 0.3.0 para aplicações Python 3.12 que requerem integração direta com a API Workload.

Implementação passo a passo

Provisionando a infraestrutura da confiança mútua.

A ancoragem de uma identidade Zero Trust em vários provedores de nuvem depende da criação de uma infraestrutura capaz de validar as propriedades físicas e criptográficas das cargas de trabalho em tempo de execução. Em vez de emitir certificados manuais de longa duração, implantamos instâncias do SPIRE Server em ambas as nuvens, configurando-as para operar em um regime de federação de chaves. O servidor AWS atesta o ambiente utilizando o mecanismo AWS IAM Roles for Service Accounts (IRSA), enquanto o servidor Azure valida as cargas de trabalho por meio do Azure Workload Identity. As duas instâncias trocam seus JSON Web Key Sets (JWKS) continuamente. Essa troca permite que um cluster em execução no Azure valide autonomamente se um token SPIFFE apresentado por um contêiner originário da AWS foi assinado por uma autoridade legítima. Provisionamos as funções de atestação AWS fundamentais utilizando o Terraform para garantir que o servidor SPIRE tenha as permissões precisas necessárias para consultar a API de metadados do EC2.

resource "aws_iam_role" "spire_server_attestation" {
  name = "spire-server-node-attestor-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRoleWithWebIdentity"
        Effect = "Allow"
        Principal = {
          Federated = var.aws_eks_oidc_provider_arn
        }
        Condition = {
          StringEquals = {
            "${var.aws_eks_oidc_url}:sub" = "system:serviceaccount:spire:spire-server"
          }
        }
      }
    ]
  })
}

resource "aws_iam_policy" "spire_node_resolver" {
  name        = "spire-node-resolver-policy"
  description = "Permits SPIRE Server to validate EC2 instance metadata for EKS nodes"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = [
          "ec2:DescribeInstances",
          "autoscaling:DescribeAutoScalingGroups"
        ]
        Resource = "*"
        Action   = [
          "ec2:DescribeInstances",
          "autoscaling:DescribeAutoScalingGroups"
        ]
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "spire_attestor_bind" {
  role       = aws_iam_role.spire_server_attestation.name
  policy_arn = aws_iam_policy.spire_node_resolver.arn
}

Uma vez estabelecida a infraestrutura de atestação fundamental nos provedores de nuvem, como traduzimos essa validação em configurações SPIRE explícitas para permitir a troca de chaves criptográficas entre a AWS e o Azure?

Configurando a Federação de Identidades SPIFFE

Traduzimos a confiança mútua declarando manifestos de configuração estruturados que definem os limites estritos dos Domínios de Confiança. O servidor SPIRE, localizado na AWS, gerencia o aws.enterprise.internaldomínio, enquanto o Azure governa o outro azure.enterprise.internal. A configuração do servidor SPIRE deve apontar explicitamente para o endpoint HTTP que expõe as chaves públicas do domínio remoto. Esse alinhamento de segurança garante que, quando um microsserviço de processamento financeiro em execução no Azure AKS tenta se comunicar com um microsserviço de inventário no Amazon EKS, a assinatura criptográfica do Documento de Identidade Verificável (SVID) X.509 SPIFFE possa ser validada localmente, sem exigir uma requisição de alta latência de volta à nuvem de origem. Implantamos essa configuração deterministicamente usando um recurso ConfigMap do Kubernetes no Terraform, garantindo que as regras de federação sejam imutáveis ​​e controladas por versão.

resource "kubernetes_config_map" "spire_server_config" {
  metadata {
    name      = "spire-server"
    namespace = "spire"
  }

  data = {
    "server.conf" = <<-EOT
      server {
          bind_address = "0.0.0.0"
          bind_port = "8081"
          trust_domain = "aws.enterprise.internal"
          data_dir = "/run/spire/data"
          log_level = "INFO"
      }
      plugins {
          DataStore "sql" {
              plugin_data {
                  database_type = "postgres"
                  connection_string = "host=spire-db.internal user=spire dbname=spire sslmode=disable"
              }
          }
          NodeAttestor "aws_iid" {
              plugin_data {
                  cluster_name = "production-eks-cluster"
              }
          }
          KeyManager "memory" {
              plugin_data {}
          }
      }
      federation {
          bundle_endpoint_profile "https_spiffe" {
              endpoint_spiffe_id = "spiffe://azure.enterprise.internal/spire/server"
              endpoint_url = "https://spire-bundle.azure.enterprise.internal/spiffe/v1/bundle"
          }
      }
    EOT
  }
}

Com os domínios de confiança federados e os servidores comunicando-se de forma confiável, como os aplicativos utilizam essas identidades dinâmicas em tempo de execução para garantir o isolamento do tráfego por meio de políticas de autorização rigorosas?

Integração direta da API de carga de trabalho para mTLS

A implementação prática do Zero Trust é alcançada integrando a aplicação diretamente com o Agente SPIRE local por meio da API de Workload SPIFFE. Embora proxies sidecar como o Envoy sejam comuns, microsserviços Python de alta segurança ou com desempenho crítico podem obter suas identidades criptográficas diretamente do socket de domínio UNIX local fornecido pelo SPIRE. A aplicação Python invoca a pyspiffebiblioteca, que se comunica com o agente local para recuperar o SVID X.509 e o pacote de confiança federada. Quando a aplicação AWS inicia uma requisição HTTPS para o endpoint Azure, ela injeta seu SVID no contexto TLS. Durante o handshake, o microsserviço Azure valida a expiração do certificado e compara o ID SPIFFE contido no Nome Alternativo do Assunto (SAN) com uma lista de controle de acesso rigorosa. Se o identificador recebido for nulo spiffe://aws.enterprise.internal/ns/finance/sa/payment-processore a política local permitir apenas conexões do domínio de auditoria, o socket Python encerra a conexão imediatamente.

import os
import ssl
import urllib.request
from pyspiffe.workloadapi import default_x509_source
from pyspiffe.spiffe_id.spiffe_id import SpiffeId

# The SPIFFE Workload API UNIX socket is mounted by the SPIRE Agent
os.environ["SPIFFE_ENDPOINT_SOCKET"] = "unix:///run/spire/sockets/agent.sock"
AZURE_TARGET_ENDPOINT = "https://transactions.azure.enterprise.internal/api/v1/process"
EXPECTED_AZURE_SPIFFE_ID = SpiffeId.parse("spiffe://azure.enterprise.internal/ns/production/sa/api-gateway")

def execute_federated_mtls_request(payload: bytes) -> None:
    # Fetch the dynamic SVID and Trust Bundles from the local SPIRE Agent
    with default_x509_source() as x509_source:
        svid = x509_source.get_x509_svid()
        trust_bundle = x509_source.get_bundle_for_trust_domain(EXPECTED_AZURE_SPIFFE_ID.trust_domain)

        # Construct a highly restricted SSL Context utilizing the fetched SPIFFE material
        context = ssl.create_default_context(cadata=trust_bundle.x509_authorities()[0].public_bytes())
        context.load_cert_chain(
            certfile=svid.cert_chain[0].public_bytes(),
            keyfile=svid.private_key.private_bytes()
        )
        context.check_hostname = False 
        context.verify_mode = ssl.CERT_REQUIRED

        req = urllib.request.Request(
            AZURE_TARGET_ENDPOINT,
            data=payload,
            headers={"Content-Type": "application/json"},
            method="POST"
        )

        try:
            # The underlying socket utilizes the SPIFFE mTLS context
            with urllib.request.urlopen(req, context=context) as response:
                print(f"Federated request successful. Status: {response.status}")

                # Retrieve and manually validate the peer's SPIFFE ID from the SAN
                peer_cert = response.fp.raw._sock.getpeercert()
                san_entries = peer_cert.get('subjectAltName', [])
                peer_spiffe_ids = [val for key, val in san_entries if key == 'URI']

                if str(EXPECTED_AZURE_SPIFFE_ID) not in peer_spiffe_ids:
                    raise PermissionError(f"Unauthorized peer identity: {peer_spiffe_ids}")

        except Exception as e:
            print(f"mTLS Connection failed or identity rejected: {str(e)}")

if __name__ == "__main__":
    execute_federated_mtls_request(b'{"transaction_value": 5000}')

O que ocorre operacionalmente no ambiente de produção quando as chaves de federação perdem a sincronização devido à grave instabilidade de roteamento de rede entre nuvens?

Solução de problemas comuns

A dessincronização dos Trust Bundles entre domínios federados é a principal causa de falhas de conexão mTLS entre nuvens, geralmente manifestando-se como erros de handshake TLS com a SSL roulette: unknown CAdiretiva. Se essa degradação ocorrer, inspecione os logs do servidor SPIRE em busca de falhas de resolução no endpoint de federação externo. Se a rota da rede pública ou a VPN sofrer perda de pacotes, o servidor SPIRE deixará de atualizar as chaves da nuvem parceira. Para contornar esse comportamento e mitigar o tempo de inatividade causado por janelas de tempo limite curtas, ajuste o bundle_endpoint_refresh_intervalparâmetro no manifesto de federação para um mínimo de 15 minutos e certifique-se de que o barramento de rede local possua regras de persistência DNS ativas para os endpoints públicos dos servidores SPIRE.

Outro erro operacional frequente decorre da rejeição, durante a atestação de nós, de nós de computação recém-provisionados em grupos de escalonamento automático do Amazon EKS ou Azure AKS. Quando um novo nó é escalado, o Agente SPIRE, instalado como um DaemonSet, faz uma chamada à API do provedor de nuvem para validar as propriedades físicas da máquina. Se a política do IAM ou a Identidade Gerenciada associada ao Servidor SPIRE não tiver permissões explícitas para executar ações de leitura de metadados da instância ec2:DescribeInstances, a atestação falhará e as cargas de trabalho nesse nó específico nunca receberão suas identidades SPIFFE legítimas. Revise sistematicamente as funções do IAM anexadas à infraestrutura do Servidor SPIRE, garantindo que as ações de listagem e descrição estejam ativas e livres de escopos de recursos excessivamente restritivos.

Conclusão

A federação de identidades criptográficas via SPIFFE/SPIRE resolve a fragilidade latente da gestão de políticas de segurança multicloud baseadas exclusivamente em perímetros de rede tradicionais. Ao desacoplar a identidade da infraestrutura subjacente da AWS e do Azure, a arquitetura garante o isolamento criptográfico de ponta a ponta e impõe uma postura autêntica de Zero Trust. À medida que a malha operacional se expande, as organizações devem integrar ferramentas Open Policy Agent (OPA) diretamente ao caminho de execução da carga de trabalho. Essa evolução permite a avaliação detalhada do contexto das solicitações em tempo real, possibilitando a validação dos parâmetros regulatórios da carga útil no exato momento em que a identidade criptográfica é inspecionada na camada de transporte.