# CloudGoat: a Vulnerable-by-Design AWS and Azure lab generator for pentest practice > CloudGoat deploys deliberately vulnerable cloud scenarios you can attack and then tear down. It is a training tool, not a scanner, and the README is explicit that it must never touch a production account. **RhinoSecurityLabs/cloudgoat** — CloudGoat is Rhino Security Labs' "Vulnerable by Design" AWS deployment tool - Repository: https://github.com/RhinoSecurityLabs/cloudgoat - Stars: 3,741 · Forks: 773 - Language: Python - License: BSD-3-Clause - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/rhinosecuritylabs-cloudgoat ## What CloudGoat actually deploys, and who it is for CloudGoat is described in its README as Rhino Security Labs' "Vulnerable by Design" cloud deployment tool. The mechanism is straightforward: it provisions cloud resources into your own account so that you can attack them. Each unit of work is a scenario, and each scenario is a set of cloud resources arranged to produce a structured exercise. Some are easy, some are hard, and the README notes that many offer multiple paths to victory. Your job as the attacker is to explore the environment, find the weaknesses, and reach the scenario's goal. The audience is narrow and worth stating plainly. This is for people who already have cloud fundamentals and want hands-on offensive practice against realistic misconfigurations, and for trainers who need a lab they can stand up and tear down per student. It is not a teaching tool for someone who has never used IAM. The scenarios assume you can read a policy, follow a role chain, and reason about what a credential lets you do. The README lists four design goals: focused curated learning experiences, good documentation, easy installation, and modularity. The modularity claim is the one with teeth. Each scenario is a standalone environment with its own goal, and CloudGoat can start, reset, or shut down each scenario independently. That matters more than it sounds, because it means a failed attempt does not force you to rebuild everything you were working on. ## How scenarios are built: Python CLI over Terraform The repository layout tells you most of the architecture. There is a cloudgoat/ Python package, a pyproject.toml built with Poetry, and a declared entry point of cloudgoat.cloudgoat:main, so the installed console script is cloudgoat. Terraform is not vendored; it is a requirement that must be on your PATH, which means the actual resource creation is delegated to Terraform modules that ship with the scenarios rather than to boto3 calls written by hand. The dependency list includes boto3, PyYAML, requests, sqlite-utils and argcomplete, which fits the shape of a CLI that reads scenario definitions, tracks state, and offers tab completion. That split has a practical consequence. CloudGoat owns the lifecycle and the bookkeeping; Terraform owns the resources. The README's second warning follows directly from it: CloudGoat can only manage resources it creates. If you add something yourself while a scenario is running, CloudGoat's destroy path has no record of it and you have to remove it manually. This is not a bug so much as the boundary of a state-tracked tool, and it is the single most common way people end up with orphaned cloud resources and a surprise bill. The CLI surface visible in the README is small: config, start, reset, destroy, and a scenario listing. Configuration is per provider. The README gives the AWS form, cloudgoat config aws, described as telling CloudGoat which AWS profile to use. An Azure configuration path also exists, and the requirements list includes the Azure CLI alongside the AWS CLI, so the tool covers both clouds even though the package description in pyproject.toml still says "A vulnerable AWS environment generator for Pentesters." That description is stale relative to the README's requirements section. ## Installing CloudGoat and running a first scenario The README's Quick Start assumes your machine already satisfies the requirements: Linux or macOS (Windows is not officially supported), Python 3.9 or later, Terraform 1.5.0 or later on your PATH, the AWS CLI on your PATH, the Azure CLI on your PATH, and jq. The README gives per-platform commands for the system packages. On Debian-derived Linux: ```bash sudo apt install terraform awscli azure-cli jq -y ``` On macOS the same set comes from Homebrew: ```bash brew install terraform awscli azure-cli jq ``` With those in place, CloudGoat itself installs as a Python application through pipx, which keeps it isolated from your other Python environments: ```bash pipx install cloudgoat ``` After installation the README recommends a short configuration step, on the grounds that it saves time later. For AWS you point CloudGoat at the profile it should use: ```bash cloudgoat config aws ``` Run that against a dedicated account, not your daily one. The README's first warning is unambiguous: CloudGoat creates intentionally vulnerable resources in your account, and you must not deploy it in a production environment or alongside sensitive resources. Once configured, the workflow is start a scenario, work it, then destroy it. The README states that start, reset and destroy operate per scenario, so a scenario you have finished can be torn down without disturbing another one you are still working through. If you create any resource by hand during the exercise, delete it before you run destroy. There is also a Dockerfile in the repository, based on python:3.12-alpine, which installs bash, curl, unzip, jq, a pinned Terraform 1.11.2 for the detected architecture, and a pinned awscli 1.38.11 before installing CloudGoat from the copied source. Its entrypoint is /bin/bash rather than the cloudgoat command, so it is a containerised working shell, not a one-shot runner. The README does not document it as the supported install path; the documented path is pipx. ## Where CloudGoat is the wrong tool The most important limitation is the one the README puts in a warning box: this deploys real, deliberately broken infrastructure into a real account. Every scenario is a live blast radius. If your AWS account is the same one that holds customer data, backups, or anything with a budget alarm attached, you are using the tool incorrectly, and no amount of care in the CLI makes that safe. The second limitation is state ownership. CloudGoat can only manage what it created. That is a hard edge, not a soft one. Manual changes made during a scenario, whether by you or by an attacker technique that creates new resources, survive destroy and must be cleaned up by hand. A tool that tracked resources by tag would be more forgiving; CloudGoat's documented behaviour is not that. Third, the platform support is genuinely restricted. Windows is not officially supported, and the README notes that argument tab-completion needs bash 4.2 or later, which it describes as available on Linux and achievable on macOS only with some difficulty. If your team is standardised on Windows workstations, this is not a tool you can hand out without a Linux VM or the container. Fourth, CloudGoat is not an assessment product. It does not scan your environment, does not report on your posture, and does not tell you whether your own cloud is misconfigured. Its scenarios are authored environments with a goal, and the skills you practise transfer, but the output of running it is your own learning, not a report. Anyone shopping for a cloud security scanner is looking at the wrong category of tool. ## CloudGoat compared with standing up your own Terraform lab The obvious alternative is writing your own Terraform for a vulnerable environment. That is what CloudGoat is underneath, and the difference is in what you get beyond the infrastructure. A hand-rolled lab gives you total control over the misconfiguration, which is useful when you are teaching one specific thing, such as a confused-deputy problem in a particular service. It also gives you the maintenance burden: you own the modules, the provider version churn, the state file, and the teardown logic, and you will re-learn all of it every time a provider release changes an argument. CloudGoat trades that control for a curated set with documented difficulty, multiple intended paths, and a CLI that starts, resets and destroys each scenario independently. If your goal is to build a scenario library for a specific organisation, hand-rolled Terraform is the better fit. If your goal is to get a working, varied lab in front of learners this week and tear it down afterwards, CloudGoat's scenario catalogue and lifecycle commands are the reason to use it. The other comparison worth drawing is against cloud provider sandboxes and free-tier accounts used as improvised labs. Those give you a real console and real services, but nothing is arranged to be exploitable, so the exercise becomes "find something interesting" with no defined goal and no reset button. CloudGoat's scenarios are explicitly arranged with a goal, and the reset command exists precisely because you will get a scenario into a broken intermediate state and want to try again from a known baseline. That reset capability is the practical dividing line between a lab and a sandbox. ## Maintenance, releases and the BSD-3-Clause licence The repository is not archived, and the last push was on 2026-04-28. The release history shows v2.5.0 on 2026-03-20, v2.4.0 on 2026-02-12, and v2.3.1 on 2025-09-18, so the cadence over the past year has been a couple of feature releases with a longer gap before them. The pyproject.toml version matches v2.5.0, and the Dockerfile labels cloudgoat.version as 2.5.0, so the packaged version and the release tag are in step. Upgrade cost is mostly about the Terraform floor. The README requires Terraform 1.5.0 or later, while the Dockerfile pins 1.11.2, which suggests the tested combination is newer than the documented minimum. If you run an older Terraform you are outside what the project appears to exercise. The Python floor is 3.9, and the dependency set pins boto3 to a range between 1.37.11 and 1.43.0, so a major boto3 release could require a CloudGoat update before your environment works again. Check that range when you plan an upgrade rather than assuming any boto3 will do. Licensing is BSD-3-Clause, per the repository metadata and the LICENSE file at the top level. That is a permissive licence, and it is the licence you would expect to see on a tool that ships deliberately vulnerable infrastructure: it lets you fork scenarios, adapt them internally, and redistribute with the copyright notice intact. It says nothing about the legal status of what you deploy, and it does not shift responsibility for the cloud resources you create in your own account. If you fork and publish scenarios, keep the notice; if you are considering bundling CloudGoat into a commercial training product, that is a question for your own counsel, not something this article can settle. ## Conclusion Adopt CloudGoat if you need repeatable, self-contained cloud attack practice and you can give it a dedicated AWS or Azure account, Python 3.9+, Terraform 1.5.0+ and the AWS CLI on Linux or macOS. Do not adopt it as a security scanner, a compliance checker, or anything you point at an account holding real data; the README's first warning is that it creates intentionally vulnerable resources and must not be deployed in production or alongside sensitive resources. Before your first scenario, verify that your Terraform and AWS CLI versions satisfy the documented minimums, that your chosen AWS profile is the throwaway one, and that you understand the second warning: anything you create by hand inside a scenario has to be deleted manually before you run destroy. ## FAQ ### What is Amazon's cloud platform called? The README does not address Amazon's cloud platform by name. It refers to AWS throughout and requires an AWS account with sufficient privileges to create and destroy resources, plus the AWS CLI on your PATH. ### Can AWS be trusted? The README does not make a claim about trusting AWS. It does warn that CloudGoat creates intentionally vulnerable resources in your account and must not be deployed in a production environment or alongside sensitive resources. ### What are the top 10 vulnerabilities in AWS? The README does not publish a ranked list of AWS vulnerabilities. It describes scenarios of varying difficulty that are arranged to be explored and exploited, and states that many offer multiple paths to victory. ### What cloud security tools are available on AWS? The README does not survey cloud security tools. It positions CloudGoat itself as a vulnerable-by-design deployment tool for building cloud cybersecurity skills through capture-the-flag style scenarios. ## Sources - [Issues](https://github.com/RhinoSecurityLabs/cloudgoat/issues) - [License: BSD-3-Clause](https://github.com/RhinoSecurityLabs/cloudgoat/blob/master/LICENSE) - [README](https://github.com/RhinoSecurityLabs/cloudgoat/blob/master/README.md) - [Releases](https://github.com/RhinoSecurityLabs/cloudgoat/releases) - [RhinoSecurityLabs/cloudgoat on GitHub](https://github.com/RhinoSecurityLabs/cloudgoat) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rhinosecuritylabs-cloudgoat