Vérifier la sécurité de Terraform IaC dans CI/CD avec Regula et Bitbucket Pipelines [Tutoriel]

Regula 2.3.0 permet aux équipes cloud d’évaluer le code d’infrastructure (IaC) Terraform, CloudFormation, Azure Resource Manager et Kubernetes afin de détecter les violations de sécurité et de conformité avant le déploiement. L’intégration de Regula aux pipelines d’intégration et de livraison continues (CI/CD) va encore plus loin en automatisant le déploiement sécurisé de l’infrastructure cloud.

Dans cet article, nous allons montrer comment intégrer Regula à Bitbucket Pipelines (un service CI/CD intégré à Bitbucket) pour tester automatiquement les ressources Amazon Web Services (AWS) déclarées dans Terraform. Lorsque nous validerons des modifications dans notre dépôt contenant du code Terraform, cela déclenchera une compilation avec Bitbucket Pipelines. Nous verrons comment Regula détecte une vulnérabilité de sécurité et fait échouer la compilation CI, puis comment corriger la violation pour que la compilation réussisse.

Une fois la configuration terminée, le pipeline CI/CD exécutera les étapes suivantes :

1. Vous validez du code IaC dans une branche (dans cet exemple, nous validons nos modifications dans la branche main par souci de simplicité, mais vous pouvez également le faire — et personnaliser le processus — pour les demandes de tirage).

2. Vous envoyez les validations, ce qui déclenche une compilation Bitbucket Pipelines.

3. Bitbucket Pipelines exécute Regula sur votre dépôt (dans cet exemple, nous avons également inclus des vérifications de formatage et de validation Terraform afin de montrer les bonnes pratiques).

4. Si le code IaC de votre dépôt passe toutes les vérifications de Regula, la compilation Bitbucket Pipelines réussit. Dans le cas contraire, elle échoue.

Conseil : Même si chaque outil CI/CD est différent, vous pouvez suivre les étapes ci-dessus pour vérifier votre code IaC dans CI/CD avec Regula.

Prérequis

Pour suivre ce tutoriel, vous aurez besoin des éléments suivants :

• Un compte Bitbucket (un compte Bitbucket Cloud ou Bitbucket Server)

• L’authentification multifacteur activée sur votre compte Bitbucket

• Un compte et des identifiants de fournisseur cloud ajoutés à Bitbucket en tant que variables de dépôt (pour cette démonstration, j’utiliserai AWS)

• Un dépôt Bitbucket (cloné en local) contenant des ressources cloud déclarées avec Terraform (voir ci-dessous la structure de mon dépôt)

Que contient le dépôt ?

L’image ci-dessus représente visuellement la structure des fichiers du dépôt, qui contient notamment :

• main.tf : un fichier Terraform qui déclare le fournisseur et les informations du compte

• ec2/instance.tf : un fichier Terraform qui contient une vulnérabilité délibérée

• .regula.yaml : un fichier de configuration Regula qui indique comment je souhaite exécuter Regula dans ce dépôt

• bitbucket-pipelines.yml : un fichier de configuration Bitbucket Pipelines

Configurer Bitbucket Pipelines

Nous allons maintenant configurer Bitbucket Pipelines pour exécuter des compilations sur notre dépôt. Dans votre dépôt Bitbucket, cliquez sur « Repository Settings » à gauche de la page, puis faites défiler le menu qui s’affiche à gauche jusqu’à la section « Pipelines ». Cliquez sur « Settings », puis sur le bouton à côté de « Enable Pipelines » pour qu’il s’affiche en vert avec une coche blanche.

Les fichiers

Examinons les différents fichiers de notre dépôt, en commençant par ec2/instance.tf.

Le code Terraform vulnérable

Le fichier Terraform en langage de configuration HashiCorp (HCL) ec2/instance.tf déclare les ressources AWS suivantes :

• Une instance Elastic Compute Cloud (EC2)

• Un rôle Identity and Access Management (IAM) permettant d’accéder à l’instance EC2 ci-dessus

