Mac```bash
brew install terraform awscli azure-cli jq

Vous pouvez également souhaiter exécuter quelques commandes de configuration rapides - cela vous fera gagner du temps plus tard :

Configurer pour AWS - indiquer à CloudGoat quel profil AWS utiliser.```bash
cloudgoat config aws

Connectez-vous à Azure - CloudGoat utilise le compte `az` actif.```bash
az login

Maintenant, à votre commande, CloudGoat peut `create` une instance d’un scénario dans le cloud. Une fois l’environnement prêt, un nouveau dossier sera créé dans le répertoire de base du projet, nommé d’après le scénario avec un identifiant unique de scénario ajouté. Dans ce dossier se trouvera un fichier appelé `start.txt`, qui contiendra toutes les ressources nécessaires pour commencer le scénario, bien que celles-ci soient également affichées dans la console lorsque la commande `create` se termine. Parfois, une paire de clés SSH nommée `cloudgoat`/`cloudgoat.pub` sera également créée.

> **Remarque :** Ne supprimez pas et ne modifiez pas le dossier d’instance du scénario ni les fichiers qu’il contient, car cela pourrait empêcher CloudGoat de gérer les ressources de votre scénario.

Pendant que vous parcourez le scénario, n’hésitez pas à consulter le fichier readme du scénario si vous avez besoin d’orientation. Si vous êtes bloqué, des aide-mémoire sont liés en bas de la procédure pas à pas de chaque route.

Lorsque vous avez terminé le scénario, supprimez toutes les ressources que vous avez créées vous-même (rappelez-vous : CloudGoat ne peut gérer que les ressources qu’il crée), puis exécutez la commande `destroy`. C’est toujours une bonne idée de jeter un coup d’œil rapide à votre console web par la suite, au cas où quelque chose n’aurait pas été supprimé.

Vous pouvez lire la documentation complète des commandes de CloudGoat [ici, dans la section Guide d’utilisation](#usage-guide).

## Comment utiliser l’image Docker de CloudGoat

[![Try in PWD](https://raw.githubusercontent.com/play-with-docker/stacks/cff22438cb4195ace27f9b15784bbb497047afa7/assets/images/button.png)](http://play-with-docker.com?stack=https://raw.githubusercontent.com/RhinoSecurityLabs/cloudgoat/master/docker_stack.yml)

### Option 1 : Exécuter avec le point d’entrée par défaut```console
docker run -it rhinosecuritylabs/cloudgoat:latest

## Scénarios Disponibles
(Groupés par difficulté)

<details open>
  <summary><strong>Facile</strong></summary>

---

### iam_enum_basics (Facile)
`cloudgoat create iam_enum_basics`

Dans ce scénario, vous démarrez avec les clés d'accès d'un utilisateur IAM de bas niveau nommé Bob. Votre tâche consiste à effectuer un inventaire approfondi des IAM en utilisant l'interface de ligne de commande AWS. En examinant les politiques gérées, les politiques en ligne, les appartenances aux groupes et les rôles assumables, vous découvrirez cinq indicateurs distincts.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_enum_basics/README.md)  

Contribué par Tyler Ramsbey

---

### data_secrets (Facile)
`cloudgoat create data_secrets`

Dans ce scénario, vous démarrez avec un utilisateur IAM disposant de permissions limitées. Votre tâche consiste à identifier une instance EC2 mal configurée qui fuit des identifiants dans ses données utilisateur, ce qui vous permet d'obtenir un accès SSH. À partir de là, vous devez pivoter en exploitant le service de métadonnées d'instance (IMDS) pour voler un rôle, énumérer les fonctions Lambda pour trouver des variables d'environnement cachées, et enfin compromettre un utilisateur ayant accès à l'objectif du scénario : un secret stocké dans AWS Secrets Manager.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/data_secrets/README.md)  

Contribué par Tyler Ramsbey

---

### beanstalk_secrets (Facile)
`cloudgoat create beanstalk_secrets`

