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

Sie möchten vielleicht auch einige schnelle Konfigurationsbefehle ausführen - das spart Ihnen später etwas Zeit:

Konfigurieren Sie für AWS - teilen Sie CloudGoat mit, welches AWS-Profil verwendet werden soll.```bash
cloudgoat config aws

Bei Azure anmelden - CloudGoat verwendet das aktive `az`-Konto.```bash
az login

Jetzt kann CloudGoat auf Ihren Befehl hin eine Instanz eines Szenarios in der Cloud `create`. Wenn die Umgebung bereit ist, wird ein neuer Ordner im Projekt-Basisverzeichnis erstellt, der nach dem Szenario benannt ist und mit einer eindeutigen Szenario-ID versehen wird. In diesem Ordner befindet sich eine Datei namens `start.txt`, die alle Ressourcen enthält, die Sie zum Starten des Szenarios benötigen. Diese werden auch auf Ihrer Konsole ausgegeben, wenn der Befehl `create` abgeschlossen ist. Manchmal wird auch ein SSH-Schlüsselpaar namens `cloudgoat`/`cloudgoat.pub` erstellt.

> **Hinweis:** Löschen oder ändern Sie nicht den Szenario-Instanzordner oder die darin enthaltenen Dateien, da dies CloudGoat daran hindern könnte, die Ressourcen Ihres Szenarios zu verwalten.

Während Sie das Szenario durcharbeiten, können Sie bei Bedarf gerne die Readme des Szenarios zu Rate ziehen. Wenn Sie nicht weiterkommen, finden Sie am Ende jeder Routenbeschreibung verlinkte Spickzettel.

Wenn Sie mit dem Szenario fertig sind, löschen Sie alle selbst erstellten Ressourcen (denken Sie daran: CloudGoat kann nur die von ihm erstellten Ressourcen verwalten) und führen Sie dann den Befehl `destroy` aus. Es ist immer eine gute Idee, anschließend einen kurzen Blick auf Ihre Webkonsole zu werfen – für den Fall, dass etwas nicht gelöscht wurde.

Die vollständige Dokumentation der CloudGoat-Befehle finden Sie [hier im Abschnitt „Verwendungshandbuch“](#usage-guide).

## So verwenden Sie das Docker-Image von 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: Mit Standard-Einstiegspunkt ausführen```console
docker run -it rhinosecuritylabs/cloudgoat:latest

## Verfügbare Szenarien
(nach Schwierigkeitsgrad gruppiert)

<details open>
  <summary><strong>Einfach</strong></summary>

---

### iam_enum_basics (Einfach)
`cloudgoat create iam_enum_basics`

In diesem Szenario startest du mit den Zugriffsschlüsseln eines IAM-Benutzers niedriger Berechtigungsstufe namens Bob. Deine Aufgabe ist es, eine gründliche IAM-Enumeration mit der AWS CLI durchzuführen. Durch die Untersuchung von verwalteten Richtlinien, Inline-Richtlinien, Gruppenmitgliedschaften und annehmbaren Rollen findest du fünf verschiedene Flags.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_enum_basics/README.md)  

Beigetragen von Tyler Ramsbey

---

### data_secrets (Einfach)
`cloudgoat create data_secrets`

In diesem Szenario startest du mit einem IAM-Benutzer mit eingeschränkten Berechtigungen. Deine Aufgabe ist es, eine falsch konfigurierte EC2-Instanz zu identifizieren, die Anmeldeinformationen in ihren User-Daten preisgibt, sodass du SSH-Zugriff erhältst. Von dort aus musst du pivotieren, indem du den Instance Metadata Service (IMDS) ausnutzt, um eine Rolle zu stehlen, Lambda-Funktionen enumerierst, um versteckte Umgebungsvariablen zu finden, und schließlich einen Benutzer kompromittierst, der Zugriff auf das Ziel des Szenarios hat: ein in AWS Secrets Manager gespeichertes Geheimnis.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/data_secrets/README.md)  

Beigetragen von Tyler Ramsbey

---

### beanstalk_secrets (Einfach)
`cloudgoat create beanstalk_secrets`

