# GCP - Conteneurs & GKE Enum

{{#include ../../../banners/hacktricks-training.md}}

## Conteneurs

Dans les conteneurs GCP, vous pouvez trouver la plupart des services basés sur des conteneurs que GCP propose, ici vous pouvez voir comment énumérer les plus courants :
```bash
gcloud container images list
gcloud container images list --repository us.gcr.io/<project-name> #Search in other subdomains repositories
gcloud container images describe <name>
gcloud container subnets list-usable
gcloud container clusters list
gcloud container clusters describe <name>
gcloud container clusters get-credentials [NAME]

# Run a container locally
docker run --rm -ti gcr.io/<project-name>/secret:v1 sh

# Login & Download
sudo docker login -u oauth2accesstoken -p $(gcloud auth print-access-token) https://HOSTNAME
## where HOSTNAME is gcr.io, us.gcr.io, eu.gcr.io, or asia.gcr.io.
sudo docker pull HOSTNAME/<project-name>/<image-name>
```
### Privesc

Dans la page suivante, vous pouvez vérifier comment **abuser des permissions des conteneurs pour élever les privilèges** :

{{#ref}}
../gcp-privilege-escalation/gcp-container-privesc.md
{{#endref}}

## Node Pools

Ce sont les pools de machines (nœuds) qui forment les clusters kubernetes.
```bash
# Pool of machines used by the cluster
gcloud container node-pools list --zone <zone> --cluster <cluster>
gcloud container node-pools describe --cluster <cluster> --zone <zone> <node-pool>
```
## Kubernetes

Pour des informations sur ce qu'est Kubernetes, consultez cette page :

{{#ref}}
../../kubernetes-security/
{{#endref}}

Tout d'abord, vous pouvez vérifier s'il existe des clusters Kubernetes dans votre projet.
```
gcloud container clusters list
```
Si vous avez un cluster, vous pouvez faire en sorte que `gcloud` configure automatiquement votre fichier `~/.kube/config`. Ce fichier est utilisé pour vous authentifier lorsque vous utilisez [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), l'interface en ligne de commande native pour interagir avec les clusters K8s. Essayez cette commande.
```
gcloud container clusters get-credentials [CLUSTER NAME] --region [REGION]
```
Ensuite, jetez un œil au fichier `~/.kube/config` pour voir les identifiants générés. Ce fichier sera utilisé pour actualiser automatiquement les jetons d'accès en fonction de la même identité que celle utilisée par votre session `gcloud` active. Cela nécessite bien sûr les autorisations appropriées.

Une fois cela configuré, vous pouvez essayer la commande suivante pour obtenir la configuration du cluster.
```
kubectl cluster-info
```
Vous pouvez en savoir plus sur `gcloud` pour les conteneurs [ici](https://cloud.google.com/sdk/gcloud/reference/container/).

Ceci est un script simple pour énumérer kubernetes dans GCP : [https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum](https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum)

### Escalade de privilèges TLS Bootstrap

Initialement, cette technique d'escalade de privilèges permettait de **privesc à l'intérieur du cluster GKE**, permettant ainsi à un attaquant de **le compromettre complètement**.

C'est parce que GKE fournit [des identifiants TLS Bootstrap](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) dans les métadonnées, qui sont **accessibles par quiconque en compromettant simplement un pod**.

La technique utilisée est expliquée dans les publications suivantes :

- [https://www.4armed.com/blog/hacking-kubelet-on-gke/](https://www.4armed.com/blog/hacking-kubelet-on-gke/)
- [https://www.4armed.com/blog/kubeletmein-kubelet-hacking-tool/](https://www.4armed.com/blog/kubeletmein-kubelet-hacking-tool/)
- [https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)

Et cet outil a été créé pour automatiser le processus : [https://github.com/4ARMED/kubeletmein](https://github.com/4ARMED/kubeletmein)

Cependant, la technique abusait du fait que **avec les identifiants de métadonnées**, il était possible de **générer un CSR** (Certificate Signing Request) pour un **nouveau nœud**, qui était **automatiquement approuvé**.\
Dans mon test, j'ai vérifié que **ces demandes ne sont plus automatiquement approuvées**, donc je ne suis pas sûr que cette technique soit toujours valide.

### Secrets dans l'API Kubelet <a href="#the-kubelet-api-git-secrets-redux" id="the-kubelet-api-git-secrets-redux"></a>

Dans [**cet article**](https://blog.assetnote.io/2022/05/06/cloudflare-pages-pt3/), il a été découvert qu'il y avait une adresse API Kubelet accessible depuis l'intérieur d'un pod dans GKE, donnant les détails des pods en cours d'exécution :
```
curl -v -k http://10.124.200.1:10255/pods
```
Même si l'API **ne permet pas de modifier les ressources**, il pourrait être possible de trouver **des informations sensibles** dans la réponse. Le point de terminaison /pods a été trouvé en utilisant [**Kiterunner**](https://github.com/assetnote/kiterunner).

{{#include ../../../banners/hacktricks-training.md}}