Dans ce scénario, vous recevez des identifiants AWS à privilèges faibles qui accordent un accès limité à Elastic Beanstalk. Votre tâche consiste à énumérer l'environnement Elastic Beanstalk et à découvrir des variables d'environnement mal configurées contenant des identifiants secondaires. En utilisant ces identifiants secondaires, vous pouvez énumérer les permissions IAM pour finalement créer une clé d'accès pour un utilisateur administrateur. Avec ces privilèges d'administrateur, vous récupérez le dernier indicateur stocké dans AWS Secrets Manager.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/beanstalk_secrets/README.md)  

Contribué par Tyler Ramsbey

---

### sns_secrets (Facile)
`cloudgoat create sns_secrets`

Dans ce scénario, vous démarrez avec un accès de base à un compte AWS. Vous devez énumérer vos privilèges, découvrir un sujet SNS auquel vous pouvez vous abonner, récupérer une clé API divulguée, et enfin utiliser cette clé API pour accéder à une API Gateway afin d'obtenir le dernier indicateur.  

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/sns_secrets/README.md)  

Contribué par Tyler Ramsbey

---

### iam_privesc_by_key_rotation (Facile)
`cloudgoat create iam_privesc_by_key_rotation`

Exploitez des permissions IAM non sécurisées pour escalader vos accès. Commencez avec un rôle qui gère les identifiants des autres utilisateurs et trouvez une faiblesse dans la configuration pour accéder au rôle "admin". En utilisant le rôle admin, récupérez l'indicateur depuis Secrets Manager.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_key_rotation/README.md)

Contribué par Infrasec.sh 

---

### iam_privesc_by_rollback (Facile)
`cloudgoat create iam_privesc_by_rollback`

En commençant avec un utilisateur IAM très limité, l'attaquant peut examiner les versions précédentes des politiques IAM et en restaurer une qui accorde des privilèges d'administrateur complets, ce qui conduit à une escalade de privilèges.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_rollback/README.md)

---

### lambda_privesc (Facile)
`cloudgoat create lambda_privesc`

En commençant en tant qu'utilisateur IAM Chris, l'attaquant découvre qu'il peut assumer un rôle qui a un accès complet à Lambda et des permissions de passage de rôle. L'attaquant peut alors effectuer une escalade de privilèges en utilisant ces nouvelles permissions pour obtenir des privilèges d'administrateur complets.

> **Note :** Ce scénario peut vous obliger à créer certaines ressources AWS, et comme CloudGoat ne peut gérer que les ressources qu'il crée, vous devez les supprimer manuellement avant d'exécuter `./cloudgoat destroy`.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/lambda_privesc/README.md)

---

### sqs_flag_shop (Facile)
`cloudgoat create sqs_flag_shop`

Tout d'abord, commencez avec la page BOUTIQUE où vous pouvez acheter FLAG. Le site Web comporte plusieurs pages, et vous pouvez voir que le code source est exposé. Les attaquants analysent le code pour trouver des vulnérabilités et utilisent leurs privilèges pour acheter FLAG.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/sqs_flag_shop/README.md)
  
</details>

<details>
  <summary><strong>Moyen</strong></summary>

### static (Moyen)
`cloudgoat create static`

Dans ce scénario, vous agissez en tant qu'attaquant externe visitant un portail d'entreprise. En analysant l'application web, vous identifiez qu'elle charge des bibliothèques JavaScript critiques depuis un bucket S3 public. Vous devez découvrir une mauvaise configuration dans les permissions du bucket, effectuer une "attaque de la chaîne d'approvisionnement" en remplaçant la bibliothèque par du code malveillant, et attendre qu'un robot administrateur interne se connecte. Votre objectif est de capturer les identifiants du robot et de les exfiltrer vers le bucket.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/static/README.md)  

### vulnerable_cognito (Moyen)
`cloudgoat create vulnerable_cognito`

Dans ce scénario, vous êtes confronté à une page d'inscription et de connexion avec AWS Cognito en arrière-plan. Vous devez contourner les restrictions et exploiter les mauvaises configurations d'Amazon Cognito pour élever vos privilèges et obtenir les identifiants du pool d'identités Cognito.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/vulnerable_cognito/README.md)

Contribué par TrustOnCloud 

---
### vulnerable_lambda (Moyen)
`cloudgoat create vulnerable_lambda`