In diesem Szenario erhältst du AWS-Anmeldeinformationen mit niedrigen Berechtigungen, die eingeschränkten Zugriff auf Elastic Beanstalk gewähren. Deine Aufgabe ist es, die Elastic-Beanstalk-Umgebung zu enumerieren und falsch konfigurierte Umgebungsvariablen zu entdecken, die sekundäre Anmeldeinformationen enthalten. Mit diesen sekundären Anmeldeinformationen kannst du IAM-Berechtigungen enumerieren, um schließlich einen Zugriffsschlüssel für einen Administratorbenutzer zu erstellen. Mit diesen Admin-Rechten rufst du das endgültige Flag aus AWS Secrets Manager ab.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/beanstalk_secrets/README.md)  

Beigetragen von Tyler Ramsbey

---

### sns_secrets (Einfach)
`cloudgoat create sns_secrets`

In diesem Szenario startest du mit grundlegendem Zugriff auf ein AWS-Konto. Du musst deine Berechtigungen enumerieren, ein SNS-Thema entdecken, das du abonnieren kannst, einen durchgesickerten API-Schlüssel abrufen und schließlich den API-Schlüssel verwenden, um über ein API-Gateway auf das endgültige Flag zuzugreifen.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/sns_secrets/README.md)  

Beigetragen von Tyler Ramsbey

---

### iam_privesc_by_key_rotation (Einfach)
`cloudgoat create iam_privesc_by_key_rotation`

Nutze unsichere IAM-Berechtigungen aus, um deinen Zugriff zu eskalieren. Starte mit einer Rolle, die die Anmeldeinformationen anderer Benutzer verwaltet, und finde eine Schwachstelle im Setup, um auf die „Admin“-Rolle zuzugreifen. Verwende die Admin-Rolle, um das Flag aus Secrets Manager abzurufen.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_key_rotation/README.md)

Beigetragen von Infrasec.sh

---

### iam_privesc_by_rollback (Einfach)
`cloudgoat create iam_privesc_by_rollback`

Ausgehend von einem stark eingeschränkten IAM-Benutzer kann der Angreifer frühere IAM-Richtlinienversionen überprüfen und eine wiederherstellen, die volle Administratorrechte gewährt, was zu einem Privilegieneskalations-Exploit führt.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_rollback/README.md)

---

### lambda_privesc (Einfach)
`cloudgoat create lambda_privesc`

Ausgehend vom IAM-Benutzer Chris entdeckt der Angreifer, dass er eine Rolle annehmen kann, die vollen Lambda-Zugriff und „Pass Role“-Berechtigungen hat. Der Angreifer kann dann eine Privilegieneskalation mit diesen neuen Berechtigungen durchführen, um volle Administratorrechte zu erhalten.

> **Hinweis:** Dieses Szenario erfordert möglicherweise die Erstellung einiger AWS-Ressourcen, und da CloudGoat nur die von ihm erstellten Ressourcen verwalten kann, solltest du diese manuell entfernen, bevor du `./cloudgoat destroy` ausführst.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/lambda_privesc/README.md)

---

### sqs_flag_shop (Einfach)
`cloudgoat create sqs_flag_shop`

Starte zunächst mit der SHOP-Seite, auf der du FLAG kaufen kannst. Die Website hat mehrere Seiten, und du siehst, dass der Quellcode offengelegt ist. Angreifer analysieren den Code, um Schwachstellen zu finden, und nutzen ihre Berechtigungen aus, um FLAG zu erwerben.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/sqs_flag_shop/README.md)

</details>

<details>
  <summary><strong>Mittel</strong></summary>

### static (Mittel)
`cloudgoat create static`

In diesem Szenario agierst du als externer Angreifer, der ein Unternehmensportal besucht. Durch die Analyse der Webanwendung stellst du fest, dass sie kritische JavaScript-Bibliotheken aus einem öffentlichen S3-Bucket lädt. Du musst eine Fehlkonfiguration in den Berechtigungen des Buckets entdecken, einen „Supply Chain Attack“ durchführen, indem du die Bibliothek mit bösartigem Code überschreibst, und darauf warten, dass sich ein interner Administrator-Bot anmeldet. Dein Ziel ist es, die Anmeldeinformationen des Bots zu erfassen und zurück in den Bucket zu exfiltrieren.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/static/README.md)

