L’extension de Terraform au-delà des frontières organisationnelles nécessite un équilibre minutieux entre standardisation et flexibilité. Grâce à des structures d’équipe claires, une gouvernance bien pensée, des processus CI/CD automatisés et un support d’outillage approprié, il est possible de gérer efficacement des infrastructures complexes à locataires multiples. Avec ces bases solides, vous pouvez étendre votre pratique de Terraform d’équipes individuelles à l’ensemble de l’organisation, tout en garantissant cohérence, sécurité et efficacité.

Cet article est la première partie d’une série sur la conception de la gestion multi-locataires en tant qu’Infrastructure-as-Code dans des infrastructures de grande envergure.

Terraform at Scale - Gestion des infrastructures à grande échelle

Partie 1a : Multi-Tenancy - Transmission d’informations aux unités organisationnelles et aux clients

Introduction

Dans le monde des infrastructures cloud modernes, le terme « Multi-Tenancy » peut sembler être l’un de ces mots à la mode que l’on entend en conférence tout en consultant discrètement ses e-mails sur son téléphone. Pourtant, pour les entreprises qui gèrent des dizaines, voire des centaines de locataires, départements ou clients sur une infrastructure commune, c’est une réalité incontournable : à mesure que le nombre de locataires augmente, la complexité croît de manière disproportionnée (souvent de façon quadratique ou cubique), car le nombre de dépendances et d’interfaces se multiplie.

Imaginez devoir gérer 20 projets Terraform distincts – chacun avec ses propres variables, états, backends et versions de modules.

Maintenant, imaginez devoir partager des informations réseau essentielles entre ces projets, sans utiliser de blocs de code dupliqués qui risqueraient inévitablement de diverger lors de la prochaine modification.

Et si cela vous semble encore gérable, ajoutez une autre dimension organisationnelle : imaginez en plus que différents employés et pipelines CI/CD mettent en œuvre l’infrastructure en tant qu’Infrastructure-as-Code dans ces projets. Peut-être même s’agit-il d’équipes provenant de différentes divisions de l’entreprise, avec des décideurs et des responsables distincts dans leur propre organigramme.

Bienvenue dans le monde de la gestion du Multi-Tenancy avec Terraform.

Les approches Terraform traditionnelles atteignent rapidement leurs limites dans ce contexte. Le modèle classique – un dépôt, un état, un espace de travail – fonctionne parfaitement pour des environnements limités. Mais dès que vous devez partager des informations entre des domaines d’infrastructure logiquement séparés, les choses se compliquent. Des questions cruciales se posent :

• Comment garantir que toutes les équipes accèdent aux mêmes configurations réseau fondamentales ?
• Comment faire en sorte que les modifications apportées à ces configurations soient automatiquement propagées aux équipes qui en dépendent ?
• Comment éviter que différentes équipes ne créent des configurations qui se chevauchent ou qui entrent en conflit, comme des plages d’adresses réseau identiques ?
• Comment éviter qu’une équipe n’écrase accidentellement les ressources d’une autre équipe ?
• Et comment garder une vue d’ensemble malgré la complexité croissante ?

Dans un précédent article , nous avons vu à quel point les catastrophes d’infrastructure peuvent survenir facilement. Le cas de Knight Capital – où un déploiement incohérent sur seulement huit serveurs a conduit à une perte de 460 millions de dollars – en est un avertissement sévère. Si un système unique, composé de quelques éléments seulement, peut entraîner de telles conséquences, qu’en est-il des environnements complexes à locataires multiples ?

La bonne nouvelle : avec les bons modèles et techniques, il est possible de maîtriser cette complexité. Terraform propose, avec son concept de Remote State, une approche élégante pour partager des informations entre différents domaines d’infrastructure, sans compromettre l’isolation des locataires.

Dans cette première partie de notre série « Terraform at Scale », nous allons précisément explorer cette problématique :

• Comment utiliser Terraform de manière efficace pour gérer des environnements Multi-Tenancy ?
• Comment transmettre des informations de manière ciblée entre unités organisationnelles ?

Nous examinerons des modèles pratiques qui ont été appliqués avec succès dans divers projets clients, et qui vous aideront à faire passer votre infrastructure Terraform au niveau supérieur – sans erreur à 460 millions de dollars.

Comprendre le Multi-Tenancy – bien plus que des environnements isolés

Lorsque l’on parle de Multi-Tenancy – ou de gestion multi-locataires – dans le monde du cloud, beaucoup imaginent d’abord des environnements totalement isolés : le client A dispose de son propre réseau, le client B a le sien, et jamais les deux ne doivent se croiser. Cette vision n’est pas incorrecte, mais elle est incomplète, en particulier dans le contexte de l’Infrastructure-as-Code (IaC).

Dans Terraform, le Multi-Tenancy ne se limite pas à la séparation technique des ressources, mais implique aussi une structuration organisationnelle du code, des états et des workflows. L’enjeu est d’organiser notre infrastructure de manière modulaire afin qu’elle reflète la réalité de notre organisation – qu’il s’agisse d’un prestataire de services avec des clients externes ou d’une entreprise regroupant plusieurs divisions et projets.

