ShiftLeft avec TFSec

Le ShiftLeft ou “décalage à gauche” dans la langue de Zizou est un concept qui veut que l’on apporte la sécurité au plus tôt dans le cycle de développement (DLC). Sur une trame temporelle qui va de gauche à droite, cette sécurité “au plus tôt” se positionnera sur le côté gauche, d’où ce nom de “ShiftLeft”.

Représentation graphique du principe de ShiftLeft

Ce concept possède plusieurs avantages :

Détection au plus tôt

  • Plus tôt les faiblesses/vulnérabilités de sécurité sont détectées, plus tôt elles peuvent être corrigées

Gain de temps

Si la sécurité est apportée tardivement il y a des risques d’avoir déjà déployé des environnements vulnérables. Le DevOps sera amené à corriger et redéployer sur ces environnements (potentiellement dans la panique)

Gain de coûts

Si le DevOps est amené à redéployer des environnements, il perd du temps mais aussi de l’argent, le coût d’un employé ou d’une prestation étant à prendre en compte. En revanche, si la faiblesse/vulnérabilité de sécurité est exploitée, le coût peut être exponentiel. Il peut être de quelques milliers d’euros à quelques millions d’euros en fonction du contexte (sans compter les impacts sur l’image).

Mises en Production (MeP) sereines

Si la sécurité a été testée tôt dans le cycle de développement, on a normalement pas à s’en soucier le jour de la MEP !

Pour respecter le principe de ShiftLeft, nous devons apporter de la sécurité à gauche, dans notre contexte cela se concrétise par réaliser des tests TFSec le plus tôt possible. Nous pouvons les intégrer à plusieurs moments dans notre cycle de développement.

Pour rappel TFSec c’est un SAST (Static Analysis Security Testing) principalement dédié à Terraform. Cet outil est capable d’analyser le code Terraform pour en déduire les potentielles faiblesses de sécurité de nos infrastructures, et cela avant même qu’elles soient déployées. Je propose une découverte de cet outil dans l’article : https://blog.wescale.fr/tfsec-decouverte/

Intégration à la CI

Vous pouvez intégrer TFSec dans vos pipelines. La documentation officielle propose 2 solutions :

  • GitHub Action : pour enrichir l’onglet “Security” de GitHub lors de vos push ou pull requests (PR)
  • PR Commenter : pour ajouter des commentaires de changement d’échec des tests TFSec lors d’une PR

Je vais présenter brièvement la seconde option :

Il suffit d’ajouter un fichier tfsec_pr_commenter.yml dans le répertoire .github/workflows à la racine de votre projet Git. Ajoutez-y le contenu suivant :

name: tfsec-pr-commenter
on:
  pull_request:
jobs:
  tfsec:
    name: tfsec PR commenter
    runs-on: ubuntu-latest

    steps:
      - name: Clone repo
        uses: actions/checkout@master

      - name: tfsec
        uses: tfsec/tfsec-pr-commenter-action@main
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

Et voilà ! À chaque PR, TFsec sera exécuté et ajoutera des commentaires pour chaque problème détecté.

Documentations associées :

Nous avons certes TFSec qui se déclenche automatiquement sous forme de pipeline à chaque PR. C’est très bien, c’est très DevOps même. Le problème c’est que dans notre cycle de développement ce test est réalisé relativement tardivement. Si des problèmes sont présents, on aurait aimé être prévenu plus tôt.

On aurait pu mettre en place le GitHub Action qui peut se déclencher au moment du push, c’est plus tôt. Cependant on peut réaliser un scan TFSec avant même que le code ne soit poussé.

Pre-commit

Pre-commit est un outil qui se hook (branche) à git afin d’exécuter des actions moment du commit. Si les tests échouent le commit n’est pas réalisé. Dans notre cas, le test consistera en l’exécution de TFSec.

Si le concept de pre-commit en général vous intéresse, je vous invite à lire l’article de Stéphane Teyssier sur le sujet : https://blog.wescale.fr/vers-linfrastructure-craftsmanship-avec-les-git-hooks/

Une fois que vous avez installé pre-commit et lié votre shell vous pouvez configurer le déclenchement automatique de TFSec à chaque commit. Pour cela il faut ajouter un fichier .pre-commit-config.yaml à la racine de votre projet et y ajouter le code suivant :

default_stages: [commit]
repos:
 - repo: https://github.com/antonbabenko/pre-commit-terraform
   rev: v1.62.3
   hooks:
     - id: terraform_tfsec

Maintenant à chaque commit, une vérification TFSec sera effectuée. Si un problème est détecté, le commit sera annulé.

Un petit peu de pratique ça vous dit ? Je vous ai préparé un scénario Katacoda pour vous exercer à pre-commit avec Terraform :

Cliquez sur le chat !

Ressources associées :

C’est super, avant même de commit il y a un test (quasiment) automatique qui se déclenche. Cependant peut-on faire encore mieux ? Oui.

Plugin VSCode

Scanner avant même le commit ? Il suffit d’exécuter TFSec manuellement ! Pour nous aider il existe un plugin VScode qui nous met en évidence les problèmes remontés par TFSec. Il faut quand même appuyer sur un bouton pour déclencher le scan.

Résultats du Plugin TFSec dans VSCode

Plugin TFSec : https://marketplace.visualstudio.com/items?itemName=tfsec.tfsec

Si vous préférez Vim celui-ci dispose aussi d'un module non-officiel permettant d'avoir en direct les résultats TFSec : https://github.com/reireias/vim-tfsec

Bon, nous sommes théoriquement au plus tôt possible. Que devons-nous retenir ?

Conclusion

Si l’on exécute TFSec dès la rédaction du code, nous sommes théoriquement dans l’optimum du respect du principe de ShiftLeft. Cependant, est-ce vraiment ce que nous souhaitons ?

Il est important de retenir que le ShiftLeft a pour objectif d’apporter de la sécurité à gauche et non pas de la déplacer à gauche. Vous avez pu le remarquer, plus on remonte dans la chronologie du cycle de développement, plus on essaye de s’approcher de la quintessence du ShiftLeft, moins on respecte la méthodologie DevOps.

Le ShiftLeft est un concept très intéressant qui permet notamment d’apporter de la sécurité plus tôt mais cela n’est pas suffisant. Le respect du ShiftLeft repose beaucoup sur la bonne volonté des DevOps. Il faudra toujours réaliser des tests TFSec au niveau de la CI, des audits d’infrastructures ou encore des pentests.

J’espère que cet article vous aura plu ! J’ai aussi présenté ce sujet du “ShiftLeft de la sécurisation du code Terraform avec TFSec” lors des HashiTalks France 2022 : https://youtu.be/EEkVTrSAWvI?t=1705