### vulnerable_cognito (Mittel)
`cloudgoat create vulnerable_cognito`

In diesem Szenario wird dir eine Anmelde- und Registrierungsseite mit AWS Cognito im Backend präsentiert. Du musst Einschränkungen umgehen und Fehlkonfigurationen in Amazon Cognito ausnutzen, um deine Berechtigungen zu erhöhen und Anmeldeinformationen für den Cognito Identity Pool zu erhalten.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/vulnerable_cognito/README.md)

Beigetragen von TrustOnCloud

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

In diesem Szenario startest du als Benutzer 'bilbo'. Du wirst eine Rolle mit mehr Berechtigungen annehmen, eine Lambda-Funktion entdecken, die Richtlinien auf Benutzer anwendet, und eine Schwachstelle in der Funktion ausnutzen, um die Berechtigungen des Benutzers bilbo zu eskalieren, um nach Geheimnissen zu suchen.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/vulnerable_lambda/README.md)

---

### cloud_breach_s3 (Mittel)
`cloudgoat create cloud_breach_s3`

Als anonymer Außenstehender ohne Zugriff oder Berechtigungen nutzt du einen falsch konfigurierten Reverse-Proxy-Server aus, um den EC2-Metadatendienst abzufragen und Instanzprofil-Schlüssel zu erhalten. Verwende dann diese Schlüssel, um einen S3-Bucket zu entdecken, darauf zuzugreifen und vertrauliche Daten zu exfiltrieren.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/cloud_breach_s3/README.md)

---

### iam_privesc_by_attachment (Mittel)
`cloudgoat create iam_privesc_by_attachment`

Ausgehend von einem sehr eingeschränkten Satz von Berechtigungen kann der Angreifer die Berechtigungen zur Instanzprofil-Anhängung nutzen, um eine neue EC2-Instanz mit deutlich höheren Berechtigungen als seinen eigenen zu erstellen. Mit Zugriff auf diese neue EC2-Instanz erlangt der Angreifer volle administrative Befugnisse innerhalb des Zielkontos und kann das Ziel des Szenarios erreichen – das Löschen des cg-super-critical-security-server und den Weg für weitere bösartige Aktionen ebnen.

> **Hinweis:** Dieses Szenario erfordert möglicherweise die Erstellung einiger AWS-Ressourcen, und da CloudGoat nur die von ihm erstellten Ressourcen verwalten kann, solltest du diese manuell entfernen, bevor du `./cloudgoat destroy` ausführst.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_attachment/README.md)

---

### ec2_ssrf (Mittel)
`cloudgoat create ec2_ssrf`

Ausgehend vom IAM-Benutzer Solus entdeckt der Angreifer, dass er ReadOnly-Berechtigungen für eine Lambda-Funktion hat, wo hartcodierte Geheimnisse ihn zu einer EC2-Instanz führen, auf der eine Webanwendung läuft, die anfällig für Server-Side Request Forgery (SSRF) ist. Nachdem er die anfällige App ausgenutzt und Schlüssel aus dem EC2-Metadatendienst erworben hat, erhält der Angreifer Zugriff auf einen privaten S3-Bucket mit einem Satz von Schlüsseln, die es ihm ermöglichen, die Lambda-Funktion aufzurufen und das Szenario abzuschließen.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ec2_ssrf/README.md)

---

### ecs_takeover (Mittel)
`cloudgoat create ecs_takeover`

Ausgehend vom Zugriff auf die externe Website muss der Angreifer eine Remote Code Execution (RCE)-Schwachstelle finden. Durch die Nutzung von RCE kann der Angreifer auf Ressourcen zugreifen, die dem Website-Container zur Verfügung stehen. Durch die Ausnutzung mehrerer ECS-Fehlkonfigurationen erlangt der Angreifer IAM-Berechtigungen, die es ihm erlauben, ECS zu zwingen, den Zielcontainer auf eine kompromittierte Instanz neu zu planen.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_takeover/README.md)

---

