Welcome to Kubernetes Goat. This is the home for exploring your
Kubernetes Goat scenarios, discovery, exploitation, attacks, endpoints, etc.
Guide
Refer to the Kubernetes Goat
guide at https://madhuakula.com/kubernetes-goat/
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. Let's see if we can find something cool here!
Scenario
To get started with the
scenario, navigate to http://127.0.0.1:1230
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, we try to
exploit and gain access to host system.
Scenario
To get started with the
scenario, navigate to http://127.0.0.1:1231
SSRF in
K8S world
SSRF (Server Side Request Forgery) vulnerability became the go-to attack for cloud native
environments. Here in this scenario, we will see how we can exploit an application
vulnerability like SSRF to gain access to cloud instance metadata as well as internal
services metdata information.
Scenario
To get started with the
scenario, navigate to http://127.0.0.1:1232
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, we will see a pod with extra capabilities and
privileges including HostPath allows us to gain access to host system and provide Node level
configuration to gain complete cluster compromise.
Scenario
To get started with the
scenario, navigate to http://127.0.0.1:1233
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.
To get started with this scenario you can either access the node and perform by following
docker bench security or run the following command to deploy docker bench security as a
DaemonSet
Scenario
kubectl apply -f
scenarios/docker-bench-security/deployment.yaml
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.
To get started with this scenario you can either access the node and perform by following
kube-bench security or run the following command to deploy kube-bench as Kubernetes job
Scenario
kubectl apply -f
scenarios/kube-bench-security/node-job.yaml
kubectl apply -f
scenarios/kube-bench-security/master-job.yaml
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. Let's see what
we can find here.
Scenario
To get started with the
scenario, navigate to http://127.0.0.1:1235
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.
To get started with the scenario, run the following command and look for open ports in the
Kubernetes Nodes
Scenario
kubectl get nodes -o wide
When Kubernetes creates a NodePort service, it allocates a port from a range specified in
the flags that define your Kubernetes cluster. (By default, these are ports ranging from
30000-32767.)
Helm v2
tiller to PwN the cluster
Helm is a package manager for Kubernetes. It's like apt-get for ubuntu. In this scenario, we
will see the older version of helm (version 2), tiller service RBAC default setup to gain
access to the completed cluster.
To get started with the scenario, run the following command
Scenario
kubectl run --rm
--restart=Never -it --image=madhuakula/k8s-goat-helm-tiller -- bash
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, we will
analyse and identify the crypto miner.
To get started, identify all the resources/images in the Kubernetes cluster. Including
Kubernetes Jobs
Scenario
kubectl get jobs
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.
We heard that Kubernetes-Goat loves cache. Let's see if we can gain access to other
namespaces
To get started with the scenario, let's run our awesome hacker-container in default namespace
Scenario
kubectl run -it
hacker-container --image=madhuakula/hacker-container -- sh
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. So let's go ahead and find
the vault key!
Scenario
To get started with the
scenario, navigate to http://127.0.0.1:1233
DoS the
memory/cpu resources
Whe 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.
Scenario
To get started with the
scenario, navigate to http://127.0.0.1:1236
Hacker
Container preview
This scenario, is just an exploration of the common security utilities inside the Kubernetes
Cluster environment. I think by this time you might have already used hacker-container
multiple times.
To get started with this scenario. Run the hacker container using the below command
Scenario
kubectl run -it
hacker-container --image=madhuakula/hacker-container -- sh
Hidden in
layers
Sensitive information disclosure is one of the most common vulnerability existing in the
wild. Mishandling of passwords, private keys, tokens, etc in containerization world is easy.
Here in this scenario, we will analyze and identify one of such mishandled bad practice that
leads to sensitive information disclosure.
To get started, identify all the resources/images in the Kubernetes cluster. Including
Kubernetes Jobs
Scenario
kubectl get jobs
RBAC
Least Privileges Misconfiguration
We commonly see in real-world where developers and devops teams tend to provide extra
privileges than required. This happens attackers gaining more control and privieges than
they intended to be. In this scenario you can leverage the serviceaccount binded to the pod
to provide webhookapikey access, but using this attacker can gain control over other
secrets and resources. Gain access to the vaultapikey secret flag.
Scenario
To get started with the
scenario, navigate to http://127.0.0.1:1236
KubeAudit
- Audit Kubernetes Clusters
This scenario is mainly to perform the audit of Kubernetes Cluster for various different
security concerns.
To get started with this scenario you can run the following command to start the
hacker-container with cluster administrator privileges (as tiller service account already has
that)
Scenario
kubectl run -n kube-system
--serviceaccount=tiller --rm --restart=Never -it --image=madhuakula/hacker-container --
bash
Sysdig
Falco - Runtime Security Monitoring & Detection
This scenario is deploy runtime security monitoring & detection for containers and
kubernetes resources.
To get started with this scenario you can deploy the below helm chart with version 3
Scenario
helm repo add falcosecurity
https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco
Popeye -
A Kubernetes Cluster Sanitizer
This scenario is mainly to perform the review of Kubernetes Cluster by scanning the live
Kubernetes cluster and reports potential issues with deployed resources and configurations.
To get started with this scenario you can run the following command to start the
hacker-container with cluster administrator privileges (as tiller service account already has
that)
Scenario
kubectl run -n kube-system
--serviceaccount=tiller --rm --restart=Never -it --image=madhuakula/hacker-container --
bash
Secure
network boundaries using NSP
This scenario is deploy a simple network security policy for kubernetes resources to create
security boundaries.
To get started with this scenario ensure you must be using a networking solution which supports
NetworkPolicy
Scenario
To get started with the
scenario, refer to the Guide.