Pour montrer simplement la puissance de Regula, j’ai délibérément inclus des vulnérabilités de sécurité (ainsi que des commentaires indiquant comment les corriger) dans l’instance EC2. Remarque : ne déployez pas ce code Terraform sur AWS sans avoir corrigé ces violations de sécurité. Examinons ces vulnérabilités :

resource "aws_instance" "app_server18391111" {
    ami           = "ami-074cce78125f09d61"
    instance_type = "t2.micro"

    # Un-comment below to satisfy FG_R00253
    #iam_instance_profile = aws_iam_instance_profile.test_profile.name

    # Make the below declaration = false to satisfy FG_R00271
    associate_public_ip_address = true

    tags = {
        Name = "ExampleAppServerInstance18391111"
        Team = "dev"
    }
}

• La ligne 9 (actuellement commentée) associe notre instance EC2 au rôle IAM et au profil d’instance à utiliser pour y accéder, plutôt qu’à des clés d’accès IAM. En transmettant les informations du rôle à une instance EC2 au lancement, vous pouvez limiter le risque d’exposition des clés d’accès et empêcher qu’un utilisateur malveillant ne compromette l’instance

• La ligne 12 indique que l’instance EC2 doit avoir une adresse IP publique associée, ce qui pourrait permettre à des utilisateurs non autorisés d’accéder à votre instance EC2, même si vous disposez de listes de contrôle d’accès réseau ou de groupes de sécurité

Déployer cette instance EC2 telle quelle en production nous exposerait à des acteurs malveillants, qui pourraient détecter et exploiter cette vulnérabilité à l’aide d’outils d’automatisation, bien avant même que nous sachions qu’elle existe ! Heureusement, Regula inclut des centaines de règles pour analyser notre code IaC et détecter les violations des benchmarks du Center for Internet Security (CIS).

Configuration de Bitbucket Pipelines

Voyons comment le fichier bitbucket-pipelines.yml indique à Bitbucket Pipelines quoi faire lorsqu’une compilation est déclenchée. Tout d’abord, nous indiquons à Bitbucket qu’il s’agit d’un pipeline et, plus précisément, du pipeline par défaut (vous pouvez créer des pipelines distincts pour les demandes de tirage, différentes branches du dépôt et d’autres cas) :

pipelines:
 default:

J’ai choisi d’exécuter les étapes suivantes de manière séquentielle, mais je peux aussi les exécuter en parallèle en ajoutant la commande parallel dans la colonne à gauche des étapes.

Ensuite, je déclare ma première étape, qui utilise l’image Terraform de HashiCorp pour initialiser Terraform, mettre en forme mon code Terraform selon les normes canoniques HCL et vérifier sa validité (par exemple, en m’assurant que toutes mes variables et tous mes modules sont déclarés) :

- step:
    name: 1 - Initialize, Format, and Validate Terraform
    image: hashicorp/terraform
    script:
        - terraform init && terraform fmt
        - terraform validate

La deuxième étape de mon pipeline exploite la puissance de Regula : elle détecte automatiquement les fichiers IaC (Terraform, CloudFormation, Azure Resource Manager et manifestes Kubernetes) à la racine ou dans les sous-répertoires, puis analyse chaque fichier IaC détecté dans mon dépôt selon les normes CIS Benchmark (Fugue prend en charge dès l’installation d’autres référentiels de conformité, comme SOC 2, HIPAA et NIST 800-53).