Dans ce scénario, vous démarrez en tant qu'utilisateur 'bilbo'. Vous assumerez un rôle avec plus de privilèges, découvrirez une fonction Lambda qui applique des politiques aux utilisateurs, et exploiterez une vulnérabilité dans la fonction pour escalader les privilèges de l'utilisateur bilbo afin de rechercher des secrets.  

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/vulnerable_lambda/README.md)

---

### cloud_breach_s3 (Moyen)
`cloudgoat create cloud_breach_s3`

En commençant en tant qu'observateur anonyme sans accès ni privilège, exploitez un serveur proxy inverse mal configuré pour interroger le service de métadonnées EC2 et acquérir les clés du profil d'instance. Ensuite, utilisez ces clés pour découvrir, accéder et exfiltrer des données sensibles depuis un bucket S3.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/cloud_breach_s3/README.md)

---

### iam_privesc_by_attachment (Moyen)
`cloudgoat create iam_privesc_by_attachment`

En commençant avec un ensemble très limité de permissions, l'attaquant peut tirer parti des permissions d'attachement de profil d'instance pour créer une nouvelle instance EC2 avec des privilèges nettement supérieurs aux siens. Avec l'accès à cette nouvelle instance EC2, l'attaquant obtient des pouvoirs d'administration complets dans le compte cible et peut accomplir l'objectif du scénario : supprimer le cg-super-critical-security-server et ouvrir la voie à d'autres actions malveillantes.

> **Note :** Ce scénario peut vous obliger à créer certaines ressources AWS, et comme CloudGoat ne peut gérer que les ressources qu'il crée, vous devez les supprimer manuellement avant d'exécuter `./cloudgoat destroy`.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_attachment/README.md)

---

### ec2_ssrf (Moyen)
`cloudgoat create ec2_ssrf`

En commençant en tant qu'utilisateur IAM Solus, l'attaquant découvre qu'il a des permissions ReadOnly sur une fonction Lambda, où des secrets codés en dur le mènent à une instance EC2 exécutant une application web vulnérable à une falsification de requête côté serveur (SSRF). Après avoir exploité l'application vulnérable et acquis des clés depuis le service de métadonnées EC2, l'attaquant accède à un bucket S3 privé contenant un jeu de clés qui lui permettent d'invoquer la fonction Lambda et de terminer le scénario.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ec2_ssrf/README.md)

---

### ecs_takeover (Moyen)
`cloudgoat create ecs_takeover`

En commençant avec un accès au site Web externe, l'attaquant doit trouver une vulnérabilité d'exécution de code à distance. En utilisant l'exécution de code à distance, l'attaquant peut accéder aux ressources disponibles dans le conteneur du site Web. En abusant de plusieurs mauvaises configurations ECS, l'attaquant accède à des permissions IAM qui lui permettent de forcer ECS à replanifier le conteneur cible sur une instance compromise.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_takeover/README.md)

---

### rds_snapshot (Moyen)
`cloudgoat create rds_snapshot`

Dans ce scénario, nous commençons avec l'utilisateur 'David'. Via David, vous pouvez exploiter des privilèges pour voler des identifiants. Avec les identifiants volés, un attaquant peut exploiter la vulnérabilité RDS pour accéder à la base de données et récupérer des indicateurs.

> **Note :** Ce scénario peut vous obliger à créer certaines ressources AWS, et comme CloudGoat ne peut gérer que les ressources qu'il crée, vous devez les supprimer manuellement avant d'exécuter `./cloudgoat destroy`. 

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/rds_snapshot/README.md)

---

### glue_privesc (Moyen)
`cloudgoat create glue_privesc`  

Ce scénario commence par une page Web qui télécharge un fichier CSV et effectue une visualisation de données via le service Glue. L'attaquant vole les identifiants présents sur la page Web via une injection SQL et télécharge un shell inversé pour créer un travail Glue afin d'obtenir la chaîne secrète.

> **Note :** Ce scénario peut vous obliger à créer certaines ressources AWS, et comme CloudGoat ne peut gérer que les ressources qu'il crée, vous devez les supprimer manuellement avant d'exécuter `./cloudgoat destroy`.  

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/glue_privesc/README.md)

