31 lines
1.8 KiB
Markdown
31 lines
1.8 KiB
Markdown
# Namespace Escalation
|
|
|
|
In Kubernetes it's pretty common that somehow **you manage to get inside a namespace** (by stealing some user credentials or by compromising a pod). However, usually you will be interested in **escalating to a different namespace as more interesting things can be found there**.
|
|
|
|
Here are some techniques you can try to escape to a different namespace:
|
|
|
|
### Abuse K8s privileges
|
|
|
|
Obviously if the account you have stolen have sensitive privileges over the namespace you can to escalate to, you can abuse actions like **creating pods** with service accounts in the NS, **executing** a shell in an already existent pod inside of the ns, or read the **secret** SA tokens.
|
|
|
|
For more info about which privileges you can abuse read:
|
|
|
|
{% content-ref url="abusing-roles-clusterroles-in-kubernetes/" %}
|
|
[abusing-roles-clusterroles-in-kubernetes](abusing-roles-clusterroles-in-kubernetes/)
|
|
{% endcontent-ref %}
|
|
|
|
### Escape to the node
|
|
|
|
If you can escape to the node either because you have compromised a pod and you can escape or because you ca create a privileged pod and escape you could do several things to steal other SAs tokens:
|
|
|
|
* Check for **SAs tokens mounted in other docker containers** running in the node
|
|
* Check for new **kubeconfig files in the node with extra permissions** given to the node
|
|
* If enabled (or enable it yourself) try to **create mirrored pods of other namespaces** as you might get access to those namespaces default token accounts (I haven't tested this yet)
|
|
|
|
All these techniques are explained in:
|
|
|
|
{% content-ref url="../../pentesting/pentesting-kubernetes/attacking-kubernetes-from-inside-a-pod.md" %}
|
|
[attacking-kubernetes-from-inside-a-pod.md](../../pentesting/pentesting-kubernetes/attacking-kubernetes-from-inside-a-pod.md)
|
|
{% endcontent-ref %}
|
|
|