### rds_snapshot (Mittel)
`cloudgoat create rds_snapshot`

In diesem Szenario starten wir mit dem Benutzer 'David'. Durch David kannst du Berechtigungen nutzen, um Anmeldeinformationen zu stehlen. Mit den gestohlenen Anmeldeinformationen kann ein Angreifer die RDS-Schwachstelle ausnutzen, um auf die Datenbank zuzugreifen und Flags abzurufen.

> **Hinweis:** Dieses Szenario erfordert möglicherweise die Erstellung einiger AWS-Ressourcen, und da CloudGoat nur die von ihm erstellten Ressourcen verwalten kann, solltest du diese manuell entfernen, bevor du `./cloudgoat destroy` ausführst.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/rds_snapshot/README.md)

---

### glue_privesc (Mittel)
`cloudgoat create glue_privesc`

Dieses Szenario beginnt mit einer Webseite, die eine CSV-Datei hochlädt und Datenvisualisierung über den Glue-Dienst durchführt. Der Angreifer stiehlt die auf der Webseite vorhandenen Anmeldeinformationen durch einen SQL-Injection-Angriff und lädt eine Reverse-Shell hoch, um einen Glue-Job zu erstellen und die geheime Zeichenfolge zu erhalten.

> **Hinweis:** Dieses Szenario erfordert möglicherweise die Erstellung einiger AWS-Ressourcen, und da CloudGoat nur die von ihm erstellten Ressourcen verwalten kann, solltest du diese manuell entfernen, bevor du `./cloudgoat destroy` ausführst.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/glue_privesc/README.md)

---

### agentcore_identity_confusion (Mittel)
`cloudgoat create agentcore_identity_confusion`

In diesem Szenario erhältst du AWS-Anmeldeinformationen, mit denen du Bedrock AgentCore-Code-Interpreter verwalten kannst. Deine Aufgabe ist es, dies zu nutzen, um Zugriff auf vertrauliche Daten zu erhalten, die von anderen AgentCore-Laufzeitagenten verwendet werden. Finde heraus, wie du Zugriff auf das in einer Bedrock-Wissensdatenbank gespeicherte Flag erhältst.

> **Hinweis:** Dieses Szenario erfordert möglicherweise die Erstellung einiger AWS-Ressourcen, und da CloudGoat nur die von ihm erstellten Ressourcen verwalten kann, solltest du diese manuell entfernen, bevor du `./cloudgoat destroy` ausführst.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/agentcore_identity_confusion/README.md)

Beigetragen von Sonrai Security

---

### bedrock_agent_hijacking (Mittel)
`cloudgoat create bedrock_agent_hijacking`

In diesem Szenario erhältst du AWS-Anmeldeinformationen, mit denen du einen Bedrock-Agent aufrufen und Lambda-Funktionen aktualisieren kannst. Deine Aufgabe ist es, den Agenten zu analysieren und zu verstehen, wie er auf Echtzeitinformationen zugreift. Nutze diesen Fluss aus, um das in S3 gespeicherte Flag zu lokalisieren und zu extrahieren.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/bedrock_agent_hijacking/README.md)

Beigetragen von Sonrai Security

</details>

<details>
  <summary><strong>Schwer</strong></summary>

### rce_web_app (Schwer)
`cloudgoat create rce_web_app`

Ausgehend vom IAM-Benutzer Lara erkundet der Angreifer einen Load Balancer und einen S3-Bucket auf Hinweise auf Schwachstellen, was zu einem RCE-Exploit auf einer anfälligen Web-App führt, der vertrauliche Dateien offenlegt und schließlich Zugriff auf das Ziel des Szenarios ermöglicht: eine hochgesicherte RDS-Datenbankinstanz.

Alternativ kann der Angreifer als IAM-Benutzer McDuck starten und S3-Buckets enumerieren, was schließlich zu SSH-Schlüsseln führt, die direkten Zugriff auf den EC2-Server und die dahinter liegende Datenbank gewähren.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/rce_web_app/README.md)

---

### codebuild_secrets (Schwer)
`cloudgoat create codebuild_secrets`