---

### agentcore_identity_confusion (Moyen)
`cloudgoat create agentcore_identity_confusion`

Dans ce scénario, vous recevez des identifiants AWS qui peuvent gérer les interpréteurs de code agentcore de Bedrock. Votre tâche consiste à en tirer parti pour accéder à des données sensibles utilisées par d'autres agents d'exécution agentcore. Trouvez comment accéder à l'indicateur stocké dans une base de connaissances Bedrock.

> **Note :** Ce scénario peut vous obliger à créer certaines ressources AWS, et comme CloudGoat ne peut gérer que les ressources qu'il crée, vous devez les supprimer manuellement avant d'exécuter `./cloudgoat destroy`.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/agentcore_identity_confusion/README.md)

Contribué par Sonrai Security

---

### bedrock_agent_hijacking (Moyen)
`cloudgoat create bedrock_agent_hijacking`

Dans ce scénario, vous recevez des identifiants AWS qui peuvent invoquer un agent Bedrock et mettre à jour des fonctions Lambda. Votre tâche consiste à analyser l'agent et à comprendre comment il accède aux informations en temps réel. Interceptez ce flux pour localiser et extraire l'indicateur stocké dans S3.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/bedrock_agent_hijacking/README.md)

Contribué par Sonrai Security

</details>

<details>
  <summary><strong>Difficile</strong></summary>

### rce_web_app (Difficile)
`cloudgoat create rce_web_app`

En commençant en tant qu'utilisateur IAM Lara, l'attaquant explore un équilibreur de charge et un bucket S3 pour trouver des indices menant à des vulnérabilités, ce qui conduit à une exploitation d'exécution de code à distance sur une application Web vulnérable qui expose des fichiers confidentiels et culmine par l'accès à l'objectif du scénario : une instance de base de données RDS hautement sécurisée.

Alternativement, l'attaquant peut commencer en tant qu'utilisateur IAM McDuck et énumérer les buckets S3, menant finalement à des clés SSH qui donnent un accès direct au serveur EC2 et à la base de données au-delà.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/rce_web_app/README.md)

---

### codebuild_secrets (Difficile)
`cloudgoat create codebuild_secrets`

En commençant en tant qu'utilisateur IAM Solo, l'attaquant énumère et explore d'abord les projets CodeBuild, y trouvant des clés IAM non sécurisées pour l'utilisateur IAM Calrissian. Opérant ensuite en tant que Calrissian, l'attaquant découvre une base de données RDS. Incapable d'accéder directement au contenu de la base de données, l'attaquant peut faire un usage astucieux de la fonctionnalité de snapshot RDS pour acquérir l'objectif du scénario : une paire de chaînes secrètes.

Alternativement, l'attaquant peut explorer les paramètres SSM et trouver des clés SSH pour une instance EC2. En utilisant le service de métadonnées, l'attaquant peut acquérir les clés du profil d'instance EC2 et pousser plus loin dans l'environnement cible, accédant finalement à la base de données d'origine et à l'objectif du scénario à l'intérieur (une paire de chaînes secrètes) par un chemin plus détourné.

> **Note :** Ce scénario peut vous obliger à créer certaines ressources AWS, et comme CloudGoat ne peut gérer que les ressources qu'il crée, vous devez les supprimer manuellement avant d'exécuter `./cloudgoat destroy`.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/codebuild_secrets/README.md)

---

### detection_evasion (Difficile)
`cloudgoat create detection_evasion`

L'objectif de ce scénario est de lire les valeurs des deux secrets sans être détecté. Les secrets sont tous deux stockés dans Secrets Manager, et leurs valeurs ont le format suivant (cg-secret-XXXXXX-XXXXXX).

Ce scénario est significativement différent des autres scénarios CloudGoat. Dans detection_evasion, vos objectifs vous seront présentés plus clairement, et le défi consiste à les accomplir sans déclencher d'alarmes. Il y a plus de configuration impliquée dans ce scénario, et cela prendra plus de temps à jouer (vous voudrez/ devrez peut-être y jouer plusieurs fois).

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/detection_evasion/README.md)

