hacktricks/pentesting/pentesting-kubernetes/pentesting-kubernetes-from-the-outside.md

# 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

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

#### Insecure API server

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

#### Secure API Server

```text
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

```text
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

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

#### kubelet \(Read only\)

```text
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:

```text
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" %}