Automatiser la sécurité Terraform dans les déploiements Scalr avec Regula [Tutoriel]

Présentation de l’intégration de Regula et Scalr

Regula

Regula permet aux équipes cloud d’analyser Terraform, CloudFormation, Azure Resource Manager et Kubernetes Infrastructure-as-Code (IaC) afin de détecter les problèmes de sécurité et de conformité avant le déploiement. Regula est une implémentation open source de Rego, le langage de requête utilisé par le projet Open Policy Agent (OPA). Le cas échéant, les règles de Regula sont associées aux référentiels CIS (Center for Internet Security) pour Amazon Web Services (AWS), Azure, Google Cloud et Kubernetes Foundation, afin de permettre aux utilisateurs d’appliquer ces règles à l’IaC avant le déploiement.

En analysant l’IaC pour détecter les mauvaises configurations avant le déploiement, Regula étend aux équipes de développement la responsabilité de la sécurité et de la conformité du cloud, d’une manière adaptée aux développeurs. Le goulot d’étranglement lié à la sécurité est ainsi éliminé lors du déploiement d’une infrastructure cloud avec l’IaC. Regula est maintenu par les ingénieurs de Fugue.

Scalr

Scalr est un logiciel d’automatisation et de collaboration Terraform (TACO) qui prend en charge l’automatisation des demandes de fusion, l’interface CLI native de Terraform et les workflows pilotés par des modules. Scalr aide les entreprises de toutes tailles à évoluer grâce à son modèle hiérarchique, qui centralise les opérations d’administration telles que le RBAC, le contrôle des règles via OPA, les vues opérationnelles et un registre de modules privé. Il en résulte une décentralisation maîtrisée des opérations Terraform, qui permet aux développeurs d’exécuter indépendamment les workflows Terraform dans leurs environnements.

Objectif

Associer les fonctionnalités pratiques et puissantes d’analyse IaC de Regula aux fonctions d’automatisation et de collaboration Terraform de Scalr, afin de montrer comment les entreprises peuvent automatiser le déploiement sécurisé d’une infrastructure cloud avec Terraform.

Prérequis

Pour suivre les étapes, vous aurez besoin des éléments suivants :

• Un compte Scalr avec les hooks personnalisés activés (remarque : cette fonctionnalité est payante). Vous trouverez ci-dessous les instructions de configuration.

• Un espace de travail configuré dans votre compte Scalr. Un espace de travail sert à stocker et gérer tous les objets associés aux ressources gérées par Terraform.

• Des identifiants de fournisseur cloud ajoutés à votre compte Scalr (pour cette démonstration, j’utiliserai AWS).

• Un fournisseur de système de contrôle de version (VCS) configuré dans votre compte Scalr (pour cette démonstration, j’utiliserai GitHub).

• Attribuez scripts/security.bash comme hook personnalisé « Before plan » et scripts/validate.bash comme hook personnalisé « After plan ».

• La dernière version de Regula dans votre répertoire /usr/local/bin (notre script security.bash la téléchargera et l’exécutera dans le pipeline Scalr, mais l’avoir en local vous permettra d’analyser votre code avant de le valider).

Vous pouvez également, si vous le souhaitez, cloner mon dépôt pour vous éviter une partie du travail, en exécutant la commande suivante dans votre terminal :

git clone https://github.com/fugue/fugue-scalr-integration.git

Que contient le dépôt ?

L’image ci-dessus présente la structure des fichiers de mon dépôt, qui contient notamment :

• main.tf : un fichier Terraform qui déclare les informations relatives aux fournisseurs et aux modules.

• s3/ : un sous-répertoire contenant des fichiers Terraform avec des vulnérabilités intentionnelles.

• waivers.rego : un fichier qui exempte certaines règles et les désactive.

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

• scripts/ : un sous-répertoire qui contient le hook personnalisé présenté ci-dessus.

Voici une vue plus détaillée du contenu du module S3, avec une superposition indiquant l’état de configuration de l’ensemble de l’infrastructure (les violations des référentiels CIS apparaissent en rouge) :

Configurer les hooks personnalisés de Scalr

Les hooks personnalisés permettent d’adapter le workflow Terraform de base à l’aide de commandes, de scripts ou d’appels d’API. En plus de l’analyse de sécurité et de conformité avec Regula, les scripts shell utilisés dans cette démonstration vérifient le formatage et la validation de Terraform.

Vous pouvez ajouter des hooks personnalisés lors de la création d’un espace de travail, ou à tout moment par la suite, en accédant aux paramètres de l’espace de travail et en indiquant ce qui doit être exécuté avant et après les commandes plan et apply. Voici comment configurer des hooks personnalisés :

Dans les options « Advanced » de la page « Settings », Scalr permet aux utilisateurs de choisir le chemin relatif dans lequel les commandes Terraform seront exécutées (j’ai sélectionné le répertoire s3/ pour cet exemple). C’est pourquoi le chemin d’accès aux scripts est précédé de “./../”.

Automatiser les analyses de sécurité en suivant la voie de la moindre résistance