Ausgehend vom IAM-Benutzer Solo enumeriert und erkundet der Angreifer zunächst CodeBuild-Projekte und findet darin ungesicherte IAM-Schlüssel für den IAM-Benutzer Calrissian. Als Calrissian entdeckt der Angreifer dann eine RDS-Datenbank. Da er nicht direkt auf den Inhalt der Datenbank zugreifen kann, kann der Angreifer die RDS-Snapshot-Funktionalität geschickt nutzen, um das Ziel des Szenarios zu erlangen: ein Paar geheimer Zeichenfolgen.

Alternativ kann der Angreifer SSM-Parameter erkunden und SSH-Schlüssel zu einer EC2-Instanz finden. Über den Metadatendienst kann der Angreifer die Schlüssel des EC2-Instanzprofils erwerben und tiefer in die Zielumgebung vordringen, um schließlich auf dem Umweg über eine längere Route Zugriff auf die ursprüngliche Datenbank und das Szenarioziel (ein Paar geheimer Zeichenfolgen) zu erhalten.

> **Hinweis:** Dieses Szenario erfordert möglicherweise die Erstellung einiger AWS-Ressourcen, und da CloudGoat nur die von ihm erstellten Ressourcen verwalten kann, solltest du diese manuell entfernen, bevor du `./cloudgoat destroy` ausführst.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/codebuild_secrets/README.md)

---

### detection_evasion (Schwer)
`cloudgoat create detection_evasion`

Das Ziel dieses Szenarios ist es, die Werte beider Geheimnisse auszulesen, ohne entdeckt zu werden. Die Geheimnisse sind beide in Secrets Manager gespeichert, und ihre Werte haben das folgende Format (cg-secret-XXXXXX-XXXXXX).

Dieses Szenario unterscheidet sich deutlich von anderen CloudGoat-Szenarien. Bei detection_evasion werden dir deine Ziele klarer vorgegeben, und die Herausforderung besteht darin, sie zu erfüllen, ohne Alarme auszulösen. Dieses Szenario erfordert mehr Einrichtung und dauert länger (du wirst es vielleicht mehrmals spielen wollen oder müssen).

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/detection_evasion/README.md)

---

### ecs_efs_attack (Schwer)
`cloudgoat create ecs_efs_attack`

Ausgehend vom Zugriff auf die "ruse" EC2 nutzt der Benutzer das Instanzprofil, um den laufenden ECS-Container zu hinterlassen. Mit dem hinterlegten Container kann der Angreifer Anmeldeinformationen von der Container-Metadaten-API abrufen. Diese Anmeldeinformationen erlauben es dem Angreifer, eine Sitzung auf jeder EC2 mit den entsprechenden Tags zu starten. Der Angreifer nutzt seine Berechtigungen, um die Tags auf der Admin-EC2 zu ändern und startet eine Sitzung. Sobald er in der Admin-EC2 ist, führt der Angreifer einen Port-Scan im Subnetz nach einem offenen EFS durch, um es zu mounten. Nach dem Mounten kann der Angreifer das Flag aus dem Elastic File System abrufen.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_efs_attack/README.md)

---

### ecs_privesc_evade_protection (Mittel)
`cloudgoat create ecs_privesc_evade_protection`

Ein Benutzer beginnt mit dem Zugriff auf einen funktionierenden Webdienst eines Containers in EC2. Der Angreifer kann eine Schwachstelle im Webdienst ausnutzen, um Anmeldeinformationen von der Metadaten-API in EC2 zu erhalten oder den Container zu kontrollieren. Diese Anmeldeinformationen erlauben es dem Angreifer, einen neuen Container mit einer bestimmten Rolle zu initiieren und zu kontrollieren. Auf der Grundlage dieser Aktion führt er eine Privilegieneskalation durch und liest FLAG in S3 aus.

> **Hinweis:** Dieses Szenario erfordert, dass Docker lokal installiert ist, da während der Bereitstellung ein Container-Image erstellt und zu ECR gepusht wird.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_privesc_evade_protection/README.md)

---

### secrets_in_the_cloud (Schwer)
`cloudgoat create secrets_in_the_cloud`