Séparation logique vs. séparation physique des locataires

Dans une séparation physique, chaque locataire dispose de ses propres ressources dédiées – serveurs, réseaux, systèmes de stockage. Cette approche garantit une isolation maximale, mais elle est coûteuse et souvent trop rigide. La séparation logique, en revanche, repose sur des ressources physiques partagées, tout en cloisonnant les données et les accès au niveau applicatif. En pratique, on observe généralement des modèles hybrides :

• Niveau réseau : VPC ou sous-réseaux dédiés par locataire, mais infrastructure physique partagée
• Niveau calcul : Instances VM dédiées, mais sur un même matériel physique
• Niveau données : Bases de données ou schémas dédiés, mais potentiellement hébergés sur les mêmes serveurs
• Niveau identité : Politiques IAM et rôles séparés, mais au sein d’un système d’identité commun

Avec Terraform, nous pouvons modéliser ces différents niveaux de séparation de manière efficace, mais nous devons concevoir soigneusement les flux d’informations entre eux.

L’organisation des locataires en pratique

En pratique, les structures multi-locataires sont rarement linéaires. Une entreprise type peut par exemple inclure :

• Divisions métier (Finance, RH, Production, Vente)
• Équipes fonctionnelles au sein de ces divisions (Développement, QA, Exploitation)
• Projets, souvent transversaux
• Environnements (Développement, Test, Production) pour chaque projet
• Structures régionales en raison de contraintes légales ou de latence

Ces dimensions organisationnelles se superposent, et notre structure Terraform doit pouvoir refléter cette complexité.

Bien que les fournisseurs cloud comme AWS avec Organizations ou OCI avec Compartments proposent des structures hiérarchiques, notre code Terraform doit souvent être encore plus granulaire. En effet, les différentes divisions et équipes ont leurs propres compétences, responsabilités et parfois même des attentes, objectifs et, dans le cas d’entreprises internationales, des différences culturelles.

Tout cela ajoute une couche de complexité qui, lorsqu’elle est traduite en code, peut entraîner des surprises – parfois bonnes, parfois mauvaises.

Un autre défi réside dans le fait que ces différentes dimensions nécessitent et produisent des informations variées. Par exemple :

• L’équipe réseau définit les réseaux et sous-réseaux de base,
• L’équipe sécurité configure les firewalls, les politiques et les certificats,
• L’équipe stockage gère les stockages en mode fichier, bloc et objet ainsi que les sauvegardes,
• L’équipe base de données met en place et maintient les bases de données,
• et les équipes applicatives doivent accéder à ces informations sans les dupliquer.

Le problème de l’héritage des informations

C’est précisément là que réside la véritable difficulté : comment garantir que les modifications apportées aux composants fondamentaux de l’infrastructure sont automatiquement propagées à toutes les autres parties qui en dépendent ?

• Si notre équipe réseau modifie une plage CIDR de sous-réseau, comment s’assurer que toutes les machines virtuelles en sont informées ?
• Si nous ajoutons de nouvelles régions cloud, comment garantir que toutes les équipes utilisent les mêmes paramètres standard ?

Dans un petit environnement, nous pourrions gérer tout cela au sein d’un unique Terraform State. Cependant, cela conduit rapidement à un monolithe de State avec :

• Des centaines, voire des milliers de ressources
• Des temps de planification excessivement longs
• Le risque qu’une équipe modifie involontairement les ressources d’une autre

L’alternative – des States totalement séparés sans partage d’informations – entraîne :

• De la duplication,
• Des incohérences,
• Et le tristement célèbre « Copy & Paste DevOps » que nous cherchons tous à éviter.

Heureusement, Terraform propose avec le concept de Remote State une solution élégante à ce dilemme. Dans la section suivante, nous verrons comment l’utilisation ciblée des Remote States permet d’assurer un héritage d’informations flexible et évolutif entre les locataires – sans compromettre leur isolation.

Le Terraform Remote State

Terraform stocke les informations relatives à votre infrastructure dans un fichier d’état – le State File, qui sert de Single Source of Truth pour l’infrastructure.

Quiconque a déjà accidentellement supprimé un fichier .tfstate local en est douloureusement conscient. Ce fichier, en apparence insignifiant, est la mémoire de Terraform – sans lui, Terraform ne sait plus quelles ressources ont déjà été créées et tenterait de tout provisionner à nouveau – souvent avec des conséquences désastreuses.

Qu’est-ce que Terraform Remote State et pourquoi est-il nécessaire ?

Cela apporte plusieurs avantages essentiels :

• Collaboration : Plusieurs membres d’une équipe peuvent travailler sur la même infrastructure sans avoir à échanger manuellement les fichiers d’état.
• Sécurité : Les fichiers d’état contiennent souvent des informations sensibles – un stockage centralisé permet une meilleure protection.
• State-Locking : Empêche plusieurs personnes d’effectuer des modifications simultanément, ce qui pourrait entraîner des incohérences.
• Partage d’informations : Les Remote States peuvent servir de source de données pour d’autres projets Terraform.

