Kubernetes Goat: an intentionally vulnerable cluster for practising Kubernetes security

Who Kubernetes Goat is for, and the problem it removes

Reading about a container escape is not the same as performing one. Most Kubernetes security material gives you a concept and a diagram. Kubernetes Goat gives you a cluster where the misconfiguration already exists, so you can spend your time on the attack path instead of on building a target. That is the specific problem it solves: there is no safe, reproducible place to practise Kubernetes attacks against a real API server, real pods and real RBAC bindings.

The audience is narrow and worth stating plainly. It suits security engineers preparing for red team work in cloud-native environments, DevSecOps practitioners who want to see what a runtime detection tool actually catches, and platform engineers who have read the CIS benchmark but never watched a privileged pod walk out to the node. The README describes it as an intentionally vulnerable cluster environment to learn and practise Kubernetes security, and the repository topics list redteam, blueteam, devsecops and container-security together, which reflects the intended range: the scenarios include both offensive paths and tools like Falco, KubeAudit and Popeye that are used from the defensive side.

It is not a course. There is no grading, no progress tracking and no explanation embedded in the cluster itself. The repository README lists the 22 scenarios by name and points to madhuakula.com/kubernetes-goat for the guide. If you want a structured curriculum with explanations attached to each step, the value is in that external guide, not in the manifests.

How the vulnerable environment is assembled

The repository is organised around scripts rather than a single Helm chart you install by hand. The top level holds setup-kubernetes-goat.sh and its PowerShell counterpart, access-kubernetes-goat.sh and its PowerShell counterpart, and teardown-kubernetes-goat.sh plus a PowerShell version. There are also infrastructure/, scenarios/, platforms/ and guide/ directories. The naming suggests a split between the cluster-level plumbing, the individual scenario workloads, environment-specific configuration, and the written material, though the README does not document what each directory contains.

The setup script is the entry point, and the README requires Helm to be present before it runs. That tells you the scenario workloads are packaged as Helm releases rather than applied as loose manifests, which matters for teardown: removing the releases is a cleaner operation than deleting a pile of objects by label. The README does not document what the setup script does internally, whether it creates a namespace, or how it names the releases, so treat the script as the interface and read it before running it if you need to know exactly what lands in your cluster.

Access is deliberately separated from setup. Once the pods are running, access-kubernetes-goat.sh sets up port forwarding so the playground is reachable at http://127.0.0.1:1234. That two-step design is a reasonable choice: the cluster can sit idle without an open tunnel, and you can re-establish access without reinstalling anything. The cost is that you need to remember which step you are on when something does not load.

The platforms/ directory and the README's pointer to the how-to-run documentation indicate that the project supports more than one environment, with GKE, EKS, AKS, K3S and KIND named explicitly. That range is useful, but it also means the setup script has to detect or assume a context. The README does not state how it selects a cluster, so if your kubeconfig points at more than one context, verify the current context before running anything.

Installing Kubernetes Goat and reaching the first scenario

The README gives a four-command sequence for a cluster you already have admin access to. It assumes kubectl and helm are installed and that you are pointed at the right cluster. The clone, the chmod and the script run are the whole setup.

git clone https://github.com/madhuakula/kubernetes-goat.git
cd kubernetes-goat
chmod +x setup-kubernetes-goat.sh
bash setup-kubernetes-goat.sh

The README explicitly says to make sure the pods are running before you run the access script. That is not decoration: the port-forward step will fail or produce a dead page if the workloads have not scheduled yet, and a first-time user is likely to blame the access script rather than the cluster.

kubectl get pods

What you should see is the scenario pods in a running state. The README includes a screenshot of this output at guide/docs/scenarios/images/kubectl-get-pods.png, which is the reference for what a healthy result looks like. If pods are stuck pending, the usual causes are insufficient node resources or an image that cannot be pulled, and the README does not cover either case.

Once the pods are up, the access script opens the tunnel and you browse to the address it prints.

bash access-kubernetes-goat.sh

Navigate to http://127.0.0.1:1234 and the playground index appears. From there you pick a scenario and follow the corresponding page in the documentation guide. The first scenario in the list, sensitive keys in codebases, is a reasonable starting point because it does not require cluster-level privileges to understand. The later scenarios, particularly container escape to the host system and the RBAC least privileges misconfiguration, are where the environment earns its keep.

What the 22 scenarios actually cover

The scenario list reads as a tour of the ways Kubernetes deployments go wrong. It opens with secrets committed to source, moves through docker-in-docker exploitation, SSRF against the Kubernetes API, container escape to the host, and private registry attacks. Then it shifts toward assessment and defence: Docker and Kubernetes CIS benchmark analysis, KubeAudit, Falco for runtime detection, Popeye as a cluster sanitiser, network policy boundaries, Cilium Tetragon for eBPF-based observability and enforcement, and Kyverno for policy.

That mix is the most interesting design decision in the project. A pure attack range would stop at scenario 14. By including Falco, Tetragon, KubeAudit and Popeye, Kubernetes Goat positions itself as a place to watch a detection fire while you are the one generating the activity. If you are evaluating a runtime security tool, being able to trigger the exact behaviour it claims to catch, in a cluster you control, is more informative than reading its rule list.

