L’intégration de microservices internes entre plusieurs fournisseurs de nuages présente des défis importants en matière d’authentification et de chiffrement du trafic. Ce guide technique détaille la mise en œuvre d’une topologie de maillage de services fédérée qui couvre Amazon EKS et Azure AKS. En ancrant l’identité de la charge de travail dans le cadre SPIFFE/SPIRE et en orchestrant le mTLS entre les nuages au moyen de passerelles Istio Multi-Primary, les équipes d’ingénierie établissent un plan de communication authentifié et à faible latence qui élimine les risques liés à des secrets partagés ou à l’exposition publique du réseau.
Introduction
Les systèmes distribués modernes répartissent souvent les charges de travail sur plusieurs environnements cloud afin de profiter de services gérés spécialisés ou d’imposer une redondance régionale stricte. Cependant, établir une communication sécurisée et à faible latence entre un microservice s’exécutant sur le Amazon Elastic Kubernetes Service (Amazon EKS) et une charge de travail dépendante sur le Azure Kubernetes Service (Azure AKS) révèle des failles architecturales fondamentales dans les schémas réseau traditionnels. S’appuyer sur des passerelles API publiques introduit une latence inutile et augmente la surface d’attaque externe, tandis que maintenir des VPN site-to-site permanents ou des circuit courts dédiés génère une complexité opérationnelle considérable et ne garantit pas la sécurité de la couche applicative. Nous remettons en question ces approches réseau centrées, en rejetant l’idée que la sécurité périphérique du réseau équivaut à l’autorisation des charges de travail.
Pour atteindre une véritable posture Zero Trust dans tous les environnements cloud, les organisations doivent désaccoupler la sécurité de la topologie réseau sous-jacente et mettre en place un maillage de services fédéré. En intégrant des architectures Istio Multi-Primary dans des réseaux distincts avec le Secure Production Identity Framework for Enterprise (SPIFFE) et son implémentation à l’exécution (SPIRE), les équipes d’ingénierie peuvent établir un plan d’identité cryptographique unifié. Les charges de travail sur AWS et sur Azure reçoivent des identités vérifiables et à courte durée de vie qui leur permettent d’initier des connexions TLS mutuellement authentifiées (mTLS) directement entre les fournisseurs, garantissant que chaque requête entre les nuages soit chiffrée, authentifiée et autorisée, quelle que soit la réseau de transit.
Pré-requisitos
La mise en place d’un maillage de services fédéré multi-cloud exige une connaissance approfondie des fondamentaux du réseau Kubernetes, des mécanismes de TLS mutuel et de la génération d’identités cryptographiques. La couche d’infrastructure est automatisée à l’aide de Terraform version 1.7.0 ou supérieure, en tirant parti des fournisseurs HashiCorp AWS, AzureRM et Helm. Les environnements Kubernetes nécessitent Amazon EKS et Azure AKS exécutant la version 1.29 ou ultérieure, avec Istio version 1.21 ou supérieure installée via Helm. La fédération des identités nécessite le déploiement de SPIRE version 1.9.0 dans les deux clusters, en utilisant la fédération OpenID Connect (OIDC) pour établir les relations de confiance initiales entre les serveurs SPIRE et les fournisseurs d’identité natifs du cloud.
Implementação passo a passo
Établissement du Plan d’Identité Unifié SPIFFE/SPIRE
L’exigence fondamentale d’une architecture de Zero Trust entre les nuages est l’élimination complète des clés cryptographiques partagées ou des identités statiques de longue durée. Si un pod sur EKS doit présenter une clé d’accès AWS IAM pour vérifier son identité auprès d’un consommateur sur AKS, le système hérite d’une vulnérabilité grave due à la charge de rotation des identités et aux risques d’exposition. Nous résolvons ce défi d’identité en implantant SPIRE en tant que racine de confiance dans les deux environnements cloud.
Le serveur SPIRE sur AWS EKS est configuré pour valider l’identité des pods locaux en utilisant l’attestateur de charge de travail natif de Kubernetes, en vérifiant des caractéristiques telles que l’espace de noms (namespace), le nom du compte de service et l’UUID du pod. Simultanément, le serveur SPIRE sur Azure AKS réalise une attestation symétrique des charges de travail locales. Fondamentalement, nous fédérons les deux installations SPIRE distinctes en établissant un échange de paquets de confiance SPIFFE. Chaque serveur SPIRE récupère et fait continuellement confiance aux clés cryptographiques publiques de son homologue, permettant que les charges de travail sur AWS valident les identités SPIFFE émises par le cluster Azure de manière 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"
}
}
Une fois l’infrastructure SPIRE fédérée et capable d’émettre des identités vérifiables globalement, comment intégrons-nous ce plan d’identité au maillage Istio afin de gérer la rotation automatique des certificats ?
Configuration d’Istio pour utiliser les certificats des charges de travail émis par SPIRE
Nous injectons les identités cryptographiques générées par SPIRE directement dans le plan de données d’Istio, en modifiant la configuration du côté Envoy pour communiquer avec l’Agent SPIRE via l’API Secrets Discovery Service (SDS) d’Envoy. Par défaut, Istio utilise sa propre autorité de certification interne (Istiod) pour émettre les certificats des charges de travail. Dans une déploiement multi-cloud, cela crée un scénario de “split brain” (cerveau partagé) où les proxies Envoy d’AWS ne peuvent pas valider les certificats générés par le plan de contrôle d’Azure Istiod sans une synchronisation complexe et manuelle de l’autorité racine.
En remplaçant l’autorité de certification native d’Istio par le socket de domaine Unix de l’agent SPIRE, Envoy ignore Istiod pour la génération des identités. Lorsqu’un pod est initialisé, l’agent SPIRE atteste le conteneur, génère un certificat X.509 extrêmement éphémère et de courte durée contenant l’ID SPIFFE unique de la charge de travail (par exemple spiffe://aws.enterprise.internal/ns/core/sa/payment-service) et le transmet dans la mémoire d’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
Avec les proxies du plan de données utilisant des certificats SPIRE fédérés, comment configurons-nous les couches de routage entre les nuages pour transmettre en sécurité ce trafic mTLS via l’Internet public ou les interconnexions privées sans rompre la correspondance TLS SNI ?
Ingénierie du routage du trafic entre les nuages via les passerelles leste-ouest d’Istio
Nous garantissons la sécurité et le routage du trafic entre les nuages en déployant des passerelles Istio East-West dédiées dans les deux clusters, en les configurant pour effectuer un routage passthrough basé sur le SNI. Exposer directement les points de terminaison internes du cluster au périmètre du réseau externe introduirait des vulnérabilités de sécurité graves. Au lieu de cela, nous faisons acheminer toutes les requêtes sortantes entre les nuages par le biais d’une passerelle de sortie dans le cluster d’origine, qui dirige le trafic à travers le périmètre réseau vers une passerelle d’entrée qui agit comme un point d’entrée East-West dans le cluster de destination.
Les passerelles sont configurées pour lire l’en-tête Server Name Indication (SNI) lors de la poignée de main TLS, en recherchant une correspondance avec le nom de domaine pleinement qualifié du service cible (par exemple, order-service.core.svc.azure.enterprise.internal). Fondamentalement, les passerelles n’interrompent pas la connexion TLS; elles agissent comme des proxys inverses de couche 4, transmettant directement les octets chiffrés vers le pod cible, où le déchiffrement final du mTLS et la vérification de l’identité SPIFFE ont lieu.
# 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"
Dépannage des problèmes courants
Le mode de défaillance le plus courant dans les maillages de services fédérés multi-cloud est le décalage des paquets de confiance entre les instances isolées du serveur SPIRE. Si un microservice s’exécutant sur AWS tente de se connecter à une charge de travail sur Azure et que les journaux du sidecar Envoy affichent SPIRE_FALSECERT_SIGNING_FAILEDou TLS_ERR_BAD_CERTIFICATE SPIRE_FALSE, les serveurs SPIRE ont échoué à échanger leurs paquets de confiance cryptographiques. Les opérateurs doivent vérifier que l’endpoint public exposant le paquet de fédération SPIRE (le chemin /v1/fedbundle) est entièrement accessible à travers le périmètre du cloud et protégé par des certificats valides et globablement approuvés. Si la boucle de synchronisation automatisée échoue en raison de règles de pare-feu strictes, les opérateurs devraient établir un pipeline d’automatisation hors bande à l’aide de Terraform pour exporter périodiquement les clés publiques de signature du serveur SPIRE d’AWS et les ajouter manuellement au magasin de confiance du serveur SPIRE d’Azure.
Une autre complication opérationnelle majeure concerne les limites strictes de MTU sur les réseaux inter-nuages. Lorsque Envoy encapsule le trafic en mTLS et attache de longues chaînes d’identité cryptographique SPIFFE à la poignée de main TLS, la taille du paquet dépasse fréquemment l’unité maximale de transmission (MTU) standard de 1500 octets des réseaux publics ou des gateways privés virtuels. Cette discordance entraîne le fragmentage silencieux des paquets, provoquant l’échec des handshakes TCP et l’expiration de la négociation mTLS lors des premières étapes. Pour remédier à ce problème, les ingénieurs doivent configurer explicitement un EnvoyFilter ou modifier les paramètres réseau CNI sous-jacents de Kubernetes afin de limiter la MSS (Maximum Segment Size) TCP à 1300 octets, garantissant que les paquets cryptographiques comportant plusieurs couches de chiffrement traversent les nœuds de routage multi-cloud sans fragmentation ni perte.
Conclusion
La fédération Istio et SPIFFE/SPIRE entre Amazon EKS et Azure AKS met en place un plan de communication extrêmement robuste et indépendant du réseau, illustrant parfaitement les paradigmes d’architecture Zero Trust. Le découplement de l’autorisation de la topologie réseau garantit que la compromission totale d’un routeur intermédiaire, d’un équilibreur de charge ou d’une configuration réseau dans le cloud ne permette pas à un intrus de falsifier l’identité d’une charge de travail ou d’intercepter des charges utiles transactionnelles sensibles. À mesure que l’échelle de la plate-forme croît, les équipes d’ingénierie devraient évaluer l’implémentation de plugins WebAssembly (WASM) dans les proxies Envoy. Cette stratégie permet l’injection dynamique de politiques complexes et localisées de conformité et d’obscurcissement des données directement à la périphérie du maillage, optimisant les contrôles de sécurité même avant que la charge utile ne traverse entre les nuages les frontières du réseau.
