Kubernetes Pivoting to Clouds
Impara e pratica l'hacking su AWS: HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'hacking su GCP:
HackTricks Training GCP Red Team Expert (GRTE)
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:
Montare le chiavi GCP-SA come segreto
Un modo comune per dare accesso a un'applicazione Kubernetes a GCP è:
Creare un account di servizio GCP
Associare ad esso le autorizzazioni desiderate
Scaricare una chiave json del SA creato
Montarla come segreto all'interno del pod
Impostare la variabile d'ambiente GOOGLE_APPLICATION_CREDENTIALS che punta al percorso in cui si trova il json.
Pertanto, come attaccante, se comprometti un contenitore all'interno di un pod, dovresti controllare quella variabile env e i file json con le credenziali GCP.
Collegare il json GSA al segreto KSA
Un modo per dare accesso a un GSA a un cluster GKE è associarli in questo modo:
Creare un account di servizio Kubernetes nello stesso namespace del tuo cluster GKE usando il seguente comando:
Crea un Kubernetes Secret che contenga le credenziali del service account di GCP a cui desideri concedere l'accesso al cluster GKE. Puoi farlo utilizzando lo strumento da riga di comando
gcloud
, come mostrato nell'esempio seguente:
Collega il Kubernetes Secret all'account del servizio Kubernetes usando il seguente comando:
Nel secondo passo sono stati impostati le credenziali del GSA come segreto del KSA. Quindi, se riesci a leggere quel segreto da dentro il cluster GKE, puoi scalare a quell'account di servizio GCP.
Identità del Carico di Lavoro GKE
Con l'Identità del Carico di Lavoro, possiamo configurare un account di servizio Kubernetes per agire come un account di servizio Google. I pod in esecuzione con l'account di servizio Kubernetes si autenticano automaticamente come l'account di servizio Google quando accedono alle API di Google Cloud.
La prima serie di passaggi per abilitare questo comportamento è abilitare l'Identità del Carico di Lavoro in GCP (passaggi) e creare l'account di servizio GCP che si desidera che k8s impersoni.
Abilita l'Identità del Carico di Lavoro su un nuovo cluster
Creare/Aggiornare un nuovo nodepool (I cluster Autopilot non ne hanno bisogno)
Crea il Account del servizio GCP da impersonare da K8s con le autorizzazioni GCP:
Connettersi al cluster e creare il account del servizio da utilizzare
Collegare il GSA con il KSA
Esegui un pod con il KSA e controlla l'accesso al GSA:
Controlla il seguente comando per autenticarti in caso di necessità:
Come attaccante all'interno di K8s dovresti cercare gli SA con l'annotazione **iam.gke.io/gcp-service-account
poiché ciò indica che l'**SA può accedere a qualcosa in GCP. Un'altra opzione sarebbe cercare di abusare ogni KSA nel cluster e verificare se ha accesso.
Da GCP è sempre interessante enumerare i binding e sapere a quali accessi stai dando agli SA all'interno di Kubernetes.
Questo è uno script per iterare facilmente su tutte le definizioni dei pod cercando quell'annotazione:
AWS
Kiam & Kube2IAM (IAM role for Pods)
Un modo (obsoleto) per assegnare ruoli IAM ai Pods è utilizzare un Kiam o un Kube2IAM server. Fondamentalmente è necessario eseguire un daemonset nel cluster con un tipo di ruolo IAM privilegiato. Questo daemonset sarà quello che fornirà l'accesso ai ruoli IAM ai pods che ne hanno bisogno.
Prima di tutto è necessario configurare quali ruoli possono essere accessibili all'interno dello spazio dei nomi, e si fa ciò con un'annotazione all'interno dell'oggetto dello spazio dei nomi:
Una volta che lo spazio dei nomi è configurato con i ruoli IAM che i Pods possono avere, puoi indicare il ruolo desiderato su ciascuna definizione del pod con qualcosa del genere:
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 ruolo che è già usato dai pod e altro (se hai accesso all'account AWS enumera i ruoli).
Creare Pod con Ruolo IAM
Il ruolo IAM da indicare deve essere nello stesso account AWS del ruolo kiam/kube2iam e quel ruolo deve essere in grado di accedervi.
Ruolo IAM per Account Servizio K8s tramite OIDC
Questo è il modo consigliato da AWS.
Prima di tutto è necessario creare un provider OIDC per il cluster.
Successivamente creare un ruolo IAM con le autorizzazioni di cui avrà bisogno l'AS.
Creare una relazione di trust tra il ruolo IAM e l'AS nome (o i namespace che concedono l'accesso al ruolo a tutti gli AS del namespace). La relazione di trust controllerà principalmente il nome del provider OIDC, il nome del namespace e il nome dell'AS.
Infine, creare un AS con un'annotazione che indica l'ARN del ruolo, e i pod in esecuzione con tale AS 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
)
Per ottenere aws usando il token da /var/run/secrets/eks.amazonaws.com/serviceaccount/token
esegui:
Come attaccante, se riesci a enumerare un cluster K8s, controlla gli account di servizio con quell'annotazione per scalare verso AWS. Per farlo, basta eseguire/creare un pod utilizzando uno degli account di servizio privilegiati IAM e rubare il token.
Inoltre, se ti trovi all'interno di un pod, controlla le variabili di ambiente come AWS_ROLE_ARN e AWS_WEB_IDENTITY_TOKEN.
A volte la Policy di Trust di un ruolo potrebbe essere configurata male e anziché concedere l'accesso AssumeRole all'account di servizio previsto, lo concede a tutti gli account di servizio. Pertanto, se sei in grado di scrivere un'annotazione su un account di servizio controllato, puoi accedere al ruolo.
Controlla la pagina seguente per ulteriori informazioni:
Trova Pods e SAs con Ruoli IAM nel Cluster
Questo è uno script per scorrere facilmente tutti i pod e le definizioni di sa cercando quell'annotazione:
Ruolo IAM del Nodo
La sezione precedente trattava di come rubare i Ruoli IAM con i pod, ma nota che un Nodo del cluster K8s sarà un'istanza all'interno del cloud. Ciò significa che è molto probabile che il Nodo 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 controllare ogni nodo).
Tuttavia, c'è un requisito importante per accedere al punto finale dei metadati dal nodo, devi essere nel nodo (sessione ssh?) o almeno avere la stessa rete:
Rubare il Token del Ruolo IAM
Precedentemente abbiamo discusso come attaccare Ruoli IAM ai Pod o addirittura come scappare al Nodo per rubare il Ruolo IAM che l'istanza ha attaccato ad esso.
Puoi utilizzare lo script seguente per rubare le tue nuove credenziali del ruolo IAM su cui hai lavorato duramente:
Riferimenti
Impara e pratica l'Hacking su AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking su GCP:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated