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

Potresti anche voler eseguire alcuni comandi di configurazione rapidi - ti farà risparmiare tempo in seguito:

- Configura per AWS - indica a CloudGoat quale profilo AWS utilizzare.```bash
cloudgoat config aws

Accedi ad Azure - CloudGoat utilizza l'account `az` attivo.```bash
az login

Ora, al tuo comando, CloudGoat può `create` un'istanza di uno scenario nel cloud. Quando l'ambiente è pronto, verrà creata una nuova cartella nella directory base del progetto, con il nome dello scenario e un ID univoco aggiunto. All'interno di questa cartella ci sarà un file chiamato `start.txt`, che conterrà tutte le risorse necessarie per iniziare lo scenario, anche se queste vengono stampate anche nella console al termine del comando `create`. A volte verrà creata anche una coppia di chiavi SSH chiamata `cloudgoat`/`cloudgoat.pub`.

> **Nota:** Non eliminare o modificare la cartella dell'istanza dello scenario o i file al suo interno, poiché ciò potrebbe impedire a CloudGoat di gestire le risorse del tuo scenario.

Mentre lavori allo scenario, sentiti libero di consultare il readme dello scenario se hai bisogno di indicazioni. Se ti blocchi, ci sono cheat sheet collegati in fondo a ogni percorso della walkthrough.

Quando hai finito con lo scenario, elimina tutte le risorse che hai creato tu stesso (ricorda: CloudGoat può gestire solo le risorse che crea) e poi esegui il comando `destroy`. È sempre una buona idea dare un'occhiata rapida alla console web dopo, nel caso qualcosa non sia stato eliminato.

Puoi leggere la documentazione completa per i comandi di CloudGoat [qui nella sezione Guida all'uso](#usage-guide).

## Come utilizzare l'immagine Docker di 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)

### Opzione 1: Esegui con entrypoint predefinito```console
docker run -it rhinosecuritylabs/cloudgoat:latest

## Scenari Disponibili
(Raggruppati per Difficoltà)

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

---

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

In questo scenario, inizi con le chiavi di accesso per un utente IAM di basso livello chiamato Bob. Il tuo compito è eseguire un'enumerazione approfondita dell'IAM utilizzando la AWS CLI. Investigando policy gestite, policy inline, appartenenze a gruppi e ruoli assumibili, scoprirai cinque flag distinti. 

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_enum_basics/README.md)  

Contribuito da Tyler Ramsbey

---

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

In questo scenario, inizi con un utente IAM con permessi limitati. Il tuo compito è identificare un'istanza EC2 configurata in modo errato che perde credenziali nei suoi User Data, permettendoti di ottenere accesso SSH. Da lì, devi effettuare un pivot sfruttando il servizio Instance Metadata (IMDS) per rubare un ruolo, enumerare le funzioni Lambda per trovare variabili d'ambiente nascoste e infine compromettere un utente con accesso all'obiettivo dello scenario: un segreto memorizzato in AWS Secrets Manager.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/data_secrets/README.md)  

Contribuito da Tyler Ramsbey

---

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

In questo scenario, ti vengono fornite credenziali AWS a bassi privilegi che concedono accesso limitato a Elastic Beanstalk. Il tuo compito è enumerare l'ambiente Elastic Beanstalk e scoprire variabili d'ambiente configurate in modo errato contenenti credenziali secondarie. Utilizzando queste credenziali secondarie, puoi enumerare i permessi IAM per creare infine una chiave di accesso per un utente amministratore. Con questi privilegi amministrativi, recuperi il flag finale memorizzato in AWS Secrets Manager.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/beanstalk_secrets/README.md)  

Contribuito da Tyler Ramsbey

---

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

In questo scenario, inizi con accesso base a un account AWS. Devi enumerare i tuoi privilegi, scoprire un Argomento SNS a cui puoi iscriverti, recuperare una chiave API trapelata e infine utilizzare la chiave API per accedere a un API Gateway per il flag finale.  

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/sns_secrets/README.md)  

Contribuito da Tyler Ramsbey

---

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

Sfrutta permessi IAM insicuri per escalare il tuo accesso. Inizia con un ruolo che gestisce le credenziali di altri utenti e trova un punto debole nella configurazione per accedere al ruolo "admin". Utilizzando il ruolo admin, recupera il flag da Secrets Manager.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_key_rotation/README.md)

Contribuito da Infrasec.sh 