---

### ecs_efs_attack (Difficile)
`cloudgoat create ecs_efs_attack`

En commençant avec un accès à l'EC2 "ruse", l'utilisateur exploite le profil d'instance pour backdoor le conteneur ECS en cours d'exécution. En utilisant le conteneur backdooré, l'attaquant peut récupérer des identifiants depuis l'API de métadonnées du conteneur. Ces identifiants permettent à l'attaquant de démarrer une session sur n'importe quelle EC2 avec les balises appropriées. L'attaquant utilise ses permissions pour changer les balises sur l'EC2 Admin et démarre une session. Une fois dans l'EC2 Admin, l'attaquant effectue un scan de ports sur le sous-réseau pour trouver un EFS ouvert à monter. Une fois monté, l'attaquant peut récupérer l'indicateur depuis le système de fichiers élastique.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_efs_attack/README.md)

---

### ecs_privesc_evade_protection (Moyen)
`cloudgoat create ecs_privesc_evade_protection`

Un utilisateur commence par accéder à un service Web fonctionnel vers un conteneur dans EC2. L'attaquant peut exploiter une vulnérabilité du service Web pour obtenir des identifiants depuis l'API de métadonnées dans EC2, ou pour contrôler le conteneur. Ces identifiants permettent à l'attaquant de lancer un nouveau conteneur avec un rôle spécifique et de le contrôler. Sur la base de cette action, effectuez une escalade de privilèges et lisez FLAG dans S3.

> **Note :** Ce scénario nécessite que Docker soit installé localement, car il construit et pousse une image de conteneur vers ECR lors du déploiement.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_privesc_evade_protection/README.md)

---

### secrets_in_the_cloud (Difficile)
`cloudgoat create secrets_in_the_cloud`

En tant qu'utilisateur IAM avec des privilèges limités, l'attaquant commence son voyage en examinant les ressources AWS pour découvrir des indices et des informations cachées. Cette enquête aboutit finalement à l'acquisition d'un rôle qui accorde l'accès à l'objectif principal du scénario : récupérer le dernier secret depuis Secrets Manager.

[Visiter la page du scénario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/secrets_in_the_cloud/README.md)
  
</details>



## Guide d'utilisation

La structure de base d'une commande CloudGoat est la suivante :

> `cloudgoat [ commande ] [ sous-commande ] [ --nom-argument ] [ valeur-argument ]`

Les cinq commandes principales de CloudGoat sont résumées ci-dessous :

### create

`create [ nom-scénario ]` déploie un scénario dans le compte AWS de votre choix. Vous pouvez également exécuter `create` sur un scénario existant si vous le souhaitez - CloudGoat détruira et recréera simplement le scénario nommé.

> **Astuce :** vous pouvez utiliser `/scenarios` dans le nom, ce qui permet la complétion native par tabulation de bash.

Notez que `--profile` est requis pour des raisons de sécurité - nous ne voulons pas que quelqu'un déploie accidentellement des scénarios CloudGoat dans un environnement de production - et CloudGoat n'utilisera pas les profils par défaut du système AWS CLI ni les profils spécifiés par défaut via des variables d'environnement. Vous pouvez toutefois définir cela via `config aws` pour éviter d'avoir à le fournir à chaque fois.

### list

`list` affiche des informations sur les scénarios `all`, `undeployed` ou `deployed`, ou même beaucoup d'informations sur un `[ nom-scénario ]` déjà déployé. Vous pouvez également filtrer les scénarios par plateforme cloud : `list aws` ou `list azure`.

### destroy

`destroy` arrête et supprime les ressources cloud d'un `[ nom-scénario ]`, puis déplace le dossier d'instance du scénario vers `./trash` - juste au cas où vous auriez besoin de récupérer le fichier d'état Terraform ou d'autres fichiers du scénario. Vous pouvez également spécifier `all` au lieu d'un nom de scénario pour détruire tous les scénarios actifs.

> **Astuce :** CloudGoat ne peut gérer que les ressources qu'il crée. Si vous créez vous-même des ressources au cours d'un scénario, vous devez les supprimer manuellement avant d'exécuter la commande `destroy`.

