Skip to main content

โŽˆ Kubernetes namespaces bypass

๐Ÿ™Œ Overviewโ€‹

Woah! this is a big misconception in the Kubernetes world. Most people assume that when there are different namespaces in Kubernetes and resources are deployed and managed they are secure and not able to access each other. Many real-world multi-tenant environments are getting exploited and critical resources are exposed internally due to this. By default, Kubernetes comes with flat networking schema and if we need to have segmentation then we have to create them by creating certain boundaries like NSP (network security policies) and others. In this scenario, we see how we can bypass the namespaces and access other namespaces resources.

By the end of the scenario, we will understand and learn the following

  1. You will understand the misconception of the Kubernetes namespaces
  2. Learn about the Kubernetes networking flat schema and communicating across namespaces
  3. Performing the reconnaissance and testing for the network port scanning and vulnerabilities
  4. Gaining access to other namespaces resources bypassing the namespaces restrictions

โšก๏ธ The storyโ€‹

By default, Kubernetes uses a flat networking schema, which means any pod/service within the cluster can talk to others. The namespaces within the cluster don't have any network security restrictions by default. Anyone in the namespace can talk to other namespaces. We heard that Kubernetes-Goat loves cache. Let's see if we gain access to other namespaces

  • To get started with the scenario, let's run our awesome hacker-container in the default namespace
kubectl run -it hacker-container --image=madhuakula/hacker-container -- sh

Scenario 11 Welcome

๐ŸŽฏ Goalโ€‹


Gain access to the cache-store and obtain the k8s_goat_flag flag value to complete this scenario.

๐Ÿช„ Hints & Spoilersโ€‹

โœจ Don't see other services?
Let's go back to the old school port scanning, but with zmap with entire cluster range for redis port ๐Ÿ™Œ
โœจ Found cache-store service?
Now it's time to read redis docs and get the SECRETSTUFF key ๐ŸŽ‰

๐ŸŽ‰ Solution & Walkthroughโ€‹

๐ŸŽฒ Method 1โ€‹

  • Let's run the hacker-container in the default namespace by using the following command to get started
kubectl run -it hacker-container --image=madhuakula/hacker-container -- sh

If you don't see the terminal TTY, just press Enter key on your keyboard.

  • First, we need to understand the cluster IP range information so that we can use the port scanners to scan the entire cluster range as we don't know which IP address these what services are running

  • Some of the simple commands to understand and get more information about the network are as below

ip route

Scenario 11 recon

  • Based on the analysis/understanding of the system. We can run the internal scan for the entire cluster range using zamp on port 6379 (the default port of Redis - assuming the cache service is Redis, but there is no limit for the testing here, in real-world we see a lot of internal services like ElasticSeach, Mongo, MySQL, etc.)
zmap -p 6379 -o results.csv

To run zmap on you may need adjust the blacklist (/etc/zmap/blacklist.conf) configuration

Scenario 11 zmap

  • Let's look at the results returned from the scan so that we can see if we can access them from the current pod and current namespace

Scenario 11 output ips


There is also another way to access the services/pods in the Kubernetes. For example using the DNS (servicename.namespace).

  • As we have identified the IP address of the service, now we can use the default redis using client reds-cli to talk to the service and explore
redis-cli -h
  • To get all the available keys
  • To get the specific key information using GET

Scenario 11 redis access


There are many other services and resources exposed within the cluster like ElasticSearch, Mongo, etc. So if your recon skill is good then you got a gold mine here.

  • Hooray ๐Ÿฅณ , now we can see that it contains Kubernetes Goat flag

๐Ÿ”– Referencesโ€‹