Les architectures monolithiques multi-régionales dépendent intrinsèquement de plans de contrôle globaux propres à chaque fournisseur. Lorsqu’une dégradation cataclysmique frappe un service d’identité ou une infrastructure réseau sous-jacente chez un seul fournisseur de cloud, toutes les partitions régionales échouent simultanément. Se reposer exclusivement sur Amazon Web Services (AWS) ou sur Microsoft Azure limite la disponibilité théorique maximale d’une plateforme à l’intégrité opérationnelle de ce seul prestataire. La mise en œuvre d’une architecture cellulaire multicloud fédérée permet de lever ce risque existentiel. En orchestrant des partitions isolées de Kubernetes sur Amazon EKS et sur Azure AKS à l’aide d’une maillage de services entre clouds, les équipes d’ingénierie bâtissent une matrice de routage qui perdure face aux défaillances globales des fournisseurs. Cette topologie isole les domaines de défaillance au niveau de l’hyperviseur, en tirant parti du routage BGP dynamique et du TLS mutuel fondé sur un proxy pour ériger une infrastructure résiliente, indépendante des fournisseurs. Cela garantit la continuité d’exécution pour des charges de travail à hautes performances lorsque les zones de disponibilité d’un seul cloud disparaissent.
Prérequis
La mise en œuvre d’un maillage multicloud fédéré exige une connaissance approfondie des réseaux avancés et de l’orchestration de conteneurs. L’infrastructure nécessite Terraform version 1.7.0 ou supérieure, initialisé avec la hashicorp/awsversion 5.40.0 et la hashicorp/azurermversion 3.90.0 du provider. Pour automatiser l’injection du plan d’identité, il faut Python 3.12, accompagné du kubernetesclient Python version 29.0.0. L’architecture dépend de Istio version 1.21.0 ou supérieure, configuré pour des déploiements multi-réseaux et serveurs primaires. Un accès administratif est obligatoire pour provisionner les AWS Transit Gateways, les Azure Virtual Network Gateways et les Numéros de Système Autonome (ASN) BGP.
Implémentation étape par étape
Établir l’épine dorsale BGP entre les clouds
Nous construisons le pont réseau physique entre les fournisseurs de cloud en provisionnant un VPN IPsec Site-to-Site qui connecte directement un AWS Transit Gateway à un Azure Virtual Network Gateway. La justification architecturale de ce réseau superposé est le déterminisme absolu du routage. Dépendre du routage public d’Internet pour communiquer entre clouds introduit une variabilité de latence inacceptable et expose la télémétrie interne à des interceptions externes. Un tunnel IPsec dédié, protégé par des clés pré-partagées, assure la livraison de paquets chiffrés et prévisible. En activant le routage BGP dynamique sur cette connexion, le réseau devient auto-récupérant. Si une Zone de Disponibilité d’AWS subit une partition réseau complète, le démon BGP retire automatiquement les routes compromises. Les cellules du Azure AKS reconnaissent instantanément le changement de topologie et redirigent le trafic vers les sous-réseaux AWS survivants sans intervention manuelle de l’opérateur.
resource "aws_customer_gateway" {
bgp_asn = 65515
ip_address = azurerm_public_ip.azure_vpn_ip.ip_address
type = "ipsec.1"
tags = {
Name = "Azure-AKS-Boundary"
}
}
resource "aws_vpn_connection" "multicloud_mesh_vpn" {
customer_gateway_id = aws_customer_gateway.azure_gateway.id
transit_gateway_id = aws_ec2_transit_gateway.mesh_tgw.id
type = aws_customer_gateway.azure_gateway.type
static_routes_only = false
tunnel1_preshared_key = var.high_entropy_ipsec_key
tunnel2_preshared_key = var.high_entropy_ipsec_key
}
resource "azurerm_local_network_gateway" "aws_tgw_local" {
name = "aws-tgw-boundary"
resource_group_name = azurerm_resource_group.multicloud.name
location = azurerm_resource_group.multicloud.location
gateway_address = aws_vpn_connection.multicloud_mesh_vpn.tunnel1_address
bgp_settings {
asn = 64512
bgp_peering_address = aws_vpn_connection.multicloud_mesh_vpn.tunnel1_cgw_inside_address
}
}
Comment pouvons-nous établir une confiance cryptographique entre les microservices opérant sur AWS EKS et sur Azure AKS, lorsque chaque fournisseur utilise des autorités de certification (CA) distinctes et propriétaires pour leurs identités gérées en interne ?
Identité fédérée via Autorité de Certification Racine unifiée
Nous établissons la confiance cryptographique en dissociant complètement le plan d’identité des fournisseurs de cloud, en déployant une maillage Istio avec plusieurs primaires, ancré par une Autorité de Certification (AC) racine unifiée et hors ligne. L’exigence architecturale absolue ici est de découpler l’authentification à confiance zéro du IAM et de Azure AD. Une fonction AWS IAM ne peut pas s’authentifier nativement à une identité de charge de travail d’Azure. En provisionnant une AC racine partagée, nous générons des certificats intermédiaires spécifiquement pour les plans de contrôle d’Istio qui opèrent à la fois sur EKS et sur AKS. Lorsque le proxy sidecar Envoy sur AWS EKS établit une connexion avec le proxy Envoy sur Azure AKS, les deux proxies présentent des certificats TLS signés par leurs intermédiaires respectifs. Comme ces intermédiaires se connectent à la même AC racine hors ligne, les proxies valident avec succès la négociation TLS mutuelle (mTLS). Cela isole strictement l’exécution du domaine des silos d’identité propres au fournisseur.
import base64
import os
from kubernetes import client, config
from kubernetes.client.rest import ApiException
def inject_intermediate_ca(cluster_context: str, cert_path: str, key_path: str, root_cert_path: str) -> None:
config.load_kube_config(context=cluster_context)
v1 = client.CoreV1Api()
with open(cert_path, ''rb) as cert_file, open(key_path, ''rb) as key_file, open(root_cert_path, ''rb) as root_file:
cert_data = base64.b64encode(cert_file.read()).decode(''utf-8')
key_data = base64.b64encode(key_file.read()).decode(''utf-8')
root_data = base64.b64encode(root_file.read()).decode(''utf-8')
secret_manifest = client.V1Secret(
metadata=client.V1ObjectMeta(
name="cacerts",
namespace="istio-system"}),
type="Opaque",
data={
"ca-cert.pem": cert_data,
"ca-key.pem": key_data,
"root-cert.pem": root_data,
"cert-chain.pem": cert_data}
}
)
try:
v1.create_namespaced_secret(namespace="istio-system", body=secret_manifest)
print(f"Successfully injected intermediate CA into {cluster_context}")
except ApiException as e:
if e.status == 409:
v1.replace_namespaced_secret(name="cacerts", namespace="istio-system", body=secret_manifest)
print(f"Updated existing intermediate CA in {cluster_context}")
else:
raise RuntimeError(f"Failed to inject CA: {e.reason}")
if __name__ == "__main__":
inject_intermediate_ca("aws-eks-admin", "certs/aws-ca-cert.pem", "certs/aws-ca-key.pem", "certs/root-cert.pem")
inject_intermediate_ca("azure-aks-admin", "certs/azure-ca-cert.pem", "certs/azure-ca-key.pem", "certs/root-cert.pem")
resource "kubernetes_manifest" "multicloud_failover_policy" {
manifest = {
"apiVersion" = "networking.istio.io/v1beta1"
"kind" = "DestinationRule"
"metadata" = {
"name" = "transaction-service-routing"
"namespace" = "enterprise-core"
}
"spec" = {
"host" = "transaction-service.enterprise-core.svc.cluster.local"
"trafficPolicy" = {
"outlierDetection" = {
"consecutive5xxErrors" = 3
"interval" = "10s"
"baseEjectionTime" = "30s"
"maxEjectionPercent" = 100
}
"loadBalancer" = {
"localityLbSetting" = {
"enabled" = true
"failover" = [
{
"from" = "us-east-1"
"to" = "eastus"
}
]
}
}
}
}
}
}
Quand le basculement automatisé masque avec succès un redirectionnement entre les clouds, comment les opérateurs de la plateforme identifient-ils la dégradation silencieuse du réseau principal AWS avant que la partition de repli Azure n’atteigne sa capacité maximale ?
Dépannage courant
Les opérateurs de plateforme identifient la dégradation silencieuse en surveillant des anomalies spécifiques dans la télémétrie du proxy, même si des configurations inexactes masquent souvent ces signaux. En établissant l’infrastructure BGP entre les clouds, l’état du VPN Site-to-Site AWS peut rester en état Active à partir de l’état initial jusqu’à parvenir à Established. Cela indique précisément un échec de négociation de la proposition IKE en phase 1 ou en phase 2. Vérifiez que les algorithmes de chiffrement et les groupes Diffie-Hellman configurés sur le AWS Transit Gateway correspondent exactement à la politique IPsec appliquée au Azure Virtual Network Gateway.
Si l’infrastructure BGP est intègre, mais que les requêtes entre clouds renvoient HTTP 503 Service Unavailable avec le tag URX « Upstream Retry Limit Exceeded » dans les journaux du proxy Istio, la poignée TLS échoue. Cela se produit souvent lorsque les certificats CA intermédiaires injectés dans l’espace de noms istio-system expirent ou lorsque les identifiants SPIFFE des workloads ne correspondent pas au domaine de confiance attendu. Inspectez les journaux du sidecar Envoy TLS error: Secret is not supplied by SDS et vérifiez si le secret cacerts a été lu correctement par le plan de contrôle d’Istiod lors de l’initialisation du pod.
Conclusion
La fédération de clusters Kubernetes sur AWS et Azure au moyen d’un maillage de services Istio offre un environnement d’exécution à l’épreuve des attaques. En reliant EKS et AKS par un réseau BGP dynamique et en imposant l’identité via une Autorité de Certification Racine indépendante du fournisseur, les architectures peuvent survivre à une perte totale du plan de contrôle régional d’un fournisseur de cloud. Les organisations qui adoptent ce modèle cellulaire avancé devraient mettre en œuvre des méthodologies GitOps à l’aide d’outils tels que ArgoCD. Cela garantit que les états de déploiement des applications restent synchronisés instantanément à travers la matrice multicloud, évitant que la dérive de configuration n’entrave les chemins de bascule du Azure lors d’événements critiques de basculement.
