Un outil pour analyser la sécurité des templates Terraform

L’utilisation d’un outil d’Infrastructure as Code est incontournable lorsque l’on déploie dans le cloud. Terraform fait partie de ces outils permettant de définir son infrastructure dans un fichier source, fichier qui pourra être modifié, versionné et réutilisé pour plusieurs environnements ou régions. Oui mais comment s’assurer qu’il n’y a pas un trou dans la raquette ?

Comment j’ai découvert l’outil tfsec

Dans un précédent article, j’ai expliqué comment je fais ma veille technique. En plus de cette veille que l’on pourrait caractériser de “structurée”, il m’arrive aussi de partir à l’aventure sur le web. LinkedIn et Reddit sont bien souvent mes points de départ de ces expéditions, je me transforme alors en un Mike Horn mais un peu plus geek !

C’est ainsi que je suis tombé sur le site de Thomas Gerardin, en particulier sur un article s’intitulant Ma boîte à outils DevOps. L’un des outils présentés est tfsec, un analyseur de template terraform permettant de détecter des problèmes de sécurité. Quels genres de problèmes ? Un security group trop permissif, l’activation du chiffrement en transit ou au repos ou encore des recommandations au niveau de l’observabilité comme par exemple la mise en place des access logs pour une API.

Comment s’utilise cet outil

Les deux principales façons d’utiliser cet outil sont la ligne de commande et la CI/CD.

Si l’on souhaite l’utiliser un ligne de commande, la première étape est de l’installer sur sa machine. Sur mac le plus simple est d’utiliser homebrew :

brew install tfsec

Ensuite il est possible de lancer tfsec en spécifiant le répertoire où se trouve les fichiers que l’on souhaite analyser :

tfsec ./infra/

Si aucun répertoire n’est spécifié, le répertoire de travail en cours sera utilisé.

En ça donne quoi comme résultat ? Bonne question ! Prenons par exemple ce template terraform :

resource "aws_security_group_rule" "mon-groupe-super-secure" {
    type        = "ingress"
    description = "un security group super secure pour l'ingress"
    cidr_blocks = ["0.0.0.0/0"]
}

Le résultat affiché dans la console sera le suivant :

Concernant l’intégration continue, le plus simple est d’utiliser les images Docker disponibles. Plusieurs formats de sorties sont possibles, à adapter en fonction de l’outil utilisé pour surveiller la qualité du code. On trouve donc du json, du csv, du checkstyle ou encore du sarif.

Voici un exemple de ce qu’il est possible de faire avec GitLab CI :

tfsec:
  stage: security
  image:
    name: aquasec/tfsec-ci
  script:
    - tfsec -f json --out tfsec.json --soft-fail
  rules:
    - when: always
  artifacts:
    paths:
      - tfsec.json

Le paramètre --out permet de spécifier le fichier de sortie des résultats tandis que --soft-fail permet de retourner un code 0 en toute circonstance et évite ainsi de faire échouer le pipeline.

Ma modeste contribution

Après avoir testé l’outil sur ma machine, j’ai commencé à mettre en place une CI. Cela fonctionnait bien dans l’ensemble mais je n’arrivais pas à importer les avertissements dans Sonar Cloud. J’ai alors découvert que l’export des résultats au format Checkstyle avait un bug. J’ai l’habitude dans ce cas là de proposer une contribution open-source. C’est ce que j’ai fait avec la pull request 388.

Concrètement comment j’ai procédé ? J’ai tout d’abord identifié le code source de Checkstyle afin de bien comprendre le format attendu. Ensuite j’ai écrit un test unitaire qui échouait, afin de reproduire le comportement attendu. Enfin j’ai corrigé le bug et j’ai vérifié que le test passait avec ce correctif. Mes changements étaient prets pour la pull request !

Si tu es arrivé jusqu’ici, merci beaucoup d’avoir lu cet article !
Pense à t’abonner à la mailing list pour ne rater aucun article, le formulaire se trouve en bas de page.
Photo de couverture par FLY:D.