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

Você também pode querer executar alguns comandos de configuração rápida - isso economizará tempo mais tarde:

Configure para AWS - informe ao CloudGoat qual perfil AWS usar.```bash
cloudgoat config aws

Faça login no Azure - CloudGoat usa a conta `az` ativa.```bash
az login

Agora, sob seu comando, o CloudGoat pode `create` uma instância de um cenário na nuvem. Quando o ambiente estiver pronto, uma nova pasta será criada no diretório base do projeto com o nome do cenário e um ID único de cenário anexado. Dentro desta pasta haverá um arquivo chamado `start.txt`, que conterá todos os recursos que você precisará para iniciar o cenário, embora estes também sejam impressos no console quando o comando `create` for concluído. Às vezes, um par de chaves SSH chamado `cloudgoat`/`cloudgoat.pub` também será criado.

> **Nota:** Não exclua ou modifique a pasta da instância do cenário ou os arquivos dentro dela, pois isso pode impedir que o CloudGoat gerencie os recursos do seu cenário.

Conforme você trabalha no cenário, sinta-se à vontade para consultar o readme do cenário se precisar de orientação. Se ficar preso, há folhas de dicas vinculadas no final da descrição de cada rota.

Quando você terminar o cenário, exclua todos os recursos que você mesmo criou (lembre-se: o CloudGoat só pode gerenciar recursos que ele cria) e então execute o comando `destroy`. É sempre uma boa ideia dar uma olhada rápida no seu web-console depois - apenas para o caso de algo não ter sido excluído.

Você pode ler a documentação completa dos comandos do CloudGoat [aqui na seção Guia de Uso](#usage-guide).

## Como usar a imagem Docker do 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)

### Opção 1: Executar com entrypoint padrão```console
docker run -it rhinosecuritylabs/cloudgoat:latest

## Cenários Disponíveis
(Agrupados por Dificuldade)

<details open>
  <summary><strong>Fácil</strong></summary>

---

### iam_enum_basics (Fácil)
`cloudgoat create iam_enum_basics`

Neste cenário, você começa com as chaves de acesso de um usuário IAM de baixo nível chamado Bob. Sua tarefa é realizar uma enumeração detalhada do IAM usando a AWS CLI. Investigando políticas gerenciadas, políticas inline, associações de grupos e funções que podem ser assumidas, você descobrirá cinco flags distintas. 

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_enum_basics/README.md)  

Contribuído por Tyler Ramsbey

---

### data_secrets (Fácil)
`cloudgoat create data_secrets`

Neste cenário, você começa com um usuário IAM com permissões limitadas. Sua tarefa é identificar uma instância EC2 mal configurada que está vazando credenciais em seus User Data, permitindo obter acesso SSH. A partir daí, você deve pivotar explorando o Serviço de Metadados de Instância (IMDS) para roubar uma função, enumerar funções Lambda para encontrar variáveis de ambiente ocultas e, finalmente, comprometer um usuário com acesso ao objetivo do cenário: um segredo armazenado no AWS Secrets Manager.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/data_secrets/README.md)  

Contribuído por Tyler Ramsbey

---

### beanstalk_secrets (Fácil)
`cloudgoat create beanstalk_secrets`

Neste cenário, você recebe credenciais AWS de baixo privilégio que concedem acesso limitado ao Elastic Beanstalk. Sua tarefa é enumerar o ambiente Elastic Beanstalk e descobrir variáveis de ambiente mal configuradas contendo credenciais secundárias. Usando essas credenciais secundárias, você pode enumerar permissões IAM para eventualmente criar uma chave de acesso para um usuário administrador. Com esses privilégios de administrador, você recupera a flag final armazenada no AWS Secrets Manager.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/beanstalk_secrets/README.md)  

Contribuído por Tyler Ramsbey

---

### sns_secrets (Fácil)
`cloudgoat create sns_secrets`

Neste cenário, você começa com acesso básico a uma conta AWS. Você precisa enumerar seus privilégios, descobrir um Tópico SNS ao qual pode se inscrever, recuperar uma chave de API vazada e, finalmente, usar a chave de API para acessar um API Gateway para obter a flag final.  

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/sns_secrets/README.md)  

Contribuído por Tyler Ramsbey

---

### iam_privesc_by_key_rotation (Fácil)
`cloudgoat create iam_privesc_by_key_rotation`