---

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

Partendo da un utente IAM molto limitato, l'attaccante può rivedere le versioni precedenti delle policy IAM e ripristinarne una che concede privilegi completi di amministratore, portando a uno sfruttamento di escalation dei privilegi.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_rollback/README.md)

---

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

Partendo come utente IAM Chris, l'attaccante scopre di poter assumere un ruolo che ha accesso completo a Lambda e permessi di passaggio ruolo. L'attaccante può quindi eseguire l'escalation dei privilegi utilizzando questi nuovi permessi per ottenere privilegi completi di amministratore.

> **Nota:** Questo scenario potrebbe richiedere la creazione di alcune risorse AWS e, poiché CloudGoat può gestire solo le risorse che crea, è necessario rimuoverle manualmente prima di eseguire `./cloudgoat destroy`.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/lambda_privesc/README.md)

---

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

Per prima cosa, inizia con la pagina SHOP dove puoi acquistare FLAG. Il sito web ha diverse pagine e puoi vedere che il codice sorgente è esposto. Gli attaccanti analizzano il codice per trovare vulnerabilità e utilizzano i loro privilegi per acquistare FLAG.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/sqs_flag_shop/README.md)
  
</details>

<details>
  <summary><strong>Medio</strong></summary>

### static (Medio)
`cloudgoat create static`

In questo scenario, agisci come un attaccante esterno che visita un portale aziendale. Analizzando l'applicazione web, identifichi che carica librerie JavaScript critiche da un bucket S3 pubblico. Devi scoprire una configurazione errata nei permessi del bucket, eseguire un "Supply Chain Attack" sovrascrivendo la libreria con codice dannoso e attendere che un bot amministratore interno effettui il login. Il tuo obiettivo è catturare le credenziali del bot e es filtrarle di nuovo nel bucket.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/static/README.md)  

### vulnerable_cognito (Medio)
`cloudgoat create vulnerable_cognito`

In questo scenario, ti viene presentata una pagina di registrazione e login con AWS Cognito nel backend. Devi bypassare le restrizioni e sfruttare le configurazioni errate in Amazon Cognito per elevare i tuoi privilegi e ottenere le credenziali del pool di identità di Cognito.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/vulnerable_cognito/README.md)

Contribuito da TrustOnCloud 

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

In questo scenario, inizi come utente 'bilbo'. Assumerai un ruolo con più privilegi, scoprirai una funzione Lambda che applica policy agli utenti e sfrutterai una vulnerabilità nella funzione per escalare i privilegi dell'utente bilbo al fine di cercare segreti.  

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/vulnerable_lambda/README.md)

---

### cloud_breach_s3 (Medio)
`cloudgoat create cloud_breach_s3`

Partendo come un estraneo anonimo senza accesso o privilegi, sfrutta un server proxy inverso configurato in modo errato per interrogare il servizio di metadati EC2 e acquisire le chiavi del profilo dell'istanza. Quindi, utilizza quelle chiavi per scoprire, accedere ed esfiltrare dati sensibili da un bucket S3.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/cloud_breach_s3/README.md)

---

### iam_privesc_by_attachment (Medio)
`cloudgoat create iam_privesc_by_attachment`

Partendo con un set di permessi molto limitato, l'attaccante è in grado di sfruttare i permessi di allegamento del profilo dell'istanza per creare una nuova istanza EC2 con privileggi significativamente maggiori dei propri. Con l'accesso a questa nuova istanza EC2, l'attaccante ottiene pieni poteri amministrativi all'interno dell'account target ed è in grado di raggiungere l'obiettivo dello scenario: eliminare il cg-super-critical-security-server e aprire la strada per ulteriori azioni maligne.

> **Nota:** Questo scenario potrebbe richiedere la creazione di alcune risorse AWS e, poiché CloudGoat può gestire solo le risorse che crea, è necessario rimuoverle manualmente prima di eseguire `./cloudgoat destroy`.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_attachment/README.md)

---

### ec2_ssrf (Medio)
`cloudgoat create ec2_ssrf`

Partendo come utente IAM Solus, l'attaccante scopre di avere permessi di sola lettura su una funzione Lambda, dove segreti hardcoded li conducono a un'istanza EC2 che esegue un'applicazione web vulnerabile a server-side request forgery (SSRF). Dopo aver sfruttato l'app vulnerabile e acquisito chiavi dal servizio di metadati EC2, l'attaccante ottiene accesso a un bucket S3 privato con un set di chiavi che gli permettono di invocare la funzione Lambda e completare lo scenario.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ec2_ssrf/README.md)

