L’une des questions les plus récurrentes dans l’utilisation de Terraform est la gestion des secrets. Il existe de nombreuses bonnes pratiques liées aux clés d’API, aux mots de passe et aux tokens d’authentification. Dans cet article, nous verrons les techniques les plus utiles pour sécuriser efficacement votre environnement Terraform.
L’équipe Ambient ITVous souhaitez devenir expert en développement d’applications performantes ? Notre formation React vous permettra de maitriser le développement d’applications monopage avec Redux et TypeScript.
L’équipe Ambient IT
Secrets en texte brut
La règle numéros une de la gestion des secrets dans Terraform est de ne pas stocker les secrets en texte brut dans le code de votre environnement.
Si des informations sensibles comme les identifiants et mots de passe administrateurs sont stockés en brut dans le code, toute personne avec un accès au code pourra le voir. De plus, chaque ordinateur ayant un accès au système de contrôle des versions possèdera une copie des secrets présents.
Lorsqu’un ordinateur consulte un répertoire, il peut faire une copie locale. Cela inclut l’ordinateur de chaque développeur de votre équipe, chaque ordinateur impliqué dans le CI (par exemple, Jenkins, CircleCi, GitLab, etc.), chaque ordinateur impliqué dans le contrôle de version, chaque ordinateur présent dans le déploiement, et ainsi de suite.
Si les secrets sont stockés en clair sur chaque ordinateur, cela implique aussi que chaque software installé sur chaque ordinateur peut également lire ce secret. Lorsque plusieurs ordinateurs et logiciels ont eu accès aux secrets, il n’existe aucun moyen d’agir rétroactivement sur cette situation, il est aussi presque impossible de savoir précisément qui a eu accès (il n’existe aucun journal d’audit). En cas d’intrusion, cela vous compliquera énormément la tache dans la traque et la résolution de la faille.
En bref, stocker des données sensibles en clair dans le code de votre infrastructure donne d’innombrables opportunités à des acteurs malveillants d’y accéder.
Sécuriser L’État de Terraform
Même si vous cryptez toute trace d’information confidentielle dans votre code Terraform, il restera toujours un endroit où ces informations seront présentes en clair : l’état.
Chaque fois que vous déployez une infrastructure avec Terraform, ce dernier stocke de nombreuses données sur cette infrastructure, y compris tous les paramètres que vous avez transmis, dans un fichier d’état. Il s’agit par défaut d’un fichier terraform.tfstate automatiquement généré dans le dossier où vous avez exécuté terraform apply.
Même en étant très précautionneux dans le code, vous aurez donc à sécuriser ce dossier pour empêcher toute intrusion dans votre environnement Terraform. La meilleure technique pour se protéger reste de stocker l’état de Terraform dans un backend qui prend en charge le chiffrement au lieu de le stocker dans un fichier local terraform.tfstate. Terraform supporte une grande variété de backends prenant en charge le chiffrement garantissant ainsi une sécurité optimale. Ces backends sont aussi utiles pour le travail d’équipe puisqu’ils prennent également en charge des fonctions de collaboration.
Vous devrez contrôler de manière très stricte qui à accès a votre backend Terraform. Par exemple, si vous utilisez S3 comme backend, vous devrez configurer une politique IAM qui n’accorde l’accès au bucket S3 pour la production qu’à une petite poignée de développeurs de confiance.
Variables d’environnement
Vous pouvez utiliser des variables d’environnement pour les secrets que vous souhaitez transmettre
variable "username" {
description = "The username for the DB master user"
type = string
}
variable "password" {
description = "The password for the DB master user"
type = string
}
Il vous suffit ensuite de passer les variables aux ressources qui en ont besoin.
resource "aws_db_instance" "example" {
engine = "mysql"
engine_version = "5.7"
instance_class = "db.t2.micro"
name = "example"
# Set the secrets from variables
username = var.username
password = var.password
}
Vous pouvez maintenant passer une valeur pour chaque variable en définissant une variable d’environnement.
Cette technique permet de stocker des secrets en texte clair dans votre code, mais elle ne permet pas de gérer les secrets de manière parfaitement sécurisée.
Encryptage de fichiers
Une autre technique consiste à chiffrer les secrets, stocker le texte dans un fichier puis enregistrer ce fichier dans le système de contrôle des versions.
Pour crypter les secrets, vous avez besoin d’une clé de cryptage. Seulement cette clé est elle-même un secret. Pas question, donc, de la stocker en texte clair dans le code de votre infrastructure.
Pour la stocker en toute sécurité, vous aurez besoin d’une solution de codage de clé comme AWS KMS, GCP KMS ou Azure Key Vault. Cette méthode vous permet de stocker vos secrets en texte clair, mais en les gardant dans votre système de contrôle des versions sans risque. Ils sont donc testés et empaquetés avec le reste du code. Cela permet de réduire les erreurs de configuration.
Cependant, le cryptage des données peut conduire à du travail supplémentaire. Vous devrez soit utiliser des commandes, soit utiliser un outil externe. De plus, les secrets étant toujours présents dans le système de contrôle des versions, si un utilisateur malveillant compromet le système de cryptage, il peut revenir en arrière et accéder à tous les secrets cryptés avec cette clé.
Secret Stores
Une troisième technique consiste à stocker les secrets dans une base de donnée dédiée au stockage des données sensibles comme AWS secret Manager, HashiCorp Vault ou AWS Param Store.
Cette méthode comporte de nombreux avantages. Les secrets sont stockés complétement en dehors de votre code dans un outil appliquant des règles d’accès et de confidentialité strictes. L’utilisation d’un tel outil demande beaucoup moins de compétences techniques que les solutions précédentes. De plus, les secrets stores prennent en charge l’automatisation de la rotation de secret, réduisant fortement les risques de compromissions ainsi que d’un journal d’audit clair permettant de savoir qui accède à vos secrets.
Ces magasins disposent généralement d’une API pouvant facilement être utilisée à partir de vos applications.
Comme les secrets ne sont pas versionnés, empaquetés et testés avec votre code, les erreurs de configuration sont plus probables. L’ajout d’un nouveau secret dans un environnement et l’oubli de l’ajouter dans un autre environnement (par exemple, production) peut conduire à des problèmes dans votre infrastructure Terraform. Les tests peuvent également être plus difficiles à réaliser.