Explore permissões IAM inseguras para escalar seu acesso. Comece com uma função que gerencia credenciais de outros usuários e encontre uma fraqueza na configuração para acessar a função "admin". Usando a função admin, recupere a flag do Secrets Manager.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_key_rotation/README.md)

Contribuído por Infrasec.sh 

---

### iam_privesc_by_rollback (Fácil)
`cloudgoat create iam_privesc_by_rollback`

Começando com um usuário IAM altamente limitado, o atacante consegue revisar versões anteriores de políticas IAM e restaurar uma que concede privilégios totais de administrador, resultando em uma exploração de escalada de privilégios.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_rollback/README.md)

---

### lambda_privesc (Fácil)
`cloudgoat create lambda_privesc`

Começando como o usuário IAM Chris, o atacante descobre que pode assumir uma função que tem acesso total a Lambda e permissões para passar funções. O atacante pode então realizar escalada de privilégios usando essas novas permissões para obter privilégios totais de administrador.

> **Nota:** Este cenário pode exigir que você crie alguns recursos AWS, e como o CloudGoat só pode gerenciar recursos que ele cria, você deve removê-los manualmente antes de executar `./cloudgoat destroy`.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/lambda_privesc/README.md)

---

### sqs_flag_shop (Fácil)
`cloudgoat create sqs_flag_shop`

Primeiro, comece com a página SHOP onde você pode comprar FLAG. O site tem várias páginas, e você pode ver que o código fonte está exposto. Os atacantes analisam o código para encontrar vulnerabilidades e usam seus privilégios para comprar a FLAG.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/sqs_flag_shop/README.md)
  
</details>

<details>
  <summary><strong>Médio</strong></summary>

### static (Médio)
`cloudgoat create static`

Neste cenário, você age como um atacante externo visitando um portal corporativo. Ao analisar a aplicação web, você identifica que ela carrega bibliotecas JavaScript críticas de um bucket S3 público. Você deve descobrir uma má configuração nas permissões do bucket, realizar um "Ataque à Cadeia de Suprimentos" sobrescrevendo a biblioteca com código malicioso e esperar que um bot administrador interno faça login. Seu objetivo é capturar as credenciais do bot e exfiltrá-las de volta para o bucket.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/static/README.md)  

### vulnerable_cognito (Médio)
`cloudgoat create vulnerable_cognito`

Neste cenário, você recebe uma página de cadastro e login com AWS Cognito no backend. Você precisa contornar restrições e explorar má configurações no Amazon Cognito para elevar seus privilégios e obter credenciais do Cognito Identity Pool.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/vulnerable_cognito/README.md)

Contribuído por TrustOnCloud 

---
### vulnerable_lambda (Médio)
`cloudgoat create vulnerable_lambda`

Neste cenário, você começa como o usuário 'bilbo'. Você assumirá uma função com mais privilégios, descobrirá uma função lambda que aplica políticas a usuários e explorará uma vulnerabilidade na função para escalar os privilégios do usuário bilbo, a fim de procurar segredos.  

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/vulnerable_lambda/README.md)

---

### cloud_breach_s3 (Médio)
`cloudgoat create cloud_breach_s3`

Começando como um outsider anônimo sem acesso ou privilégios, explore um servidor proxy reverso mal configurado para consultar o serviço de metadados EC2 e adquirir chaves de perfil de instância. Em seguida, use essas chaves para descobrir, acessar e exfiltrar dados confidenciais de um bucket S3.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/cloud_breach_s3/README.md)

---

### iam_privesc_by_attachment (Médio)
`cloudgoat create iam_privesc_by_attachment`

Começando com um conjunto muito limitado de permissões, o atacante consegue aproveitar as permissões de anexação de perfil de instância para criar uma nova instância EC2 com privilégios significativamente maiores que os seus. Com acesso a esta nova instância EC2, o atacante obtém poderes administrativos totais na conta alvo e consegue cumprir o objetivo do cenário - deletar o cg-super-critical-security-server e abrir caminho para ações futuras nefastas.

> **Nota:** Este cenário pode exigir que você crie alguns recursos AWS, e como o CloudGoat só pode gerenciar recursos que ele cria, você deve removê-los manualmente antes de executar `./cloudgoat destroy`.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/iam_privesc_by_attachment/README.md)

---

### ec2_ssrf (Médio)
`cloudgoat create ec2_ssrf`