Pour les novices comme pour les experts, la voie de la moindre résistance vers le cloud avec l’IaC consiste à utiliser du code Terraform trouvé sur Internet ou partagé par des collègues et des équipes, en supposant qu’il est sécurisé et conforme. Ce code peut réussir tous les contrôles de formatage, de lint et de validation disponibles, tout en exposant ceux qui l’utilisent à des vulnérabilités potentiellement dévastatrices.

Révéler les vulnérabilités cachées : analyser l’infrastructure avec Regula

Pour cette démonstration, j’ai volontairement choisi la voie de la moindre résistance en recherchant du code Terraform qui me permettrait de déployer un bucket S3 aussi rapidement que possible. Je vais commencer par vous montrer à quel point ce code Terraform est vulnérable en exécutant regula run localement dans ce dépôt :

Lorsque vous exécutez cette commande, Regula va :

• détecter automatiquement les fichiers IaC pris en charge dans l’ensemble du dépôt ;

• effectuer une analyse de sécurité et de conformité sur tous les fichiers IaC pris en charge détectés ;

• afficher les résultats de l’analyse par ordre décroissant de gravité, avec les informations suivantes :

  • l’identifiant et le titre de la règle Fugue (par ex. FG_R00099) ;

  • le niveau de gravité de la règle (par ex. [High]) ;

  • un lien vers les étapes de correction de la règle (par ex. https://docs.fugue.co/FG_R00099.html) ;

  • l’emplacement de la violation de règle, indiqué par fichier IaC.

Les résultats de l’analyse ci-dessus devraient inquiéter aussi bien les ingénieurs DevOps que les ingénieurs en sécurité. En copiant, en collant et en déployant du code vulnérable, nous nous exposons aux pirates qui utilisent l’automatisation pour détecter et exploiter ces vulnérabilités. De plus, j’ai réalisé cette analyse volontairement, sans l’intégrer à un pipeline (comme celui de Scalr) : ce n’est pas vraiment la voie de la moindre résistance ! Les violations passées nous apprennent que les pirates du cloud détectent les vulnérabilités grâce à l’automatisation, puis s’en servent (par exemple, un bucket S3 vulnérable) comme point d’entrée pour s’attaquer à l’infrastructure et aux données qu’il faut protéger le plus. Sans automatisation comparable pour configurer correctement les ressources avant leur arrivée dans le cloud, les attaques ne sont plus une question de « si », mais de « quand ».

Examinons ces violations de plus près en observant un extrait du code (si vous suivez les étapes, le code ci-dessous correspond aux lignes 18 à 26 de s3/bucket.tf ; l’indentation a été décalée vers la gauche pour faciliter la lecture) :

18server_side_encryption_configuration {
19  rule {
20    apply_server_side_encryption_by_default {
21      #Un-comment below to satisfy FG_R00099
22      #kms_master_key_id = aws_kms_key.mykey.arn
23      #sse_algorithm     = "aws:kms"
24    }
25  }
26}

J’ai associé les vulnérabilités intentionnelles de ce code à des commentaires qui indiquent comment le modifier pour respecter les règles numérotées fournies avec Regula. Tel qu’il est écrit actuellement, le code ci-dessus enfreint la règle FG_R00099 (une violation de gravité élevée selon les référentiels CIS) : s’il était déployé sans correction, ce bucket AWS Simple Storage Service (S3) exposerait les données au repos. Pour les novices qui lisent cet article, imaginez que vous laissiez ouverts le coffre-fort d’une banque et son compartiment de dépôt. Même si vous transportiez votre dépôt dans un véhicule blindé (le chiffrement en transit, dans cette analogie), ne pas verrouiller le coffre-fort et le compartiment de dépôt (activer le chiffrement côté serveur) pourrait rendre vains ces efforts de protection des données.

Ce qui est inquiétant dans cet exemple, c’est que la documentation Terraform dont j’ai tiré ce code explique comment déployer un bucket S3 aussi simplement que possible (comme le fait généralement la documentation), en privilégiant les exemples de paramètres obligatoires et en reléguant les paramètres facultatifs (dont le chiffrement côté serveur !) à des sections ultérieures, faciles à manquer. La configuration de vos ressources cloud relève après tout de votre responsabilité : votre fournisseur cloud ne fait que vous donner les moyens de déployer et d’utiliser l’infrastructure cloud en toute sécurité.

Pourquoi laisser la sécurité au hasard alors que vous pouvez si facilement l’automatiser ?

Flexibilité appliquée : exempter et désactiver des règles

Les impératifs opérationnels peuvent parfois entrer en conflit avec des règles de gravité faible ou moyenne. Par exemple, une entreprise qui dépend de la diffusion de contenu par l’intermédiaire d’un bucket S3 hébergeant un site web statique finira naturellement par se lasser de voir ce bucket enfreindre FG_R00229 (toutes les options « block public access » doivent être activées pour les buckets S3). Les utilisateurs de Regula peuvent exempter des ressources spécifiques de certaines règles ou désactiver complètement certaines règles. Pour cette démonstration, j’ai décidé d’exempter mon bucket de journalisation de la règle FG_R00274 et de désactiver complètement la règle Fugue FG_R00275 à l’aide de mon fichier d’exemptions (waivers.rego). Voici comme il est facile d’exempter et de désactiver des règles avec Regula :

package fugue.regula.config

waivers[waiver] {
  waiver := {
    #Waiving bucket logging (for the logging bucket)
    "rule_id": "FG_R00274",
    "resource_id": "module.s3.aws_s3_bucket.logbucket"
  }
}

rules[rule] {
  rule := {
    #Disabling cross region replication (budgetary purposes)
    "rule_id": "FG_R00275",
    "status": "DISABLED"
  }
}

Mettre en œuvre la sécurité IaC : empêcher les mauvaises configurations d’atteindre le cloud

Voyons maintenant comment Regula s’associe au backend d’état distant et d’opérations Terraform de Scalr pour empêcher le déploiement dans le cloud d’une infrastructure mal configurée.

Le premier script de hook personnalisé (security.bash) télécharge, extrait, déplace et exécute la dernière version de Regula, analyse tous les fichiers Terraform (en langage HashiCorp (HCL) ou sous forme de plans Terraform JavaScript Object Notation (JSON)) et génère soit un code de sortie différent de zéro accompagné d’un message qui interrompt la compilation Scalr, soit un code de sortie égal à zéro qui permet à la compilation Scalr de se poursuivre.

Le script de hook personnalisé suivant (validate.bash) vérifie que le code Terraform de ce dépôt est valide et correctement formaté selon les normes canoniques HCL. Si le code Terraform n’est pas valide, ce script génère un code de sortie différent de zéro. S’il est valide, Scalr poursuit la compilation en exécutant automatiquement terraform plan et terraform apply. Votre infrastructure est alors déployée dans le cloud et l’état Terraform est conservé dans son interface facile à utiliser.

Lancer une compilation (et échouer)

Je vais maintenant vous montrer ce qui se passe lorsque je valide du code Terraform vulnérable dans mon dépôt GitHub. Je commence par exécuter les commandes suivantes (<files> est un espace réservé qui désigne les fichiers à valider et à envoyer sur GitHub) :

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

Scalr détectera les modifications apportées à mon dépôt et utilisera les scripts que j’ai fournis pour analyser mon code Terraform à la recherche de problèmes de sécurité et de conformité :

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 dans VSCode et exécuter localement regula run pour corriger ces problèmes (je pourrais également exporter les résultats de la commande regula run exécutée par Scalr). J’ai configuré ce dépôt de façon à pouvoir facilement réactiver les corrections de mon code Terraform en supprimant les commentaires, mais configurer correctement votre infrastructure est aussi simple que de cliquer sur le lien qui apparaît pour chaque règle après l’exécution de regula run. Remarquez que les deux règles que je corrige (FG_R00036 et FG_R00101) ne nécessitent qu’une seule ligne de code chacune. Ces lignes proviennent directement des étapes de correction de la règle accessibles via le lien fourni dans les résultats de la commande. Difficile de faire plus simple pour les développeurs.

Lancer une compilation (et réussir !)

Mon infrastructure étant correctement configurée, je vais à nouveau valider mes modifications dans mon dépôt GitHub afin de tirer le meilleur parti des fonctionnalités d’automatisation Terraform de Scalr. Les scripts de hook personnalisés s’exécuteront de nouveau, puis, s’ils réussissent, Scalr exécutera terraform plan et terraform apply.

Pour vous le montrer, je vais réexécuter les commandes lancées au départ :

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

… et la compilation s’est terminée avec succès !

Et voilà ! Grâce à Regula et Scalr, nous disposons désormais d’un pipeline qui automatise en toute sécurité le déploiement d’une infrastructure cloud avec Terraform.

Étapes suivantes

L’exemple ci-dessus montre comment sécuriser votre IaC conformément aux CIS Benchmarks. Pour utiliser d’autres référentiels de conformité (tels que HIPAA, SOC 2, ISO 27001, NIST 800-53, le RGPD, PCI DSS, AWS WAF ou CSA), rendez-vous sur www.fugue.co. L’exemple montre également des hooks personnalisés (une fonctionnalité payante de Scalr). Pour bénéficier d’autres fonctionnalités pratiques, comme l’estimation des coûts de l’infrastructure cloud, des agents auto-hébergés, le SSO ou des aperçus des règles, rendez-vous sur https://www.scalr.com/.

Vous souhaitez en savoir plus sur Regula ? Consultez notre dépôt GitHub et notre documentation. Regula analyse le code HCL de Terraform, les fichiers JSON de plans Terraform, les fichiers YAML/JSON de CloudFormation, les manifestes YAML de Kubernetes 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 souhaitez découvrir d’autres façons d’automatiser le déploiement sécurisé d’une infrastructure cloud ? Consultez notre article de blog sur l’intégration de Regula et Travis CI, ou celui sur l’intégration de Regula et Bitbucket Pipelines.