Als IAM-Benutzer mit eingeschränkten Berechtigungen beginnt der Angreifer seine Reise, indem er AWS-Ressourcen untersucht, um Hinweise und versteckte Informationen zu finden. Diese Untersuchung führt schließlich zum Erwerb einer Rolle, die Zugriff auf das Hauptziel des Szenarios gewährt: das endgültige Geheimnis aus Secrets Manager abzurufen.

[Zur Szenarioseite.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/secrets_in_the_cloud/README.md)

</details>

## Bedienungsanleitung

Der grundlegende Aufbau eines CloudGoat-Befehls ist wie folgt:

> `cloudgoat [ Befehl ] [ Unterbefehl ] [ --arg-Name ] [ arg-Wert ]`

Die fünf Hauptbefehle in CloudGoat werden unten zusammengefasst:

### create

`create [ Szenario-Name ]` stellt ein Szenario in dem von dir gewählten AWS-Konto bereit. Du kannst `create` auch für ein bestehendes Szenario ausführen, wenn du möchtest – CloudGoat zerstört und erstellt das benannte Szenario dann einfach neu.

> **Tipp:** Du kannst `/scenarios` im Namen verwenden, was die native Tab-Vervollständigung von Bash ermöglicht.

Beachte, dass `--profile` aus Sicherheitsgründen erforderlich ist – wir möchten nicht, dass jemand versehentlich CloudGoat-Szenarien in einer Produktionsumgebung bereitstellt – und CloudGoat nicht die „default“-AWS-CLI-Profile des Systems oder über Umgebungsvariablen als Standard angegebene Profile verwendet. Du kannst dies jedoch über `config aws` einstellen, um es nicht jedes Mal angeben zu müssen.

### list

`list` zeigt einige Informationen über `all` (alle), `undeployed` (nicht bereitgestellte) oder `deployed` (bereitgestellte) Szenarien oder sogar viele Informationen über ein bereits bereitgestelltes `[ Szenario-Name ]` an. Du kannst Szenarien auch nach Cloud-Plattform filtern: `list aws` oder `list azure`.

### destroy

`destroy` schaltet die Cloud-Ressourcen eines `[ Szenario-Name ]` ab und löscht sie und verschiebt dann den Szenario-Instanzordner nach `./trash` – nur für den Fall, dass du die Terraform-Statusdatei oder andere Szenariodateien wiederherstellen musst. Du kannst auch `all` anstelle eines Szenarionamens angeben, um alle aktiven Szenarien zu zerstören.

> **Tipp:** CloudGoat kann nur Ressourcen verwalten, die es erstellt. Wenn du im Laufe eines Szenarios selbst Ressourcen erstellst, solltest du diese manuell entfernen, bevor du den `destroy`-Befehl ausführst.

### config

`config` ermöglicht es dir, verschiedene Aspekte deiner CloudGoat-Installation zu verwalten, insbesondere die IP-`whitelist` (Zulassungsliste), dein standardmäßiges AWS `profile` und die Tab-Vervollständigung über `argcomplete`. Es lohnt sich, kurz zu beschreiben, was jeder dieser Unterbefehle tut.

#### whitelist

CloudGoat muss wissen, welche IP-Adressen bei der Bereitstellung potenziell anfälliger Ressourcen in der Cloud zugelassen werden sollen, und diese IPs werden in einer Datei `./whitelist.txt` im Basisprojektverzeichnis verfolgt. Die von dir für die Zulassungsliste angegebene IP-Adresse muss _nicht_ im CIDR-Format sein, aber CloudGoat fügt allen nackten IPs, die du angibst, ein `/32` hinzu. Optional kannst du das Argument `--auto` hinzufügen, und CloudGoat führt automatisch eine Netzwerkanfrage mit curl an ifconfig.co durch, um deine IP-Adresse zu ermitteln, und erstellt dann die Zulassungsliste mit dem Ergebnis.

#### aws