- step:
    name: 2 - Scan Terraform Locally for Security and Compliance with CIS Benchmarks
    image: fugue/regula
    script:
        # Run in root directory first
        - regula run ./
        # Run in child directories next
        - regula run ./*/

La dernière étape réinitialise Terraform et utilise à nouveau l’image Terraform de HashiCorp, car chaque étape du pipeline Bitbucket s’exécute dans un conteneur Docker distinct ; les dépendances déclarées ne sont donc pas conservées d’une étape à l’autre. La dernière étape crée ensuite un plan Terraform et l’applique :

- step:
    name: 3 - Plan and Apply Secure, Valid Terraform
    image: hashicorp/terraform
    deployment: Production
    trigger: manual
    script:
        - terraform init
        - terraform plan
        - terraform apply -auto-approve

Lancer une compilation

Tenter une compilation — et échouer : après avoir modifié mon dépôt contenant des fichiers IaC, je commence par saisir les commandes suivantes dans mon terminal :

git add 
git commit -m "initiating the bitbucket pipeline"
git push

Lorsque Bitbucket Pipelines détecte le nouveau commit dans mon dépôt (ou si je le déclenche manuellement), il lance le pipeline décrit ci-dessus dans le fichier .yml. Voici ce qui se passe lorsque j’essaie de valider dans la branche main du dépôt du code Terraform qui enfreint les CIS Benchmarks :

Corriger les problèmes de configuration avec Regula

Maintenant que je sais que mes fichiers Terraform contiennent des erreurs de configuration, je peux retourner dans mon dépôt et exécuter Regula localement pour les corriger. J’ai configuré ce dépôt afin de pouvoir facilement décommenter mes corrections de code Terraform. Toutefois, configurer correctement votre infrastructure est aussi simple que de cliquer sur le lien vers la documentation de correction de la règle Fugue, qui apparaît pour chaque violation après l’exécution de regula. Voici comment j’ai corrigé les règles Fugue FG_R00253 et FG_R00271, puis vérifié à nouveau mon infrastructure en exécutant une dernière fois regula.

Réussir une compilation

Mon infrastructure étant correctement configurée, je vais à nouveau valider mes modifications dans mon dépôt Bitbucket afin de tirer pleinement parti de l’automatisation fournie par le pipeline Bitbucket configuré pour mon dépôt.

Je relance les commandes que j’ai exécutées au départ…

git add 
git commit -m "initiating the bitbucket pipeline"
git push

…et la compilation réussit :

Et voilà ! Nous avons maintenant un pipeline Regula/Bitbucket qui automatise en toute sécurité le déploiement d’une infrastructure cloud avec Terraform.

Exécuter Regula en local

Heureusement, vous n’avez pas besoin d’attendre que Bitbucket Pipelines (ou d’autres outils CI/CD) détecte les erreurs. Vous pouvez exécuter Regula en local avant de valider et d’envoyer vos modifications — et nous vous le recommandons ! Mon outil préféré est le hook pre-commit de Regula, qui met en pratique la défense en profondeur en obligeant les développeurs à corriger les violations de sécurité et de conformité avant de valider leur code. En détectant les problèmes plus tôt dans le cycle de développement, vous « déplacez la sécurité vers la gauche », accélérez le développement et gagnez du temps et de l’argent, tout en évitant bien des frustrations par la suite.

Commencez par installer Regula en local. Il s’agit d’un binaire autonome, qui ne nécessite l’installation d’aucun prérequis. Il vous suffit de suivre les étapes de la documentation correspondant à votre système d’exploitation.

Ensuite, depuis la racine de votre dépôt, exécutez la même commande que Bitbucket Pipelines :

regula run

Vous obtiendrez le même résultat que dans les journaux Bitbucket Pipelines. Mais en exécutant cette commande en local, vous éviterez de consommer des minutes de compilation et confierez aux développeurs une part de la responsabilité des équipes de sécurité, réduisant ainsi — voire éliminant ! — les blocages liés à la sécurité avant le déploiement.

Étapes suivantes

Vous souhaitez en savoir plus sur Regula ? Consultez notre dépôt GitHub et notre documentation. Regula évalue les fichiers Terraform HCL, les plans Terraform au format JSON, les fichiers CloudFormation YAML/JSON, les manifestes Kubernetes YAML et les modèles Azure Resource Manager afin d’en vérifier la sécurité et la conformité. Regula prend également en charge les dérogations, les règles personnalisées, l’activation ou la désactivation des règles, et bien plus encore.

Vous cherchez d’autres moyens d’automatiser le déploiement sécurisé de l’infrastructure cloud ? Découvrez notre article de blog sur l’intégration de Regula et Travis CI.