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”.
Ce concept possède plusieurs avantages :
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)
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).
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/
Vous pouvez intégrer TFSec dans vos pipelines. La documentation officielle propose 2 solutions :
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: $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 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_tfsecMaintenant à 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 Killercoda pour vous exercer à pre-commit avec Terraform :
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.
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.
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 ?
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