# Pentesting Kubernetes from the outside

There different ways to find exposed **Kubernetes** Pods to the internet.

## Finding exposed pods with OSINT

One way could be searching for `Identity LIKE "k8s.%.com"` in [crt.sh](https://crt.sh/) to find subdomains related to kubernetes. Another way might be to search `"k8s.%.com"` in github and search for **YAML files** containing the string.

## Finding Exposed pods via port scanning

The following ports might be open in a Kubernetes cluster:

| Port       | Process        | Description                                                            |
| ---------- | -------------- | ---------------------------------------------------------------------- |
| 443/TCP    | kube-apiserver | Kubernetes API port                                                    |
| 2379/TCP   | etcd           |                                                                        |
| 6666/TCP   | etcd           | etcd                                                                   |
| 4194/TCP   | cAdvisor       | Container metrics                                                      |
| 6443/TCP   | kube-apiserver | Kubernetes API port                                                    |
| 8443/TCP   | kube-apiserver | Minikube API port                                                      |
| 8080/TCP   | kube-apiserver | Insecure API port                                                      |
| 10250/TCP  | kubelet        | HTTPS API which allows full mode access                                |
| 10255/TCP  | kubelet        | Unauthenticated read-only HTTP port: pods, running pods and node state |
| 10256/TCP  | kube-proxy     | Kube Proxy health check server                                         |
| 9099/TCP   | calico-felix   | Health check server for Calico                                         |
| 6782-4/TCP | weave          | Metrics and endpoints                                                  |

#### cAdvisor

```
curl -k https://<IP Address>:4194
```

#### Insecure API server

```
curl -k https://<IP Address>:8080
```

#### Secure API Server

```
curl -k https://<IP Address>:(8|6)443/swaggerapi
curl -k https://<IP Address>:(8|6)443/healthz
curl -k https://<IP Address>:(8|6)443/api/v1
```

#### etcd API

```
curl -k https://<IP address>:2379
curl -k https://<IP address>:2379/version
etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only
```

#### Kubelet API

```
curl -k https://<IP address>:10250
curl -k https://<IP address>:10250/metrics
curl -k https://<IP address>:10250/pods
```

#### kubelet (Read only)

```
curl -k https://<IP Address>:10255
http://<external-IP>:10255/pods
```

### Remote Cluster Misconfigurations

By **default**, API endpoints are **forbidden** to **anonymous** access. But it’s always a good idea to check if there are any **insecure endpoints that expose sensitive information**:

![](https://www.cyberark.com/wp-content/uploads/2019/09/Kube-Pen-2-fig-5.png)

### **Checking for ETCD Anonymous Access**

The ETCD stores the cluster secrets, configuration files and more **sensitive data**. By **default**, the ETCD **cannot** be accessed **anonymously**, but it always good to check.

If the ETCD can be accessed anonymously, you may need to use the [etcdctl](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md) tool. The following command will get all the keys stored:

```
etcdctl --ndpoints=http://<MASTER-IP>:2379 get / –prefix –keys-only
```

### **Checking Kubelet (Read Only Port) Information Exposure**

When the “kubelet” read-only port is exposed, the attacker can retrieve information from the API. This exposes **cluster configuration elements, such as pods names, location of internal files and other configurations**. This is not critical information, but it still should not be exposed to the internet.

For example, a remote attacker can abuse this by accessing the following URL: `http://<external-IP>:10255/pods`

![](https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-6.png)

## References

{% embed url="<https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-2>" %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://chinnidiwakar.gitbook.io/githubimport/pentesting/pentesting-kubernetes/pentesting-kubernetes-from-the-outside.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.