Two entries deserve a caveat. Scenario 9, Helm v2 tiller to PwN the cluster, is marked Deprecated in the README, which is consistent with Helm 2 being long out of use; do not expect it to work against a current cluster. Scenario 13, DoS the Memory/CPU resources, is a resource exhaustion exercise, and on a shared or metered cluster that is exactly the kind of scenario that can take down neighbouring workloads or run up a cloud bill. The README's disclaimer covers the general risk, but it does not single out this scenario.

Several scenarios depend on cluster-level access or on the specific platform you deployed to. NodePort exposed services behaves differently depending on whether your cluster has a load balancer controller, and the cloud-specific paths for EKS, AKS and GKE will not map cleanly onto a local KIND cluster. The README does not document per-scenario prerequisites, so expect to consult the guide page for each one before assuming it applies to your environment.

The isolation requirement is the real limitation

The README's disclaimer is unusually direct, and it is the single most important thing to understand about this project. Kubernetes Goat creates intentional vulnerabilities, and the README says not to run it alongside production environments and infrastructure, recommending a safe and isolated environment instead. It also states that the project comes with no warranties and that by using it you take full responsibility for the outcomes.

Take that literally. A cluster running these scenarios has privileged pods, weak RBAC, exposed services and a working container escape path. If your kubeconfig can reach a production cluster from the same shell, a mistake in context selection is all that stands between a training exercise and an incident. The same applies to cloud credentials: a scenario that attacks a private registry or abuses a node's instance profile is only as contained as the identity attached to that node.

The project is also the wrong tool for several legitimate goals. If you need to validate that your own manifests are secure, a policy engine or a scanner against your real manifests is the right approach; Kubernetes Goat tests your ability to exploit a known-bad cluster, not the security of your own. If you need a compliance artefact, CIS benchmark scenarios show you how to run an assessment, but they do not produce an audit report for your environment. And if you are looking for a managed, hosted lab with no setup, the README points to the guide for running it in various environments, all of which require you to bring the cluster.

There is a maintenance dimension too. The most recent release listed is v2.3.0 from 2024-09-03, and the last push to the repository was on 2026-04-16. That is recent enough that the project is not abandoned, but the gap between the last tagged release and the last push means the documentation and the code may not have moved together. Do not assume a scenario behaves exactly as the guide describes without checking.

How it compares with deliberately vulnerable applications

The closest comparison is a deliberately vulnerable web application in the style of OWASP Juice Shop or DVWA. Those give you a single application with injected flaws and a browser as the interface. Kubernetes Goat gives you an orchestration layer with injected flaws and kubectl as the interface. The attack surface is different in kind: instead of SQL injection and broken access control inside one process, you are working with pod security contexts, service accounts, network policies and the API server itself.

That difference determines which one you should reach for. If your team is learning application security, a vulnerable web app is the right target because the flaws live in application code. If your team is moving workloads onto Kubernetes and needs to understand what a compromised pod can reach, Kubernetes Goat is the better fit because the flaws live in the cluster configuration. The two are complementary rather than competing, and the repository topics list cloud-native and container-security alongside owasp, which fits that framing.

A second alternative is a cloud-specific vulnerable environment. The search results around this project include EKS Goat and OWASP EKS Goat, which suggests demand for the same idea applied to a specific managed platform. Kubernetes Goat's own platforms/ directory and its how-to-run documentation cover GKE, EKS, AKS, K3S and KIND, so it partially serves that need, but a platform-specific environment will generally model that platform's identity and networking primitives more faithfully. If your job is defending EKS specifically, check whether a dedicated EKS-focused range covers ground this one does not.

Finally, there is the option of building your own broken cluster. That is more work and rarely reproducible across a team, which is precisely the gap a maintained scenario collection fills.

Licence, teardown and the cost of keeping it around

Kubernetes Goat is MIT licensed. In practice that means you can run it, modify the manifests, and use it in internal training without a licensing conversation. The MIT terms also mean the project ships with no warranty, which lines up with the README's own disclaimer. None of this is legal advice, and if you plan to redistribute modified scenario content, read the LICENSE file at the repository root rather than relying on the badge in the README.

The upgrade story is thin. The README documents setup but does not document an in-place upgrade path, and it does not describe rollback. The repository does ship teardown-kubernetes-goat.sh and teardown-kubernetes-goat.ps1, so the practical pattern is to tear down and set up again rather than to upgrade a running installation. That is acceptable for a training environment and would not be acceptable for anything holding state.

Running costs are whatever your cluster costs, plus the time to rebuild it. If you deploy to a managed cluster, the scenarios that exhaust memory and CPU or expose NodePort services will consume real resources, and the README's warning about isolation applies to your billing account as much as to your network. A local KIND or K3S cluster avoids the bill but limits which scenarios behave realistically. Whichever you choose, decide the teardown point before you start, because an intentionally vulnerable cluster left running is a standing liability rather than a paused exercise.

Editorial conclusion

Adopt Kubernetes Goat if you learn by breaking things and you have a disposable cluster, a local KIND or K3S instance, or a sandbox cloud account you can delete afterwards. Do not run it on a cluster that shares a network or cloud credentials with anything you care about, and do not treat the scenario list as a security control checklist for production. Before you start, confirm three things: that you have admin rights and both kubectl and helm available, that the setup script is executable, and that you have a teardown path, since the repository ships teardown-kubernetes-goat.sh alongside the setup script. The guide at madhuakula.com/kubernetes-goat is where the actual scenario walkthroughs live; the repository README only lists their names.

Frequently asked questions

Official sources

1. License: MIT
2. madhuakula/kubernetes-goat on GitHub
3. Project website
4. README
5. Releases