CloudGoat wird zwar niemals die „default“-AWS-CLI-Profile des Systems oder über Umgebungsvariablen als Standard angegebene Profile verwenden, du kannst CloudGoat jedoch anweisen, ein bestimmtes AWS-Profil namentlich mit dem Befehl `config aws` zu verwenden. Dies fragt nach und speichert den Namen deines Profils in einer Datei `config.yml` im Basisprojektverzeichnis. Solange diese Datei vorhanden ist, verwendet CloudGoat den darin aufgeführten Profilnamen für Create- und Destroy-Befehle, anstatt das Flag `--profile` zu erfordern. Du kannst den Befehl `config aws` jederzeit ausführen, um den Namen deines CloudGoat-Standardprofils anzuzeigen und das Format der `config.yml` zu überprüfen. Du kannst `config.yml` auch manuell erstellen, wenn du möchtest, vorausgesetzt du verwendest das korrekte Format.

#### azure

Neuere Versionen des Azure-Anbieters für Terraform erfordern die Abonnement-ID, um Ressourcen anzuwenden. CloudGoat verwendet zwar dieselbe Anmeldeinformationskonfiguration wie das `az`-Tool, aber CloudGoat muss explizit mitgeteilt werden, in welches Abonnement bereitgestellt werden soll. Die Konfiguration erfolgt mit `cloudgoat config azure`, und das Abonnement wird in `config.yml` neben der AWS-Konfiguration gespeichert. Du kannst `config.yml` auch manuell erstellen, wenn du möchtest, vorausgesetzt du verwendest das korrekte Format.

#### argcomplete