### config

`config` vous permet de gérer divers aspects de votre installation CloudGoat, notamment la `whitelist` d'IP, votre AWS `profile` par défaut et la complétion par tabulation via `argcomplete`. Il vaut la peine de décrire brièvement ce que fait chacune de ces sous-commandes.

#### whitelist

CloudGoat a besoin de savoir quelles adresses IP doivent être autorisées lorsque des ressources potentiellement vulnérables sont déployées dans le cloud, et ces IP sont suivies dans un fichier `./whitelist.txt` dans le répertoire de base du projet. L'adresse IP que vous fournissez pour l'autorisation ne doit pas nécessairement être au format CIDR, mais CloudGoat ajoutera un `/32` à toutes les IP nues que vous fournissez. Optionnellement, vous pouvez ajouter l'argument `--auto`, et CloudGoat effectuera automatiquement une requête réseau, en utilisant curl vers ifconfig.co pour trouver votre adresse IP, puis créera le fichier d'autorisation avec le résultat.

#### aws

Bien que CloudGoat n'utilise jamais les profils par défaut du système AWS CLI ni les profils spécifiés par défaut via des variables d'environnement, vous pouvez demander à CloudGoat d'utiliser un profil AWS particulier par son nom en utilisant la commande `config aws`. Cela vous demandera et enregistrera le nom de votre profil dans un fichier `config.yml` dans le répertoire de base du projet. Tant que ce fichier est présent, CloudGoat utilisera le nom de profil indiqué pour les commandes create et destroy, au lieu d'exiger le drapeau `--profile`. Vous pouvez exécuter la commande `config aws` à tout moment pour voir le nom de votre profil par défaut CloudGoat et valider le format du `config.yml`. Vous pouvez également créer `config.yml` manuellement, si vous le souhaitez, à condition d'utiliser le format correct.

#### azure

Les versions plus récentes du fournisseur Azure pour Terraform nécessitent l'ID d'abonnement pour appliquer des ressources. Bien que CloudGoat utilise la même configuration d'identifiants que l'utilitaire `az`, CloudGoat doit être informé explicitement de l'abonnement à utiliser pour le déploiement. La configuration se fait avec `cloudgoat config azure`, et l'abonnement est stocké dans `config.yml` avec la configuration aws. Vous pouvez également créer `config.yml` manuellement, si vous le souhaitez, à condition d'utiliser le format correct.

#### argcomplete

