GCP - Containers & GKE Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
In GCP containers you can find most of the containers based services GCP offers, here you can see how to enumerate the most common ones:
In the following page you can check how to abuse container permissions to escalate privileges:
GCP - Container PrivescThese are the pool of machines (nodes) that form the kubernetes clusters.
For information about what is Kubernetes check this page:
Kubernetes PentestingFirst, you can check to see if any Kubernetes clusters exist in your project.
If you do have a cluster, you can have gcloud automatically configure your ~/.kube/config file. This file is used to authenticate you when you use kubectl, the native CLI for interacting with K8s clusters. Try this command.
Then, take a look at the ~/.kube/config file to see the generated credentials. This file will be used to automatically refresh access tokens based on the same identity that your active gcloud session is using. This of course requires the correct permissions in place.
Once this is set up, you can try the following command to get the cluster configuration.
You can read more about gcloud for containers here.
This is a simple script to enumerate kubernetes in GCP: https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum
Initially this privilege escalation technique allowed to privesc inside the GKE cluster effectively allowing an attacker to fully compromise it.
This is because GKE provides TLS Bootstrap credentials in the metadata, which is accessible by anyone by just compromising a pod.
The technique used is explained in the following posts:
Ans this tool was created to automate the process: https://github.com/4ARMED/kubeletmein
However, the technique abused the fact that with the metadata credentials it was possible to generate a CSR (Certificate Signing Request) for a new node, which was automatically approved. In my test I checked that those requests aren't automatically approved anymore, so I'm not sure if this technique is still valid.
In this post it was discovered it was discovered a Kubelet API address accesible from inside a pod in GKE giving the details of the pods running:
Even if the API doesn't allow to modify resources, it could be possible to find sensitive information in the response. The endpoint /pods was found using Kiterunner.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
