Mise à jour : Le code de mes implémentations est désormais public ! Retrouvez mes Landing Zones sur GitHub. J’y propose 3 déclinaisons complètes (AWS, GCP, Azure). Bien que chaque fournisseur ait ses propres particularités techniques, l’architecture reste agnostique : nous pouvons déplacer nos applications de l’un vers l’autre sans le moindre problème. Avec l’utilisation de Kubernetes, c’est encore plus simple : la conteneurisation permet de s’abstraire totalement de la couche matérielle et du CSP sous-jacent.
Introduction
La création d’une infrastructure dans le Cloud ne devrait pas rimer avec enfermement propriétaire (“Vendor Lock-In”). L’enjeu majeur pour les entreprises est de concevoir une base réseau, sécuritaire et de gouvernance capable de s’adapter, quel que soit le fournisseur Cloud. C’est ce que nous appelons une Landing Zone Agnostique.
L’idée est de bâtir un socle solide pour accueillir nos charges de travail tout en garantissant qu’elles puissent évoluer de manière homogène dans n’importe quel environnement.
Pourquoi une Landing Zone Agnostique ?
Se forcer à créer un socle générique a une immense valeur. Les concepts fondamentaux de la micro-segmentation, du FinOps, et du Zéro Trust sont universels.
- Gouvernance et Identité : Au lieu de reposer uniquement sur les spécificités de l’IAM d’un fournisseur, nous normalisons les rôles et utilisons des mécanismes standardisés pour la fédération d’identité. L’identité devient le vrai périmètre.
- Topologie Réseau : Que l’on utilise un VPC sur AWS, Azure ou GCP, nous mettons en place des règles “Deny by Default”, des inspections en périphérie (L7) et des passerelles isolées.
- Automatisation : Le déploiement s’effectue via de l’Infrastructure as Code (IaC), rendant l’architecture prédictible, auditable et reproductible à l’infini.
L’objectif de cette approche est de conserver une liberté totale de mouvement, tout en s’assurant qu’on ne sacrifie jamais la sécurité de la production.
Les Particularités des 3 CSP
Même si nous concevons une architecture agnostique, l’implémentation technique variera nécessairement selon le Cloud Provider (AWS, GCP, Azure) :
- AWS : L’accent est mis sur l’industrialisation via les organisations, l’usage des Service Control Policies (SCPs) pour bloquer les dérives, et les Transit Gateways pour gérer le réseau tentaculaire.
- GCP : La force de Google réside dans son Global VPC natif et le Network Connectivity Center. Cela permet des architectures Anycast mondiales avec une simplicité déconcertante par rapport à ses concurrents.
- Azure : La structure repose sur un design Hub-and-Spoke maîtrisé, avec un recours intensif au Virtual WAN (vWAN) et un durcissement profond par les Azure Policies.
La magie de ce modèle, c’est que la charge applicative hébergée n’a pas besoin de connaître ces détails. Elle consomme l’infrastructure (réseau, sécurité, logs) de la même manière, peu importe où elle atterrit.
Conclusion
Construire une Landing Zone agnostique demande un effort de conception initial plus important, mais c’est le prix de l’indépendance. En standardisant la gouvernance, le réseau et la sécurité, nous offrons à nos applications un environnement de production véritablement portable, prêt à basculer vers le meilleur fournisseur selon les opportunités financières ou techniques.
Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome
Implémentation & Hardening Hybride (CLI OPA/Conftest & Terraform Multi-CSP)
Pour appliquer le modèle 80 % Agnostique / 20 % Natif recommandé par la CNCF [1] et les référentiels CIS Benchmarks [2], on valide systématiquement les plans Terraform en CI/CD avec Open Policy Agent (OPA / Conftest) [3] avant tout déploiement sur AWS, Azure ou GCP :
1. Commandes CLI : Validation Policy-as-Code Agnostique avant apply
# Générer le plan Terraform binaire et l'exporter en JSON agnostique
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json
# Valider le plan avec OPA / Conftest (zéro IP publique, chiffrement CMEK actif, tags FinOps présents)
conftest test tfplan.json --policy ./policies/rego/
2. Terraform HCL : Module Agnostique avec Garde-Fous precondition / postcondition
variable "environment" {
type = string
validation {
condition = contains(["prod", "staging", "dev"], var.environment)
error_message = "L'environnement doit être prod, staging ou dev."
}
}
resource "kubernetes_namespace_v1" "workload_ns" {
metadata {
name = "app-${var.environment}"
labels = {
"pod-security.kubernetes.io/enforce" = "restricted"
"pod-security.kubernetes.io/audit" = "restricted"
"pod-security.kubernetes.io/warn" = "restricted"
"finops.cost-center" = "platform-secops"
}
}
}