Les risques liés à la supply Chain Terraform

Même si nos conseils vous aideront, notre formation Terraform reste le meilleur moyen d’acquérir une maitrise complète de l’outil. Vous y apprendrez l’utilisation et la configuration de Terraform avec des outils cloud afin d’automatiser votre infrastructure de manière performante.

L’équipe Ambient IT

La supply chain dans les applications

Avant de nous pencher sur les vulnérabilités en elles-mêmes, penchons-nous sur la supply chain. C’est l’une des sources de vulnérabilité les plus communes lors de la création d’applications web.

Les providers Terraform permettent aux équipes DevOps une très grande flexibilité dans leurs tâches quotidiennes. Ils sont aux cœurs des missions liées à la gestion des ressources et à l’automatisation. Ces composants tiers sont donc essentiels dans le bon fonctionnement de Terraform.

L’ajout de composant tiers ouvre généralement la porte à de nombreuses vulnérabilités potentielles. Si ces derniers sont mal configurés et/ou obsolètes, cela peut conduire à de nombreux problèmes de grande ampleur et particulièrement nocifs pour votre application.

S’il existe des solutions « locales » pour résoudre ses problèmes (comme le cadre SLSA développé par Google, l’Open Source Security Foundation et Chainguard), il n’existe pas de technique officielle et disponible à grande échelle.

Comment faire, donc, pour réduire ses vulnérabilités tout en profitant des avantages de la répétabilité et de l’évolutivité de l’IaC ?

Réduire les risques de sécurité dans Terraform

Il existe un certain nombre d’actions possibles pour améliorer la sécurité de la chaîne d’approvisionnement de votre pipeline Terraform. Vous devez par contre impérativement garder à l’esprit que ces solutions ne sont pas universelles. Elles ne couvrent malheureusement souvent qu’un seul aspect du problème. Maintenir une sécurité optimale dans votre infrastructure Terraform est une tâche complexe qui demande des connaissances profondes de l’outil.

Utiliser des informations d’identification temporaires

Générer des identifiants temporaires à chaque fois que vous avez besoin de donner un accès privilégié est une des meilleures astuce pour assurer la sécurité de vos environnements Terraform. Vous pouvez, par exemple, utiliser un accès basé sur OIDC pour obtenir un jeton d’accès.

Cette méthode est très efficace pour lutter contre les attaques liées au credential mining. Elle pose néanmoins 2 problèmes :

• Si les informations d’identifications sont suffisamment privilégiées, un pirate informatique peut contourner cette méthode en créant des rôles IAM ou des utilisateurs auxquels il peut accéder plutôt que d’attaquer directement le système d’identification.
• Certaines applications cloud ne prennent pas en charge les informations d’identification temporaires.

L’utilisation d’informations d’identification temporaire n’est donc pas une solution idéale, mais elle est néanmoins efficace comme technique de première ligne de défense face à de nombreux vecteurs d’attaque courants.

Utiliser des hash de commits plutôt que des tags

Lorsque l’on utilise Terraform, il est courant de s’appuyer sur des balises de version lors de l’extraction du code d’un module. L’avantage et l’inconvénient de ses balises réside dans le fait qu’elles fournissent la version sémantique de votre code et qu’elles le rendent donc complètement lisible pour n’importe qui. Les balises Git étant des alias du hachage du commit, un acteur malveillant pourrait insérer du code dans une branche non protégée et insérer une balise qui pointe vers cette branche.

Un autre cas de figure serait la modification d’une étiquette par un hackeur. En déplaçant une balise existante pour la faire pointer vers un commit différent, il est possible d’intégrer des modules malveillants sans modifier le code. Rendant donc l’intrusion très difficilement détectable.

L’alternative est donc d’utiliser directement le commit SHA associé au tag. Cela sacrifie une partie de la lisibilité de votre code, mais vous gardez l’assurance de toujours tirer le ref exact du commit que vous attendez.

Cette méthode représente quelques inconvénients :

• Le Terraform Registry ne permet pas d’extraire directement le commit SHA. Pour utiliser cette méthode, vous devrez extraire le module directement de git. Cela peut ne pas être possible si vous avez des politiques de sécurité en aval qui imposent une liste restreinte de sources.
• Il faut également ajouter des protections de branche sinon les SHAs des commits peuvent également être mutables. Le niveau d’accès nécessaire pour cela est généralement déjà très élevé dans la plupart des organisations. La plupart du temps, le pire qui puisse donc arriver est que le module ne soit plus disponible.
• S’appuyer sur des SHA de commit augmente les risques liés à des facteurs humains en raison de l’augmentation de la charge cognitive. Ce désavantage peut néanmoins jouer dans les deux sens et encourager les développeurs à examiner attentivement chaque mise à jour de dépendance pour s’assurer que le ref fait référence à une étiquette de version et à une branche protégée.

Malgré ces désavantages, cette méthode est idéale pour fournir un niveau de protection de base en garantissant que vous tirez toujours le même code de version de module.

Ajouter des contrôles statiques sur les dépendances

Il est possible d’utiliser l’analyse statique du code Terraform pour vérifier vos sources. Par exemple, la bibliothèque go terraform-config-inspect permet de collecter une liste de dépendance afin de s’assurer que :

• La référence renvoie à une étiquette de version sémantique
• Le commit référencé est associé à la branche de publication attendue
• La branche de publication attendue est protégée

Cette méthode peut être intégrée comme test unitaire avec le framework terratest ou comme un linter CLI s’exécutant avant terraform plan. Cette méthode présente 2 inconvénients :

• Cela complexifie le code de contrôle qui devra donc être renforcé
• Cette méthode est très dépendante de votre capacité à assurer que le fichier de workflow ne peut pas être facilement mis à jour pour sauter l’étape de validation statique.

Bien configurée, cette méthode offre une garantie plus forte que l’utilisation de la SHA pour les références.

Ajouter des validations statiques pour le code tiré dans Terraform

Les outils d’application des politiques de Terraform comme OPA, Sentinel ou Checkov sont connus et sont souvent utilisés pour l’application de politiques sur la sortie du plan. Il existe cependant une méthode d’utilisation alternative.

Il existe des moyens d’utiliser ces outils afin d’exécuter une analyse statique sur le code Terraform lui-même. Par exemple, il est possible d’utiliser OPA de la façon suivante :

• Lancez terraform.init. Cela permet d’extraire tous les modules afin qu’ils soient disponibles pour l’analyse.
• Utilisez hcl2json pour les convertir au format JSON
• Vous pouvez maintenant rédiger une politique OPA garantissant que toutes les ressources et sources de données utilisées proviennent de l’un des fournisseurs autorisés

Cette méthode demande un pipeline parfaitement sécurisé afin de fonctionner. De plus, en fonction des règles que vous définissez, cela peut devenir complexe à maintenir dans le temps. Le succès de cette méthode dépendant de la vérification, il est important de trouver un bon équilibre afin de réaliser cette tâche sans la bâcler par manque de temps.

Cette méthode a l’avantage d’analyser le code réel plutôt que les références. L’attaquant n’a donc aucune importance même si celui-ci a été en mesure de cacher du code malveillant via le pipeline.

Conclusion

Assurer la sécurité de la chaîne d’approvisionnement de votre code Terraform est tout aussi important que d’assurer celle de la chaine d’approvisionnement de votre code applicatif. Même si HashiCorp n’offre pas encore de réelle solution de première ligne afin de s’en assurer, ces méthodes vous permettront d’en limiter les risques.