Começando como o usuário IAM Solus, o atacante descobre que tem permissões ReadOnly para uma função Lambda, onde segredos codificados o levam a uma instância EC2 executando uma aplicação web vulnerável a server-side request forgery (SSRF). Após explorar a aplicação vulnerável e adquirir chaves do serviço de metadados EC2, o atacante ganha acesso a um bucket S3 privado com um conjunto de chaves que permitem invocar a função Lambda e completar o cenário.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ec2_ssrf/README.md)

---

### ecs_takeover (Médio)
`cloudgoat create ecs_takeover`

Começando com acesso ao site externo, o atacante precisa encontrar uma vulnerabilidade de execução remota de código. Usando RCE, o atacante pode obter acesso aos recursos disponíveis para o contêiner do site. Abusando de várias configurações incorretas do ECS, o atacante obtém acesso a permissões IAM que permitem forçar o ECS a reagendar o contêiner alvo para uma instância comprometida.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_takeover/README.md)

---

### rds_snapshot (Médio)
`cloudgoat create rds_snapshot`

Neste cenário, começamos com o usuário 'David'. Através de David, você pode aproveitar privilégios para roubar credenciais.
Com as credenciais roubadas, um atacante pode aproveitar a vulnerabilidade RDS para acessar o banco de dados e recuperar flags.

> **Nota:** Este cenário pode exigir que você crie alguns recursos AWS, e como o CloudGoat só pode gerenciar recursos que ele cria, você deve removê-los manualmente antes de executar `./cloudgoat destroy`. 

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/rds_snapshot/README.md)

---

### glue_privesc (Médio)
`cloudgoat create glue_privesc`  

Este cenário começa com uma página web que envia um arquivo CSV e realiza visualização de dados através do serviço Glue.
O atacante rouba as credenciais presentes na página através de um ataque de injeção SQL e faz upload de um shell reverso para criar um Glue Job e obter a string secreta.

> **Nota:** Este cenário pode exigir que você crie alguns recursos AWS, e como o CloudGoat só pode gerenciar recursos que ele cria, você deve removê-los manualmente antes de executar `./cloudgoat destroy`.  

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/glue_privesc/README.md)

---

### agentcore_identity_confusion (Médio)
`cloudgoat create agentcore_identity_confusion`

Neste cenário, você recebe credenciais AWS que podem gerenciar interpretadores de código do bedrock agentcore. Sua tarefa é aproveitar isso para obter acesso a dados confidenciais usados por outros agentes de runtime do agentcore. Descubra como acessar a flag armazenada em uma knowledgebase do bedrock.

> **Nota:** Este cenário pode exigir que você crie alguns recursos AWS, e como o CloudGoat só pode gerenciar recursos que ele cria, você deve removê-los manualmente antes de executar `./cloudgoat destroy`.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/agentcore_identity_confusion/README.md)

Contribuído por Sonrai Security

---

### bedrock_agent_hijacking (Médio)
`cloudgoat create bedrock_agent_hijacking`

Neste cenário, você recebe credenciais AWS que podem invocar um Bedrock Agent e atualizar funções lambda. Sua tarefa é analisar o agente e entender como ele acessa informações em tempo real. Explore esse fluxo para localizar e extrair a flag armazenada no S3.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/bedrock_agent_hijacking/README.md)

Contribuído por Sonrai Security

</details>

<details>
  <summary><strong>Difícil</strong></summary>

### rce_web_app (Difícil)
`cloudgoat create rce_web_app`

Começando como o usuário IAM Lara, o atacante explora um Load Balancer e um bucket S3 em busca de pistas sobre vulnerabilidades, levando a uma exploração RCE em uma aplicação web vulnerável que expõe arquivos confidenciais e culmina no acesso ao objetivo do cenário: uma instância de banco de dados RDS altamente protegida.

Alternativamente, o atacante pode começar como o usuário IAM McDuck e enumerar buckets S3, eventualmente levando a chaves SSH que concedem acesso direto ao servidor EC2 e ao banco de dados além.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/rce_web_app/README.md)

---

### codebuild_secrets (Difícil)
`cloudgoat create codebuild_secrets`

Começando como o usuário IAM Solo, o atacante primeiro enumera e explora projetos CodeBuild, encontrando chaves IAM inseguras do usuário IAM Calrissian neles. Operando então como Calrissian, o atacante descobre um banco de dados RDS. Sem conseguir acessar o conteúdo do banco de dados diretamente, o atacante pode fazer uso inteligente da funcionalidade de snapshot do RDS para adquirir o objetivo do cenário: um par de strings secretas.