Nous voulions vraiment avoir une complétion native par tabulation dans CloudGoat, mais il s'est avéré que c'était assez difficile à réaliser en dehors d'un REPL. Cela devrait fonctionner raisonnablement bien pour les utilisateurs Linux, et pour les utilisateurs OSX assez courageux pour trouver un moyen de mettre à niveau leur version de bash vers 4.2+. CloudGoat inclut et prend en charge [la bibliothèque python "argcomplete"](https://github.com/kislyuk/argcomplete). Un bref résumé de la façon d'installer argcomplete est fourni ci-dessous, bien que pour des étapes plus détaillées, vous devriez vous référer à la documentation officielle sur la [page github](https://github.com/kislyuk/argcomplete) de la bibliothèque.

1. Installez le package Python argcomplete en utilisant le fichier requirements.txt de CloudGoat : `$ pip3 install -r core/python/requirements.txt`
2. Dans bash, exécutez le script de complétion globale des arguments Python fourni par le package argcomplete : `$ activate-global-python-argcomplete`
3. Sourcez le script de complétion à l'emplacement imprimé par la commande d'activation précédente, ou redémarrez votre session shell : `$ source [ /chemin/vers/le/script/de/completion ]`

Pour ceux qui ne peuvent pas ou ne souhaitent pas configurer argcomplete, CloudGoat prend également en charge l'utilisation de chemins de répertoire comme noms de scénarios, ce qui signifie que la complétion par tabulation fonctionnera pour les noms de scénarios. Utilisez simplement `/scenario/[ nom-scénario ]` ou `./[ nom-instance-scénario ]` et votre shell devrait faire le reste.

### help

`help` fournit une aide contextuelle sur les commandes. `help` peut venir avant ou après la commande en question, il est donc toujours là quand vous en avez besoin. Voici quelques exemples :* `cloudgoat create help`
* `cloudgoat destroy help`
* `cloudgoat list help`
* `cloudgoat config help`

Une autre utilisation notable : `cloudgoat [ scenario-name ] help` peut être utilisé pour afficher dans la console un bref résumé du scénario, tel que défini par son auteur.

## Demandes de fonctionnalités et signalements de bugs

Si vous avez une demande de fonctionnalité ou un bug à signaler, veuillez [les soumettre ici](https://github.com/RhinoSecurityLabs/cloudgoat/issues/new).

Pour les bugs, veillez à inclure une description suffisante pour reproduire le bug que vous avez trouvé, y compris les traces d'exécution et les étapes de reproduction, et vérifiez qu'aucun autre rapport de votre bug n'a déjà été soumis avant d'en déposer un nouveau.

Pour les fonctionnalités, le même principe s'applique ! Soyez précis dans votre demande et assurez-vous que personne d'autre n'a déjà demandé la même fonctionnalité.

## Directives de contribution

Les contributions à CloudGoat sont grandement appréciées. Si vous souhaitez contribuer à l'amélioration du projet, lisez ce qui suit.

1. **Création d'un nouveau scénario** :
   - Nous avons fourni un modèle de scénario pour vous aider à démarrer rapidement. Le modèle comprend la structure de base et les fichiers nécessaires pour un scénario CloudGoat. Vous trouverez le modèle de scénario [ici](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/scenarios/scenario_template).
   - **Étapes pour créer un nouveau scénario** :
     - **Copier le modèle** : Copiez le contenu du modèle de scénario dans un nouveau répertoire portant le nom de votre scénario.
     - **Modifier le modèle** : Remplacez le contenu factice du modèle par les spécificités de votre nouveau scénario.
     - **Tester le scénario** : Assurez-vous que votre scénario fonctionne comme prévu en le testant minutieusement.
2. **Normes de codage** :
   - **Style de code** : Suivez le style de code existant dans le projet. La cohérence est primordiale.
   - **Commentaires** : Ajoutez des commentaires à votre code si nécessaire pour expliquer une logique complexe ou des décisions importantes.
   - **Documentation** : Mettez à jour le fichier README.md et toute autre documentation pertinente pour inclure les détails de votre nouveau scénario ou des modifications.
3. **Liste blanche** :
   - Lors de la création ou de la modification de scénarios, gardez à l'esprit ce qui suit :
     - **Liste blanche** : Assurez-vous que les règles de groupe de sécurité et les autres contrôles d'accès sont configurés pour mettre sur liste blanche uniquement l'IP de la configuration CloudGoat.
     - **Vérification** : Vérifiez à nouveau vos configurations pour détecter toute ressource publique potentiellement vulnérable avant de contribuer (c'est-à-dire, ne créez pas d'EC2 vulnérables accessibles depuis Internet).
4. **Style de code Python** :
   - Le code Python dans CloudGoat doit généralement suivre les conventions de style de Python, en privilégiant la lisibilité et la maintenabilité avant tout.
   - Suivez les bonnes pratiques Git : utilisez les pull requests, préférez les branches de fonctionnalités, rédigez toujours des messages de commit clairs.
   - CloudGoat utilise `black` et `flake8` - des linters de syntaxe et de style Python. Assurez-vous que `flake8` et `black` sont exécutés sur tous les fichiers Python dans `core/python/` et sur `cloudgoat.py` avant de valider le code. Les décisions de `black` priment sur celles de `flake8`. Ces deux outils sont commentés dans le fichier `core/python/requirements.txt` car les utilisateurs normaux n'en ont pas besoin.
5. **Licence** :
   - Le code de CloudGoat doit toujours utiliser la licence BSD 3 clauses.

Et enfin, merci pour votre contribution !

## Journal des modifications

- **24/06/19 :** CloudGoat 2.0 est sorti !

## Avertissement

CloudGoat est un logiciel qui ne comporte absolument aucune garantie. En utilisant CloudGoat, vous assumez l'entière responsabilité de tous les résultats qui en découlent.