Wir wollten unbedingt native Tab-Vervollständigung in CloudGoat haben, aber wie sich herausstellte, war das außerhalb einer REPL etwas schwierig umzusetzen. Es sollte für Linux-Benutzer einigermaßen gut funktionieren und für diejenigen OSX-Benutzer, die mutig genug sind, einen Weg zu finden, ihre Bash-Version auf 4.2+ zu aktualisieren. CloudGoat enthält und unterstützt [die Python-Bibliothek „argcomplete“](https://github.com/kislyuk/argcomplete). Eine kurze Zusammenfassung zur Installation von argcomplete findest du unten; für detailliertere Schritte solltest du die offizielle Dokumentation auf der [GitHub-Seite](https://github.com/kislyuk/argcomplete) der Bibliothek konsultieren.

1. Installiere das Python-Paket argcomplete mit der Datei `requirements.txt` von CloudGoat: `$ pip3 install -r core/python/requirements.txt`
2. Führe in Bash das globale Python-Argumentvervollständigungsskript aus, das vom argcomplete-Paket bereitgestellt wird: `$ activate-global-python-argcomplete`
3. Führe das Vervollständigungsskript an dem Ort aus, der beim vorherigen Aktivierungsbefehl ausgegeben wurde, oder starte deine Shell-Sitzung neu: `$ source [ /pfad/zum/vervollständigungsskript ]`

Für diejenigen, die argcomplete nicht konfigurieren können oder möchten, unterstützt CloudGoat auch die Verwendung von Verzeichnispfaden als Szenarionamen, was bedeutet, dass die Tab-Vervollständigung für Szenarionamen funktioniert. Verwende einfach `/scenario/[ Szenario-Name ]` oder `./[ Szenario-Instanzname ]`, und deine Shell sollte den Rest erledigen.

### help

`help` bietet kontextbezogene Hilfe zu Befehlen. `help` kann vor oder nach dem betreffenden Befehl stehen, sodass es immer da ist, wenn du es brauchst. Nachfolgend einige Beispiele:* `cloudgoat create help`
* `cloudgoat destroy help`
* `cloudgoat list help`
* `cloudgoat config help`

Eine weitere erwähnenswerte Verwendung: `cloudgoat [ Szenario-Name ] help` gibt eine kurze Zusammenfassung des Szenarios auf der Konsole aus, wie vom Autor des Szenarios definiert.

## Funktionsanfragen und Fehlermeldungen

Wenn Sie eine Funktionsanfrage oder einen Fehler melden möchten, [reichen Sie diese bitte hier ein](https://github.com/RhinoSecurityLabs/cloudgoat/issues/new).

Bei Fehlern geben Sie bitte eine ausreichende Beschreibung an, um den gefundenen Fehler zu reproduzieren, einschließlich Tracebacks und Reproduktionsschritten. Überprüfen Sie auch, ob Ihr Fehler bereits von jemand anderem gemeldet wurde.

Für Funktionsanfragen gilt Ähnliches: Seien Sie spezifisch in Ihrer Anfrage und stellen Sie sicher, dass nicht bereits jemand anderes dieselbe Funktion angefragt hat.

## Beitragsrichtlinien

Beiträge zu CloudGoat werden sehr geschätzt. Wenn Sie helfen möchten, das Projekt zu verbessern, lesen Sie weiter.

1. **Erstellen eines neuen Szenarios**:
   - Wir haben eine Szenario-Vorlage bereitgestellt, die Ihnen den schnellen Einstieg erleichtert. Die Vorlage enthält die grundlegende Struktur und die notwendigen Dateien für ein CloudGoat-Szenario. Sie finden die Szenario-Vorlage [hier](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/scenarios/scenario_template).
   - **Schritte zum Erstellen eines neuen Szenarios**:
     - **Kopieren Sie die Vorlage**: Kopieren Sie den Inhalt der Szenario-Vorlage in ein neues Verzeichnis, das nach Ihrem Szenario benannt ist.
     - **Passen Sie die Vorlage an**: Ersetzen Sie den Platzhalterinhalt in der Vorlage durch die Einzelheiten Ihres neuen Szenarios.
     - **Testen Sie das Szenario**: Stellen Sie sicher, dass Ihr Szenario wie erwartet funktioniert, indem Sie es gründlich testen.
2. **Codierungsstandards**:
   - **Code-Stil**: Folgen Sie dem vorhandenen Code-Stil im Projekt. Konsistenz ist entscheidend.
   - **Kommentare**: Fügen Sie Kommentare zu Ihrem Code hinzu, wo nötig, um komplexe Logik oder wichtige Entscheidungen zu erläutern.
   - **Dokumentation**: Aktualisieren Sie die README.md und andere relevante Dokumentationen, um Details zu Ihrem neuen Szenario oder Ihren Änderungen aufzunehmen.
3. **Whitelisting**:
   - Beachten Sie beim Erstellen oder Ändern von Szenarien Folgendes:
     - **Whitelisting**: Stellen Sie sicher, dass Sicherheitsgruppenregeln und andere Zugriffskontrollen so konfiguriert sind, dass nur die IP aus der CloudGoat-Konfiguration auf die Whitelist gesetzt wird.
     - **Überprüfung**: Überprüfen Sie Ihre Konfigurationen vor dem Beitrag zweimal auf potenziell gefährdete öffentliche Ressourcen (d.h. erstellen Sie keine verwundbaren EC2-Instanzen, die vom Internet aus zugänglich sind).
4. **Python-Code-Stil**:
   - Python-Code in CloudGoat sollte im Allgemeinen den Python-Stilkonventionen folgen, wobei Lesbarkeit und Wartbarkeit an erster Stelle stehen.
   - Beachten Sie gute Git-Praktiken: Verwenden Sie Pull-Requests, bevorzugen Sie Feature-Branches und schreiben Sie stets klare Commit-Nachrichten.
   - CloudGoat verwendet `black` und `flake8` – Python-Syntax- und Stil-Linter. Stellen Sie sicher, dass sowohl `flake8` als auch `black` auf allen Python-Dateien in `core/python/` und auf `cloudgoat.py` ausgeführt werden, bevor Sie Code committen. Die Entscheidungen von `black` haben Vorrang vor denen von `flake8`. Beide sind in der Datei `core/python/requirements.txt` auskommentiert, da normale Benutzer sie nicht benötigen.
5. **Lizenzierung**:
   - CloudGoat-Code sollte stets unter der BSD-3-Klausel-Lizenz stehen.

Und zu guter Letzt: Vielen Dank für Ihren Beitrag!


## Änderungsprotokoll

- **24.06.19:** CloudGoat 2.0 wurde veröffentlicht!

## Haftungsausschluss

CloudGoat ist Software, die ohne jegliche Gewährleistung bereitgestellt wird. Durch die Nutzung von CloudGoat übernehmen Sie die volle Verantwortung für alle daraus resultierenden Ergebnisse.