Alternativamente, o atacante pode explorar parâmetros SSM e encontrar chaves SSH para uma instância EC2. Usando o serviço de metadados, o atacante pode adquirir as chaves do perfil de instância EC2 e avançar mais profundamente no ambiente alvo, eventualmente ganhando acesso ao banco de dados original e ao objetivo do cenário (um par de strings secretas) por uma rota mais indireta.

> **Nota:** Este cenário pode exigir que você crie alguns recursos AWS, e como o CloudGoat só pode gerenciar recursos que ele cria, você deve removê-los manualmente antes de executar `./cloudgoat destroy`.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/codebuild_secrets/README.md)

---

### detection_evasion (Difícil)
`cloudgoat create detection_evasion`

O objetivo deste cenário é ler os valores de ambos os segredos sem ser detectado. Os segredos estão armazenados no Secrets Manager, e seus valores têm o seguinte formato (cg-secret-XXXXXX-XXXXXX).

Este cenário é significativamente diferente dos outros cenários do CloudGoat. Em detection_evasion, seus objetivos serão delineados com mais clareza, e o desafio é completá-los sem disparar alarmes. Há mais preparação envolvida neste cenário, e levará mais tempo para jogar (talvez você queira/precise jogá-lo várias vezes).

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/detection_evasion/README.md)

---

### ecs_efs_attack (Difícil)
`cloudgoat create ecs_efs_attack`

Começando com acesso ao EC2 "ruse", o usuário aproveita o perfil de instância para backdoor no contêiner ECS em execução. Usando o contêiner backdoorado, o atacante pode recuperar credenciais da API de metadados do contêiner. Essas credenciais permitem que o atacante inicie uma sessão em qualquer EC2 com as tags adequadas definidas. O atacante usa suas permissões para alterar as tags no Admin EC2 e inicia uma sessão. Uma vez no Admin EC2, o atacante fará um port scan na sub-rede em busca de um EFS aberto para montar. Uma vez montado, o atacante pode recuperar a flag do sistema de arquivos elástico.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_efs_attack/README.md)

---

### ecs_privesc_evade_protection (Médio)
`cloudgoat create ecs_privesc_evade_protection`

Um usuário começa acessando um serviço web funcional para um contêiner dentro do EC2. O atacante pode explorar uma vulnerabilidade do serviço web para obter credenciais da API de metadados no EC2, ou para controlar o contêiner. Essa credencial permite que o atacante inicie um novo contêiner com uma função específica e o controle. Com base nessa ação, faça uma escalada de privilégios e leia a FLAG no S3.

> **Nota:** Este cenário requer que o Docker esteja instalado localmente, pois ele constrói e envia uma imagem de contêiner para o ECR durante a implantação.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/ecs_privesc_evade_protection/README.md)

---

### secrets_in_the_cloud (Difícil)
`cloudgoat create secrets_in_the_cloud`

Como um usuário IAM com privilégios limitados, o atacante inicia sua jornada examinando recursos AWS para descobrir pistas e informações ocultas. Essa investigação resulta, em última análise, na aquisição de uma função que concede acesso ao objetivo principal do cenário: recuperar o segredo final do Secrets Manager.

[Visite a Página do Cenário.](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/cloudgoat/scenarios/aws/secrets_in_the_cloud/README.md)
  
</details>



## Guia de Uso

A anatomia básica de um comando CloudGoat é a seguinte:

> `cloudgoat [ comando ] [ sub-comando ] [ --nome-do-argumento ] [ valor-do-argumento ]`

Os cinco comandos principais no CloudGoat são resumidos abaixo:

### create

`create [ nome-do-cenário ]` implanta um cenário na conta AWS de sua escolha. Você também pode executar `create` em um cenário existente, se desejar - o CloudGoat simplesmente destruirá e recriará o cenário nomeado.

> **Dica:** você pode usar `/scenarios` no nome, o que permite a conclusão por tabulação nativa do bash.

Observe que o `--profile` é necessário por razões de segurança - não queremos que ninguém implante acidentalmente cenários CloudGoat em um ambiente de produção - e o CloudGoat não usará os perfis "default" do AWS CLI do sistema nem perfis especificados como padrão por meio de variáveis de ambiente. Você pode, no entanto, definir isso via `config aws` para evitar ter que fornecê-lo toda vez.