---

### ecs_takeover (Medio)
`cloudgoat create ecs_takeover`

Partendo con accesso al sito web esterno, l'attaccante deve trovare una vulnerabilità di esecuzione di codice remoto. Usando RCE, l'attaccante può ottenere accesso alle risorse disponibili per il contenitore del sito web. Sfruttando diverse configurazioni errate di ECS, l'attaccante ottiene permessi IAM che gli permettono di forzare ECS a riprogrammare il contenitore target su un'istanza compromessa.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_takeover/README.md)

---

### rds_snapshot (Medio)
`cloudgoat create rds_snapshot`

In questo scenario, iniziamo con l'utente 'David'. Attraverso David, puoi sfruttare i privilegi per rubare credenziali.
Con le credenziali rubate, un attaccante può sfruttare la vulnerabilità RDS per accedere al DB e recuperare i flag.

> **Nota:** Questo scenario potrebbe richiedere la creazione di alcune risorse AWS e, poiché CloudGoat può gestire solo le risorse che crea, è necessario rimuoverle manualmente prima di eseguire `./cloudgoat destroy`. 

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/rds_snapshot/README.md)

---

### glue_privesc (Medio)
`cloudgoat create glue_privesc`  

Questo scenario inizia con una pagina web che carica un file CSV e esegue la visualizzazione dei dati tramite il servizio Glue.
L'attaccante ruba le credenziali presenti sulla pagina web tramite un attacco SQL injection e carica una reverse shell per creare un Glue Job e ottenere la stringa segreta.

> **Nota:** Questo scenario potrebbe richiedere la creazione di alcune risorse AWS e, poiché CloudGoat può gestire solo le risorse che crea, è necessario rimuoverle manualmente prima di eseguire `./cloudgoat destroy`.  

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/glue_privesc/README.md)

---

### agentcore_identity_confusion (Medio)
`cloudgoat create agentcore_identity_confusion`

In questo scenario, ti vengono fornite credenziali AWS che possono gestire gli interpreti di codice bedrock agentcore. Il tuo compito è sfruttare questo per ottenere accesso a dati sensibili utilizzati da altri agenti runtime di agentcore. Scopri come ottenere accesso al flag memorizzato in una knowledge base di bedrock.

> **Nota:** Questo scenario potrebbe richiedere la creazione di alcune risorse AWS e, poiché CloudGoat può gestire solo le risorse che crea, è necessario rimuoverle manualmente prima di eseguire `./cloudgoat destroy`.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/agentcore_identity_confusion/README.md)

Contribuito da Sonrai Security

---

### bedrock_agent_hijacking (Medio)
`cloudgoat create bedrock_agent_hijacking`

In questo scenario, ti vengono fornite credenziali AWS che possono invocare un Bedrock Agent e aggiornare funzioni lambda. Il tuo compito è analizzare l'agente e capire come accede alle informazioni in tempo reale. Intercetta questo flusso per individuare ed estrarre il flag memorizzato in S3.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/bedrock_agent_hijacking/README.md)

Contribuito da Sonrai Security

</details>

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

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

Partendo come utente IAM Lara, l'attaccante esplora un Load Balancer e un bucket S3 per trovare indizi sulle vulnerabilità, portando a uno sfruttamento RCE su un'app web vulnerabile che espone file confidenziali e culmina nell'accesso all'obiettivo dello scenario: un'istanza di database RDS altamente protetta.

In alternativa, l'attaccante può partire come utente IAM McDuck ed enumerare i bucket S3, portando infine a chiavi SSH che concedono accesso diretto al server EC2 e al database oltre.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/rce_web_app/README.md)

---

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

Partendo come utente IAM Solo, l'attaccante enumera ed esplora per primi i progetti CodeBuild, trovando al loro interno chiavi IAM non sicure per l'utente IAM Calrissian. Quindi, operando come Calrissian, l'attaccante scopre un database RDS. Non potendo accedere direttamente ai contenuti del database, l'attaccante può fare un uso intelligente della funzionalità di snapshot RDS per acquisire l'obiettivo dello scenario: una coppia di stringhe segrete.

