Kubernetes Goat – Vulnerable by Design Kubernetes Cluster

The Kubernetes Goat designed to be intentionally vulnerable cluster environment to learn and practice Kubernetes security. Kubernetes Goat creates intentionally vulnerable resources into your cluster. DO NOT deploy Kubernetes Goat in a production environment or alongside any sensitive cluster resources.

Kubernetes Goat - Vulnerable by Design Kubernetes Cluster
Kubernetes Goat – Vulnerable by Design Kubernetes Cluster

Some of the vulnerable scenario available are:

  1. Sensitive keys in code bases – Developers tend to commit sensitive information to version control systems. As we are moving towards CI/CD and GitOps systems, we tend to forgot identifying sensitive information in code and commits.
  2. DIND(docker-in-docker) exploitation – Most of the CI/CD and pipeline system which use Docker and build containers for you with in the pipeline use something called DIND (docker-in-docker). Here in this scenario user will try to exploit and gain access to host system.
  3. SSRF in K8S world – SSRF (Server Side Request Forgery) vulnerability became the go-to attack for cloud native environments. Here in this scenario, user will see how he can exploit an application vulnerability like SSRF to gain access to cloud instance metadata as well as internal services metdata information.
  4. Container escape to access host system – Most of the monitoring, tracing and debugging software require to run with extra privileges and capabilities. Here in this scenario, user will see a pod with extra capabilities and privileges including HostPath allows him to gain access to host system and provide Node level configuration to gain complete cluster compromise.
  5. Docker CIS Benchmarks analysis – This scenario is mainly to perform the Docker CIS benchmarks analysis on top of Kubernetes nodes to identify the possible security vulnerabilities.
  6. Kubernetes CIS Benchmarks analysis – This scenario is mainly to perform the Kubernetes CIS benchmarks analysis on top of Kubernetes nodes to identify the possible security vulnerabilities.
  7. Attacking private registry – Container registry is the place where all the container images gets pushed. Most of the time each organization have their own private registry. Also sometimes it ends up misconfigured, public/open. On the other hand, developers assumes that it’s internal private registry only and end up storing all the sensitive information inside the container images.
  8. NodePort exposed services – If any of the user has exposed any service with in the Kubernetes cluster with NodePort. This means, if the nodes where the Kubernetes clusters running doesn’t have any firewall/network security enabled. We ned seeing some unauthenticated an unauthorized services.
  9. Helm v2 tiller to PwN the cluster – Helm is a package manager for Kubernetes. It’s like apt-get for ubuntu. In this scenario, user will see the older version of helm (version 2), tiller service RBAC default setup to gain access to the completed cluster.
  10. Analysing crypto miner container – Crypto mining has became popular with these modern infrastructure. Especially environments like Kubernetes is easy target as you might not event look what exactly the container image built upon and what it is doing with proactive monitoring. Here in this scenario, user will analyse and identify the crypto miner.
  11. Kubernetes Namespaces bypass – By default Kubernetes uses flat networking schema, which means any pod/service with in the cluster can talk to other. The namespaces with in the cluster doesn’t have any network security restrictions by default. Anyone in the any namespace can talk to other namespace.
  12. Gaining environment information – Each environment in the Kubernetes will have lot of information to share. Some of the key things includes, secrets, apikeys, configs, services, many other.
  13. DoS the memory/cpu resources – Where there is no specification of resources in the Kubernetes manifests and not applied limit ranges for the containers. As an attacker we can consume all the resources where the pod/deployment running and starve other resources and cause a DoS for the environment.
  14. Hacker Container preview – This scenario, is just an exploration of the common security utilities inside the Kubernetes Cluster environment.

You can read more and use this framework over here: https://github.com/madhuakula/kubernetes-goat

Notify of
Inline Feedbacks
View all comments