### list

`list` mostra algumas informações sobre cenários `all` (todos), `undeployed` (não implantados) ou `deployed` (implantados), ou até mesmo muitas informações sobre um `[ nome-do-cenário ]` já implantado. Você também pode filtrar cenários por plataforma de nuvem: `list aws` ou `list azure`.

### destroy

`destroy` desliga e exclui os recursos de nuvem de um `[ nome-do-cenário ]` e, em seguida, move a pasta da instância do cenário para `./trash` - caso você precise recuperar o arquivo de estado do Terraform ou outros arquivos do cenário. Você também pode especificar `all` em vez de um nome de cenário para destruir todos os cenários ativos.

> **Dica:** O CloudGoat só pode gerenciar recursos que ele cria. Se você criar recursos por conta própria durante um cenário, remova-os manualmente antes de executar o comando `destroy`.

### config

`config` permite gerenciar vários aspectos da sua instalação CloudGoat, especialmente a `whitelist` de IP, seu `profile` AWS padrão e a conclusão por tabulação via `argcomplete`. Vale a pena descrever brevemente o que cada um desses subcomandos faz.

#### whitelist

O CloudGoat precisa saber quais endereços IP devem ser colocados na lista de permissões quando recursos potencialmente vulneráveis são implantados na nuvem, e esses IPs são rastreados em um arquivo `./whitelist.txt` no diretório base do projeto. O endereço IP que você fornece para a lista de permissões não _precisa_ estar no formato CIDR, mas o CloudGoat adicionará um `/32` a qualquer IP simples que você fornecer. Opcionalmente, você pode adicionar o argumento `--auto`, e o CloudGoat fará automaticamente uma solicitação de rede, usando curl para ifconfig.co para encontrar seu endereço IP e, em seguida, criará o arquivo de lista de permissões com o resultado.

#### aws

Embora o CloudGoat nunca use os perfis "default" do AWS CLI do sistema nem perfis especificados como padrão por meio de variáveis de ambiente, você pode instruir o CloudGoat a usar um perfil AWS específico pelo nome usando o comando `config aws`. Isso solicitará e salvará o nome do seu perfil em um arquivo `config.yml` no diretório base do projeto. Enquanto esse arquivo estiver presente, o CloudGoat usará o nome do perfil listado para comandos create e destroy, em vez de exigir a flag `--profile`. Você pode executar o comando `config aws` a qualquer momento para visualizar o nome do seu perfil padrão do CloudGoat e validar o formato do `config.yml`. Você também pode criar `config.yml` manualmente, se desejar, desde que use o formato correto.

#### azure

Versões mais recentes do provedor Azure para Terraform exigem o ID da assinatura para aplicar recursos. Embora o CloudGoat use a mesma configuração de credenciais que o utilitário `az`, o CloudGoat deve ser informado explicitamente em qual assinatura implantar. A configuração é feita com `cloudgoat config azure`, e a assinatura é armazenada em `config.yml` junto com a configuração aws. Você também pode criar `config.yml` manualmente, se desejar, desde que use o formato correto.

#### argcomplete