Dans les grandes infrastructures, ce dernier point est particulièrement crucial. Il permet de construire une architecture modulaire et évolutive :

• Chaque équipe ou projet gère son propre Terraform State, sans écrire directement de dépendances inter-équipes dans le code.
• Les composants d’infrastructure partagés (par ex. réseaux, contrôles d’identité et d’accès, services communs) peuvent être exposés en tant que Remote State par leurs équipes responsables.
• Les modifications de l’infrastructure globale sont automatiquement propagées aux projets qui en dépendent.

Importance du Remote State dans les architectures Multi-Tenancy

Dans un environnement Multi-Tenancy typique, nous avons plusieurs couches d’infrastructure interconnectées :

1. Infrastructure globale : Réseaux de base, configurations IAM, services partagés
2. Ressources spécifiques aux locataires : Bases de données, serveurs applicatifs, solutions de stockage…
3. Niveau applicatif : Workloads des locataires

Grâce aux Remote States, nous pouvons séparer proprement ces couches, évitant ainsi que les niveaux supérieurs dupliquent des informations de base provenant des couches inférieures.

Une équipe applicative, par exemple, peut accéder aux informations réseau gérées par l’équipe réseau sans avoir à définir ses propres ressources réseau.

Remote State en pratique

Voyons à quoi cela ressemble en pratique : 

• Une équipe d’infrastructure centrale gère les configurations réseau de base et les systèmes de stockage pour toutes les équipes dans un projet Terraform dédié.
• Le Security NOC central définit les pare-feu ainsi que les règles et politiques associées. 
• L’équipe Bases de données administre les bases de données et fournit aux locataires des partitions de bases de données isolées. 
• Une équipe applicative peut ensuite, dans ses propres projets Terraform liés aux différents flux de valeur, accéder aux informations réseau, aux systèmes de stockage, aux politiques de sécurité et aux bases de données sans avoir à les redéfinir. De même, les pipelines des différents flux de valeur peuvent échanger des données entre eux via Remote State.
• Si l’équipe réseau, stockage, sécurité ou bases de données effectue des modifications, celles-ci sont automatiquement propagées aux projets en aval.

La data source "terraform_remote_state" en détail

L’élément central de cet échange d’informations est la data source terraform_remote_state. Elle permet à un projet Terraform d’accéder au State d’un autre projet. Voici un exemple simple :

data "terraform_remote_state" "network" {
  backend = "remote"
  config = {
    organization = "my-org"
    workspaces = {
      name = "network-global"
    }
  }
}

resource "cloud_instance" "app_server" {
  image_id      = "image-12345678"
  instance_type = "standard"
  subnet_id     = data.terraform_remote_state.network.outputs.private_subnet_id
}

Dans cet exemple, l’équipe applicative accède à l’ID du sous-réseau défini par l’équipe réseau. L’élément clé est que nous ne pouvons accéder qu’aux valeurs explicitement définies en tant qu’output  – ce qui établit une interface claire entre les projets.

Autre fonctionnalité puissante : il est possible d’accéder aux States provenant de différents backends et ainsi d’échanger des informations entre différentes plateformes (par ex. AWS et OCI). Pour les organisations adoptant des stratégies multi-cloud, cela est particulièrement précieux.

Considérations de sécurité lors du partage des informations du State

Aussi puissant que soit le concept des Remote States, il nécessite une planification minutieuse en matière de sécurité. Les fichiers State peuvent contenir des informations sensibles :

1. Contrôle d’accès : Toutes les équipes ne doivent pas avoir accès à tous les Remote States. Utilisez les contrôles d’accès de votre backend (par ex. IAM Policies pour S3).
2. Données sensibles : Les fichiers State peuvent contenir des mots de passe et autres secrets. Utilisez sensitive = true pour les outputs de Terraform et envisagez l’utilisation de HashiCorp Vault pour gérer les secrets critiques.
3. Chiffrement : Assurez-vous que vos fichiers State sont chiffrés à la fois au repos et en transit.
4. Contrôle des outputs : Ne publiez que les informations réellement nécessaires dans les outputs. Chaque output introduit une dépendance et un risque potentiel de sécurité. N’incluez jamais de données sensibles dans un output. Évitez d’utiliser sensitive = true dans les outputs, car ces données ne peuvent pas être héritées.

Un modèle particulièrement efficace consiste à créer des "States d’interface" ou "Proxy-States", exclusivement destinés à fournir des informations filtrées aux autres équipes. Ceux-ci ne contiennent pas directement de ressources, mais uniquement des Data Sources qui extraient les informations depuis le State principal et les exposent sous forme d’outputs sélectionnés. Le locataire accède ainsi uniquement aux informations nécessaires, sans avoir accès aux données originales potentiellement sensibles ou destinées à d’autres locataires.

Avec ces bases en place, nous allons explorer un exemple d’architecture : comment le Multi-Tenancy fonctionne-t-il concrètement, et comment pouvons-nous utiliser les Remote States pour transmettre les informations entre les différentes unités organisationnelles ?

Nous répondrons à ces questions dans la suite de cette série, très prochainement.