In alternativa, l'attaccante può esplorare i parametri SSM e trovare chiavi SSH per un'istanza EC2. Utilizzando il servizio di metadati, l'attaccante può acquisire le chiavi del profilo dell'istanza EC2 e spingersi più a fondo nell'ambiente target, ottenendo infine l'accesso al database originale e all'obiettivo dello scenario (una coppia di stringhe segrete) attraverso un percorso più tortuoso.

> **Nota:** Questo scenario potrebbe richiedere la creazione di alcune risorse AWS e, poiché CloudGoat può gestire solo le risorse che crea, è necessario rimuoverle manualmente prima di eseguire `./cloudgoat destroy`.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/codebuild_secrets/README.md)

---

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

L'obiettivo di questo scenario è leggere i valori di entrambi i segreti senza essere rilevati. I segreti sono entrambi memorizzati in Secrets Manager e i loro valori hanno il seguente formato (cg-secret-XXXXXX-XXXXXX).

Questo scenario è significativamente diverso dagli altri scenari di CloudGoat. In detection_evasion, i tuoi obiettivi ti saranno delineati più chiaramente e la sfida è completarli senza attivare allarmi. C'è più configurazione coinvolta in questo scenario, e ci vorrà più tempo per giocare (potresti voler/dover giocare più volte).

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/detection_evasion/README.md)

---

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

Partendo con accesso all'EC2 "ruse", l'utente sfrutta il profilo dell'istanza per backdoorare il contenitore ECS in esecuzione. Utilizzando il contenitore backdoorato, l'attaccante può recuperare le credenziali dall'API dei metadati del contenitore. Queste credenziali permettono all'attaccante di avviare una sessione su qualsiasi EC2 con i tag appropriati impostati. L'attaccante utilizza i propri permessi per cambiare i tag sull'Admin EC2 e avvia una sessione. Una volta nell'Admin EC2, l'attaccante eseguirà una scansione delle porte sulla subnet per trovare un EFS aperto da montare. Una volta montato, l'attaccante può recuperare il flag dal file system elastico.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_efs_attack/README.md)

---

### ecs_privesc_evade_protection (Medio)
`cloudgoat create ecs_privesc_evade_protection`

Un utente inizia accedendo a un servizio web funzionante per un contenitore all'interno di EC2. L'attaccante può sfruttare una vulnerabilità del servizio web per ottenere credenziali dall'API dei metadati in EC2, o per controllare il contenitore. Questa credenziale permette all'attaccante di avviare un nuovo contenitore con un ruolo specifico e controllarlo. Basandosi su questa azione, esegue un'escalation dei privilegi e legge FLAG in S3.

> **Nota:** Questo scenario richiede che Docker sia installato localmente, poiché durante la distribuzione costruisce e invia un'immagine del contenitore a ECR.