Nós realmente queríamos ter conclusão por tabulação nativa no CloudGoat, mas descobrimos que isso era um tanto difícil de fazer fora de um REPL. Deve funcionar razoavelmente bem para usuários Linux e para aqueles usuários de OSX corajosos o suficiente para encontrar uma maneira de atualizar sua versão do bash para 4.2+. O CloudGoat inclui e suporta [a biblioteca Python "argcomplete"](https://github.com/kislyuk/argcomplete). Um breve resumo de como instalar o argcomplete é fornecido abaixo, embora para etapas mais detalhadas você deva consultar a documentação oficial na [página do github](https://github.com/kislyuk/argcomplete) da biblioteca.

1. Instale o pacote Python argcomplete usando o arquivo requirements.txt do CloudGoat: `$ pip3 install -r core/python/requirements.txt`
2. No bash, execute o script de conclusão de argumentos Python global fornecido pelo pacote argcomplete: `$ activate-global-python-argcomplete`
3. Importe o script de conclusão no local impresso pelo comando de ativação anterior, ou reinicie sua sessão do shell: `$ source [ /caminho/para/o/script/de/conclusão ]`

Para aqueles que não podem ou não desejam configurar o argcomplete, o CloudGoat também suporta o uso de caminhos de diretório como nomes de cenários, o que significa que a conclusão por tabulação funcionará para nomes de cenários. Basta usar `/scenario/[ nome-do-cenário ]` ou `./[ nome-da-instância-do-cenário ]` e seu shell deve fazer o resto.

### help

`help` fornece ajuda contextual sobre comandos. `help` pode vir antes ou depois do comando em questão, então está sempre lá quando você precisa. Abaixo estão alguns exemplos:* `cloudgoat create help`
* `cloudgoat destroy help`
* `cloudgoat list help`
* `cloudgoat config help`

Outro uso digno de nota: `cloudgoat [ nome-do-cenário ] help` pode ser usado para imprimir no console um breve resumo do cenário, conforme definido pelo autor do cenário.

## Solicitações de Funcionalidades e Relatórios de Bugs

Se você tiver uma solicitação de funcionalidade ou um bug para relatar, por favor [submeta-os aqui](https://github.com/RhinoSecurityLabs/cloudgoat/issues/new).

Para bugs, certifique-se de incluir uma descrição suficiente para reproduzir o bug encontrado, incluindo rastreamentos de erro e etapas de reprodução, e verifique se já existem outros relatos do seu bug antes de abrir um novo relatório.

Para funcionalidades, aplica-se o mesmo! Seja específico em sua solicitação e certifique-se de que ninguém mais já solicitou a mesma funcionalidade.

## Diretrizes de Contribuição

Contribuições para o CloudGoat são muito apreciadas. Se você gostaria de ajudar a melhorar o projeto, continue lendo.

1. **Criando um Novo Cenário**:
   - Fornecemos um modelo de cenário para ajudá-lo a começar rapidamente. O modelo inclui a estrutura básica e os arquivos necessários para um cenário do CloudGoat. Você pode encontrar o modelo de cenário [aqui](https://github.com/rhinosecuritylabs/cloudgoat/blob/HEAD/scenarios/scenario_template).
   - **Passos para Criar um Novo Cenário**:
     - **Copiar o Modelo**: Copie o conteúdo do modelo de cenário para um novo diretório com o nome do seu cenário.
     - **Modificar o Modelo**: Substitua o conteúdo de espaço reservado no modelo pelos detalhes do seu novo cenário.
     - **Testar o Cenário**: Certifique-se de que seu cenário funcione conforme o esperado testando-o minuciosamente.
2. **Padrões de Codificação**:
   - **Estilo de Código**: Siga o estilo de código existente no projeto. Consistência é fundamental.
   - **Comentários**: Adicione comentários ao seu código quando necessário para explicar lógica complexa ou decisões importantes.
   - **Documentação**: Atualize o README.md e outras documentações relevantes para incluir detalhes sobre seu novo cenário ou alterações.
3. **Lista de Permissões**:
   - Ao criar ou modificar cenários, tenha em mente o seguinte:
     - **Lista de Permissões**: Certifique-se de que as regras do grupo de segurança e outros controles de acesso estejam configurados para permitir apenas o IP da configuração do CloudGoat.
     - **Revisão**: Verifique duas vezes suas configurações quanto a recursos públicos potencialmente vulneráveis antes de contribuir (ou seja, não crie EC2s vulneráveis acessíveis à internet).
4. **Estilo de Código Python**:
   - O código Python no CloudGoat deve geralmente seguir as convenções de estilo do Python, favorecendo legibilidade e manutenibilidade acima de tudo.
   - Siga boas práticas de git: use pull requests, prefira branches de funcionalidades, sempre escreva mensagens de commit claras.
   - O CloudGoat usa `black` e `flake8` - linters de sintaxe e estilo Python. Certifique-se de que tanto `flake8` quanto `black` sejam executados em todos os arquivos Python em `core/python/` e em `cloudgoat.py` antes de commitar código. As decisões do `black` têm prioridade sobre as do `flake8`. Ambos estão comentados no arquivo `core/python/requirements.txt` já que usuários normais não precisam deles.
5. **Licenciamento**:
   - O código do CloudGoat deve sempre usar a licença BSD de 3 cláusulas.

E por último, obrigado por contribuir!

## Histórico de Alterações

- **6/24/19:** CloudGoat 2.0 foi lançado!

## Aviso Legal

CloudGoat é um software que não oferece absolutamente nenhuma garantia. Ao usar o CloudGoat, você assume total responsabilidade por todos e quaisquer resultados que decorrerem.