L'Infrastructure As Code (IAC)
Mise à jour :
Avec l’essor de la démarche DevOps, la nécessité de pouvoir provisionner et gérer les infrastructures informatiques rapidement a conduit à la création d’un nouveau type d’outils. L’infrastructure en tant que code (IaC) incarne cette évolution, offrant une approche automatisée pour le provisionnement et la gestion des ressources informatiques. Ce type d’outils transforme la gestion des infrastructures en permettant aux équipes de les traiter avec du code informatique, semblable à celui utilisé pour le développement de logiciels. Cette innovation favorise une relation plus étroite et plus synergique entre le développement (Dev) et les opérations (Ops) dans le cadre de la culture DevOps.
Au cœur de cette révolution se trouvent des outils comme Pulumi, Terraform et Ansible. Chacun de ces outils apporte une perspective unique à l’IaC. Pulumi, par exemple, permet aux développeurs d’utiliser des langages de programmation familiers pour définir et déployer l’infrastructure, tandis que Terraform utilise un langage déclaratif pour décrire l’état souhaité de l’infrastructure. Ansible, quant à lui, se concentre sur la gestion de configuration automatisée, facilitant la maintenance et le déploiement de configurations sur diverses machines.
En explorant ces outils et en examinant leurs applications pratiques, ce chapitre vise à vous fournir une compréhension profonde de l’IaC et de son impact sur le paysage technologique actuel.
Concepts Fondamentaux de l’IaC
Impératif vs Déclaratif
L’approche impérative en IaC décrit comment atteindre un état désiré, souvent à travers une série d’instructions ou de commandes.
En revanche, l’approche déclarative se concentre sur le quoi, décrivant l’état désiré de l’infrastructure sans préciser explicitement comment y parvenir.
Cette distinction est fondamentale dans le choix et l’utilisation des outils IaC.
Idempotence
L’idempotence est la propriété d’une opération qui, lorsqu’elle est effectuée à plusieurs reprises, produit le même résultat que si elle était effectuée une seule fois. En IaC, cela signifie que l’exécution répétée d’un script ou d’une configuration ne modifie pas l’infrastructure au-delà de l’état désiré initial.
Gestion de Configuration
La gestion de configuration est un processus systématique visant à établir et maintenir la cohérence des performances, des fonctionnalités et des attributs physiques et fonctionnels d’un produit tout au long de sa vie. Dans le contexte de l’informatique et de l’infrastructure en tant que code (IaC), la gestion de configuration fait spécifiquement référence à la pratique de gérer et de maintenir de manière automatisée et répétable les configurations logicielles et matérielles des systèmes et des infrastructures.
Provisionnement
Le provisionnement de ressources, dans le contexte de l’infrastructure as code se réfère au processus de création de l’infrastructure informatique nécessaire pour supporter diverses applications et services. Cela inclut la création, la configuration et la gestion des ressources telles que les serveurs physiques ou virtuels, le stockage, les réseaux, et d’autres composants logiciels et matériels.
Choix des Outils
Il est important de noter que chercher à opposer des outils ayant différentes utilisations est une démarche peu productive. Il est courant de voir des débats sur Terraform versus Ansible, mais il est essentiel de comprendre que ces outils sont en réalité complémentaires. Chacun d’entre eux possède ses propres forces et se spécialise dans des domaines spécifiques. Terraform excelle dans la création et la gestion des ressources d’infrastructure, tandis qu’Ansible se concentre sur la configuration des serveurs et des applications. En les utilisant de manière judicieuse en tandem, il est possible de tirer pleinement parti de leurs avantages respectifs, automatisant de manière exhaustive et efficace l’intégralité du cycle de vie de l’infrastructure en tant que code.
Donc au lieu de les considérer comme des concurrents, il est plus approprié de les voir comme des partenaires complémentaires travaillant de concert pour répondre aux besoins diversifiés de votre environnement informatique. Cette approche collaborative offre une flexibilité inestimable et décuple la puissance de l’automatisation. On peut ainsi imaginer des couples Pulumi/Salt, Terraform/Puppet…
Sécurité de l’Infrastructure as Code
L’IaC amplifie tout : les bonnes pratiques comme les mauvaises. Un secret
commité dans un dépôt Git se retrouve répliqué sur tous les clones. Une
mauvaise configuration de sécurité se propage à toute l’infrastructure en un
terraform apply. Les principes de sécurité
s’appliquent donc avec une rigueur particulière.
Gestion des secrets
Les fichiers IaC contiennent souvent des références à des ressources sensibles : credentials cloud, tokens API, mots de passe de bases de données. Ces secrets ne doivent jamais apparaître en clair dans le code.
| Anti-pattern | Bonne pratique |
|---|---|
| Mot de passe en dur dans le code | Référence à un gestionnaire de secrets |
| Variables d’environnement non chiffrées | Intégration Vault, AWS Secrets Manager, etc. |
Fichier .tfvars commité | Fichier .tfvars dans .gitignore |
| State Terraform local non chiffré | Backend distant avec chiffrement (S3 + KMS) |
Pour approfondir : Gestion des secrets
Moindre privilège
Les credentials utilisés pour provisionner l’infrastructure ont souvent des droits étendus. Le principe de moindre privilège impose de limiter ces droits au strict nécessaire.
Pour les pipelines CI/CD :
- Utiliser des credentials temporaires (OIDC avec GitHub Actions, GitLab CI)
- Scoper les permissions au projet/environnement concerné
- Séparer les credentials de lecture (plan) et d’écriture (apply)
Pour les comptes de service :
- Un compte par environnement (dev, staging, prod)
- Pas de credentials partagés entre équipes
- Rotation régulière des secrets
Analyse statique du code IaC
Avant même le déploiement, le code IaC peut être scanné pour détecter des problèmes de sécurité : ports ouverts au monde, chiffrement désactivé, logs non activés.
| Outil | Spécialité |
|---|---|
| Checkov ↗ | Multi-framework (Terraform, CloudFormation, Kubernetes) |
| tfsec ↗ | Terraform spécifique |
| Trivy | IaC + images + SBOM |
| KICS ↗ | Multi-framework, requêtes personnalisables |
Ces outils s’intègrent dans les pipelines CI/CD pour bloquer les configurations non conformes avant qu’elles n’atteignent la production.
State et données sensibles
Le state Terraform (ou équivalent Pulumi) contient l’état réel de l’infrastructure, y compris des données sensibles (mots de passe générés, clés privées). Sa protection est critique.
Bonnes pratiques :
- Stocker le state dans un backend distant sécurisé (S3 + chiffrement, Terraform Cloud)
- Activer le verrouillage (DynamoDB pour S3) pour éviter les corruptions
- Restreindre l’accès au state aux seules personnes/pipelines autorisés
- Ne jamais commiter le state dans Git
Revue de code et validation
L’IaC bénéficie des mêmes pratiques que le code applicatif :
- Pull requests obligatoires : pas de modification directe sur main/master
- Revue par un pair : un second regard détecte les erreurs de configuration
- Plan avant apply : toujours vérifier le
terraform planavant d’appliquer - Environnements de test : valider les changements en dev/staging avant prod
Traçabilité et audit
L’IaC facilite l’audit : chaque modification est un commit, chaque déploiement est traçable. Exploitez cette traçabilité :
- Historique Git = journal des modifications d’infrastructure
- Logs des pipelines CI/CD = qui a déployé quoi et quand
- State versionné = possibilité de revenir en arrière
Cette traçabilité contribue à la non-répudiation : on peut prouver qui a fait quoi.
Conclusion
Maintenant que vous maitrisez la définition d’infra-as-code, concentrons-nous sur la gestion de Configuration.