[Visita la pagina dello scenario.](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`

Come utente IAM con privilegi limitati, l'attaccante inizia il suo viaggio esaminando le risorse AWS per scoprire indizi e informazioni nascoste. Questa indagine porta infine all'acquisizione di un ruolo che concede accesso all'obiettivo primario dello scenario: recuperare il segreto finale da Secrets Manager.

[Visita la pagina dello scenario.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/secrets_in_the_cloud/README.md)
  
</details>



## Guida all'Utilizzo

L'anatomia di base di un comando CloudGoat è la seguente:

> `cloudgoat [ comando ] [ sotto-comando ] [ --nome-argomento ] [ valore-argomento ]`

I cinque comandi principali in CloudGoat sono riassunti di seguito:

### create

`create [ nome-scenario ]` distribuisce uno scenario nell'account AWS di tua scelta. Puoi anche eseguire `create` su uno scenario esistente se lo desideri - CloudGoat semplicemente distruggerà e ricreerà lo scenario nominato.

> **Suggerimento:** puoi usare `/scenarios` nel nome, che consente il completamento con tabulazione nativo di bash.

Nota che `--profile` è richiesto per motivi di sicurezza - non vogliamo che nessuno distribuisca accidentalmente scenari CloudGoat in un ambiente di produzione - e CloudGoat non utilizzerà i profili CLI AWS "default" del sistema o i profili specificati come predefiniti tramite variabili d'ambiente. Puoi comunque impostarlo tramite `config aws` per evitare di doverlo fornire ogni volta.

### list

`list` mostra alcune informazioni sugli scenari `all` (tutti), `undeployed` (non distribuiti), o `deployed` (distribuiti), o anche molte informazioni su un `[ nome-scenario ]` già distribuito. Puoi anche filtrare gli scenari per piattaforma cloud: `list aws` o `list azure`.

### destroy

`destroy` spegne ed elimina le risorse cloud di un `[ nome-scenario ]`, e quindi sposta la cartella dell'istanza dello scenario in `./trash` - nel caso tu abbia bisogno di recuperare il file di stato di Terraform o altri file dello scenario. Puoi anche specificare `all` invece di un nome di scenario per distruggere tutti gli scenari attivi.

> **Suggerimento:** CloudGoat può gestire solo le risorse che crea. Se crei delle risorse tu stesso durante lo scenario, dovresti rimuoverle manualmente prima di eseguire il comando `destroy`.

### config

`config` ti permette di gestire vari aspetti della tua installazione di CloudGoat, in particolare la `whitelist` degli IP, il tuo `profile` AWS predefinito e il completamento tramite tabulazione con `argcomplete`. Vale la pena descrivere brevemente cosa fa ciascuno di questi sotto-comandi.

#### whitelist

CloudGoat ha bisogno di sapere quali indirizzi IP devono essere inseriti nella whitelist quando vengono distribuite risorse potenzialmente vulnerabili nel cloud; questi IP sono tracciati in un file `./whitelist.txt` nella directory di base del progetto. L'indirizzo IP che fornisci per la whitelist non _deve_ essere in formato CIDR, ma CloudGoat aggiungerà un `/32` a qualsiasi IP nudo che fornisci. Opzionalmente, puoi aggiungere l'argomento `--auto`, e CloudGoat farà automaticamente una richiesta di rete, usando curl per ifconfig.co per trovare il tuo indirizzo IP, e quindi creerà il file whitelist con il risultato.

#### aws

Sebbene CloudGoat non utilizzi mai i profili CLI AWS "default" del sistema o i profili specificati come predefiniti tramite variabili d'ambiente, puoi istruire CloudGoat a utilizzare un particolare profilo AWS per nome usando il comando `config aws`. Questo richiederà e salverà il nome del tuo profilo in un file `config.yml` nella directory di base del progetto. Fintanto che quel file è presente, CloudGoat utilizzerà il nome del profilo elencato al suo interno per i comandi create e destroy, invece di richiedere il flag `--profile`. Puoi eseguire il comando `config aws` in qualsiasi momento per visualizzare il nome del tuo profilo predefinito di CloudGoat e convalidare il formato del file `config.yml`. Puoi anche creare `config.yml` manualmente, se lo desideri, purché utilizzi il formato corretto.

#### azure

Le versioni più recenti del provider Azure per Terraform richiedono l'ID della sottoscrizione per applicare le risorse. Sebbene CloudGoat utilizzi la stessa configurazione delle credenziali dell'utility `az`, CloudGoat deve essere informato esplicitamente su quale sottoscrizione distribuire. La configurazione si effettua con `cloudgoat config azure`, e la sottoscrizione viene memorizzata in `config.yml` insieme alla configurazione AWS. Puoi anche creare `config.yml` manualmente, se lo desideri, purché utilizzi il formato corretto.

#### argcomplete

Volevamo davvero avere il completamento nativo con tabulazione in CloudGoat, ma si è rivelato piuttosto difficile da realizzare al di fuori di un REPL. Dovrebbe funzionare ragionevolmente bene per gli utenti Linux, e per quegli utenti OSX abbastanza coraggiosi da trovare un modo per aggiornare la loro versione di bash a 4.2+. CloudGoat include e supporta [la libreria python "argcomplete"](https://github.com/kislyuk/argcomplete). Di seguito è fornito un breve riepilogo di come installare argcomplete, anche se per passaggi più dettagliati dovresti fare riferimento alla documentazione ufficiale sulla [pagina github](https://github.com/kislyuk/argcomplete) della libreria.

1. Installa il pacchetto Python argcomplete utilizzando il file requirements.txt di CloudGoat: `$ pip3 install -r core/python/requirements.txt`
2. In bash, esegui lo script di completamento degli argomenti Python globale fornito dal pacchetto argcomplete: `$ activate-global-python-argcomplete`
3. Sorgente il completamento script nella posizione stampata dal comando di attivazione precedente, o riavvia la sessione della shell: `$ source [ /percorso/del/script/di/completamento ]`

Per coloro che non possono o non desiderano configurare argcomplete, CloudGoat supporta anche l'uso di percorsi di directory come nomi di scenario, il che significa che il completamento con tabulazione funzionerà per i nomi di scenario. Basta usare `/scenario/[ nome-scenario ]` o `./[ nome-istanza-scenario ]` e la tua shell dovrebbe fare il resto.

### help

`help` fornisce aiuto contestuale sui comandi. `help` può essere inserito prima o dopo il comando in questione, quindi è sempre lì quando ne hai bisogno. Di seguito sono riportati alcuni esempi:* `cloudgoat create help`
* `cloudgoat destroy help`
* `cloudgoat list help`
* `cloudgoat config help`

Un altro uso degno di nota: `cloudgoat [ nome-scenario ] help` può essere utilizzato per stampare sulla console un breve riassunto dello scenario, come definito dall'autore dello scenario.

## Richieste di funzionalità e segnalazioni di bug

Se hai una richiesta di funzionalità o un bug da segnalare, [inviala qui](https://github.com/RhinoSecurityLabs/cloudgoat/issues/new).

Per i bug, assicurati di includere una descrizione sufficiente per riprodurre il bug trovato, includendo traceback e passaggi per la riproduzione, e verifica che non ci siano altre segnalazioni del tuo bug prima di aprirne una nuova.

Per le funzionalità, vale lo stesso! Sii preciso nella tua richiesta e assicurati che qualcun altro non abbia già richiesto la stessa funzionalità.

## Linee guida per i contributi

I contributi a CloudGoat sono molto apprezzati. Se desideri contribuire a migliorare il progetto, continua a leggere.

1. **Creare un nuovo scenario**:
   - Abbiamo fornito un template per scenario per aiutarti a iniziare rapidamente. Il template include la struttura di base e i file necessari per uno scenario CloudGoat. Puoi trovare il template per scenario [qui](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/scenarios/scenario_template).
   - **Passaggi per creare un nuovo scenario**:
     - **Copia il template**: Copia il contenuto del template per scenario in una nuova directory con il nome del tuo scenario.
     - **Modifica il template**: Sostituisci il contenuto segnaposto nel template con i dettagli del tuo nuovo scenario.
     - **Testa lo scenario**: Assicurati che il tuo scenario funzioni come previsto testandolo accuratamente.
2. **Standard di codifica**:
   - **Stile del codice**: Segui lo stile del codice esistente nel progetto. La coerenza è fondamentale.
   - **Commenti**: Aggiungi commenti al tuo codice dove necessario per spiegare logiche complesse o decisioni importanti.
   - **Documentazione**: Aggiorna il file README.md e altra documentazione pertinente per includere dettagli sul tuo nuovo scenario o modifiche.
3. **Whitelisting**:
   - Quando crei o modifichi scenari, tieni presente quanto segue:
     - **Whitelisting**: Assicurati che le regole del gruppo di sicurezza e altri controlli di accesso siano configurati per autorizzare solo l'IP dalla configurazione di CloudGoat.
     - **Revisione**: Ricontrolla le tue configurazioni per eventuali risorse pubbliche potenzialmente vulnerabili prima di contribuire (ad esempio, non creare EC2 vulnerabili accessibili da Internet).
4. **Stile del codice Python**:
   - Il codice Python in CloudGoat dovrebbe generalmente seguire le convenzioni di stile di Python, privilegiando leggibilità e manutenibilità sopra ogni altra cosa.
   - Segui buone pratiche git: usa le pull request, preferisci i rami di funzionalità, scrivi sempre messaggi di commit chiari.
   - CloudGoat utilizza `black` e `flake8` - linter di sintassi e stile Python. Assicurati che sia `flake8` che `black` vengano eseguiti su tutti i file Python in `core/python/` e su `cloudgoat.py` prima di inviare il codice. Le decisioni di `black` hanno priorità su quelle di `flake8`. Entrambi sono commentati nel file `core/python/requirements.txt` poiché gli utenti normali non ne hanno bisogno.
5. **Licenze**:
   - Il codice di CloudGoat deve sempre utilizzare la licenza BSD a 3 clausole.

E infine, grazie per il tuo contributo!

## Registro delle modifiche

- **24/06/19:** CloudGoat 2.0 è stato rilasciato!

## Dichiarazione di non responsabilità

CloudGoat è un software fornito senza alcuna garanzia di alcun tipo. Utilizzando CloudGoat, ti assumi la piena responsabilità per qualsiasi risultato che ne derivi.