Cyber Security Academy · Lezione

Modello delle minacce di Kubernetes

Dove vengono attaccati i cluster.

Modello delle minacce di Kubernetes è una lezione Cyber Security Academy gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Cyber Security Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Cyber Security Academy include 4 lezioni in totale.

Perché Kubernetes è un obiettivo

Kubernetes orchestra i container su numerosi nodi. Centralizza segreti, networking e compute, quindi compromettere il cluster può significare compromettere ogni workload che esegue.

Un solo API server controlla l'intero cluster.
I nodi eseguono i workload di molti tenant fianco a fianco.
Una configurazione errata è molto più comune delle CVE nel core.

Riepilogo dell'architettura del cluster

Per definire il threat model, conosca i componenti.

Piano di controllo: API server, etcd, scheduler, controller-manager.
Nodi: kubelet, container runtime, kube-proxy, pod.
etcd archivia l'intero stato del cluster e i segreti.

L'API server è il singolo punto di accesso; etcd è l'asset di dati più prezioso.

La mappa della superficie di attacco

Gli attacchi prendono di mira livelli distinti.

Esterno: API server, dashboard e ingress esposti.
Workload: un'applicazione compromessa all'interno di un pod.
Identità: token degli account di servizio e RBAC.
Nodo: API del kubelet, fuga del container verso l'host.
Catena di fornitura: immagini e dipendenze dannose.

Piano di controllo esposto

Un API server o un kubelet raggiungibile da Internet con un'autenticazione debole rappresenta un percorso diretto alla presa di controllo del cluster.

Accesso anonimo abilitato sull'API server.
API di lettura/scrittura del kubelet (porta 10250) esposta.
Dashboard Kubernetes aperta con un binding amministrativo.

# Probe an exposed kubelet for running pods
curl -sk https://NODE_IP:10250/pods

# Test anonymous API access
kubectl --insecure-skip-tls-verify --server https://API:6443 get pods

Il punto d'appoggio nel pod

Il punto di partenza più comune è una RCE in un'applicazione in esecuzione in un pod. Dall'interno di un pod, gli attaccanti individuano:

Un token dell'account di servizio montato in /var/run/secrets/....
Servizi interni raggiungibili (in assenza di una policy di rete).
L'API server, spesso risolvibile come kubernetes.default.

# From inside a pod: read the mounted SA token
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Use it against the API
curl -sk -H "Authorization: Bearer $(cat .../token)" https://kubernetes.default/api/v1/namespaces/default/pods

Fuga dal container

Uscire da un container e approdare sul nodo consente di accedere a tutti i workload presenti su quell'host.

I container privilegiati possono accedere ai dispositivi dell'host e consentire la fuga.
I mount hostPID/hostNetwork/hostPath ampliano il raggio d'azione dell'attacco.
Un socket Docker montato consente di avviare un container privilegiato.
Capability pericolose (SYS_ADMIN) consentono la fuga.

# A privileged pod can mount the host filesystem and chroot to it
mount /dev/sda1 /mnt && chroot /mnt sh

etcd: l'archivio dei segreti

etcd contiene l'intero stato del cluster, inclusi i Secrets, che per impostazione predefinita sono solo codificati in base64. L'accesso diretto a etcd (spesso non autenticato nei cluster configurati erroneamente) espone ogni segreto.

# Read all secrets from an exposed etcd
etcdctl --endpoints=https://NODE:2379 get / --prefix --keys-only

Movimento laterale nei cluster

Una volta all'interno, gli attaccanti si spostano lateralmente sfruttando l'identità e il networking del cluster.

Un account di servizio permissivo consente di creare pod privilegiati.
Le reti dei pod piatte (senza NetworkPolicy) consentono di raggiungere qualsiasi servizio.
Pianificare un pod su un nodo obiettivo consente di compromettere il nodo.

Metadati cloud dai pod

Nei cluster gestiti (EKS/GKE/AKS), i pod possono raggiungere il servizio di metadati cloud del nodo e sottrarre le credenziali IAM/di ruolo del nodo, trasformando la compromissione del cluster in un accesso all'account cloud.

Le difese includono IMDSv2, il blocco dei metadati a livello di rete e l'utilizzo della workload identity al posto dei ruoli dei nodi.

Mappatura con gli strumenti

Gli strumenti automatizzano la valutazione delle minacce del cluster.

kube-hunter esegue probe alla ricerca di componenti esposti.
kube-bench verifica la conformità al benchmark CIS.
Peirates / kubeletctl esercitano i percorsi di attacco all'interno del cluster.

# Assess attack surface
kube-hunter --remote API_IP

# CIS benchmark check on a node
kube-bench run --targets node

Priorità difensive

Il threat model indica priorità difensive chiare: protegga l'API server, limiti RBAC, isoli i pod, rafforzi i nodi e protegga la catena di fornitura. Le lezioni successive approfondiranno ciascun aspetto.

Durante i test, attacchi solo cluster per i quali dispone di autorizzazione ed eviti di destabilizzare i workload di produzione.

Verifica rapida

Verifichi le basi del threat model di Kubernetes.

Riepilogo

Ha mappato i punti in cui i cluster Kubernetes possono essere attaccati.

L'API server e etcd sono gli obiettivi centrali e di maggior valore.
I punti d'appoggio nei pod sfruttano i token SA montati e le reti piatte.
I pod privilegiati o con hostPath consentono la fuga dal container verso il nodo.
I cluster gestiti sono esposti al rischio di uno spostamento laterale nel cloud basato sui metadati.

Prossimo argomento: RBAC e account di servizio.

Domande Frequenti

La lezione «Modello delle minacce di Kubernetes» è gratuita?

Sì — il testo completo di «Modello delle minacce di Kubernetes» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Cyber Security Academy, passa a CoddyKit PRO. Il corso Cyber Security Academy include 4 lezioni in totale.

Cosa imparerò in «Modello delle minacce di Kubernetes»?

Dove vengono attaccati i cluster. Eserciti Cyber Security Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Cyber Security Academy?

Non è richiesta alcuna esperienza precedente. Cyber Security Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.

Quanto tempo richiede la lezione «Modello delle minacce di Kubernetes»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Cyber Security Academy?

Sì. Ogni lezione Cyber Security Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

← Torna a Cyber Security Academy