0Pricing
Cyber Security Academy · Lezione

RBAC e account di servizio

Proteggere l'accesso al cluster.

RBAC e account di servizio è una lezione Cyber Security Academy gratuita su CoddyKit. Questa è la lezione 2 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.

RBAC controlla ogni aspetto

Il controllo degli accessi basato sui ruoli (RBAC) stabilisce quali identità possono eseguire quali azioni su quali risorse in un cluster. Ogni chiamata API viene autorizzata in base a RBAC. Un RBAC configurato erroneamente è la principale causa di escalation dei privilegi all'interno del cluster.

  • Soggetti: utenti, gruppi, account di servizio.
  • I ruoli associano i verbi alle risorse.
  • I binding collegano i soggetti ai ruoli.

Ruoli e ClusterRole a confronto

Esistono due ambiti.

  • Role + RoleBinding: autorizzazioni limitate al namespace.
  • ClusterRole + ClusterRoleBinding: autorizzazioni a livello di cluster.

Un ClusterRoleBinding a cluster-admin garantisce il controllo totale. Concederlo a un account di servizio è un errore frequente e pericoloso.

Token degli account di servizio

Ogni pod viene eseguito come account di servizio e, per impostazione predefinita, monta il relativo token. Questo token è una credenziale bearer che conferisce le autorizzazioni RBAC dell'account. Se il pod viene compromesso, anche il token lo è.

I cluster moderni emettono token proiettati a breve durata e vincolati a un'audience, ma i token legacy a lunga durata memorizzati nei Secret sono ancora presenti.

# Inspect which service account a pod uses
kubectl get pod web -o jsonpath='{.spec.serviceAccountName}'

Enumerare le proprie autorizzazioni

Dopo aver acquisito un token, il primo passo consiste nel capire cosa può fare. Kubernetes mette a disposizione un'API di autoverifica.

# What can this token do?
kubectl auth can-i --list

# Specific checks
kubectl auth can-i create pods
kubectl auth can-i create clusterrolebindings

Combinazioni di autorizzazioni pericolose

Alcuni verbi sono primitivi di escalation anche senza cluster-admin.

  • create pods: pianificare un pod privilegiato o con hostPath per fuggire.
  • create pods/exec: eseguire comandi nei pod esistenti.
  • get/list secrets: leggere le credenziali a livello dell'intero cluster.
  • create rolebindings/clusterrolebindings: associarsi a un ruolo amministrativo.
  • Verbi escalate / bind: concedere diritti di cui non si dispone.
  • impersonate: agire come un altro soggetto con privilegi maggiori.

Escalation tramite la creazione di pod

Se un account di servizio può creare pod, spesso può assumere il controllo del nodo. L'attaccante pianifica un pod che monta il file system dell'host o viene eseguito con privilegi elevati, quindi legge le credenziali del nodo o evade dal container.

# Pod spec snippet that mounts the host root
# volumes: hostPath path: /  ;  container mounts it at /host
kubectl apply -f evil-pod.yaml
kubectl exec -it evil -- chroot /host bash

Escalation tramite i binding

Se può creare (cluster)rolebindings, potrebbe associare direttamente il proprio account di servizio a cluster-admin. Kubernetes protegge questa operazione con i verbi bind/escalate, ma i ruoli configurati erroneamente talvolta la consentono.

# Bind a service account to cluster-admin (if permitted)
kubectl create clusterrolebinding pwn \
  --clusterrole=cluster-admin \
  --serviceaccount=default:web

Abuso dell'impersonation

Il verbo impersonate consente a un soggetto di agire come qualsiasi utente, gruppo o account di servizio. Un principal con autorizzazioni ampie di impersonation detiene di fatto ogni permesso del cluster.

# Act as a privileged user via impersonation
kubectl get secrets --as=admin-user --as-group=system:masters

Verifica di RBAC

I difensori dovrebbero esaminare continuamente RBAC alla ricerca di concessioni rischiose.

  • Individuino i soggetti associati a cluster-admin.
  • Segnalino i verbi e le risorse jolly (*).
  • Rilevino concessioni di lettura dei Secret e creazione di pod su account non amministrativi.
# Tools to audit RBAC
kubectl-who-can create pods
rbac-tool analysis
rakkess --as=system:serviceaccount:default:web

Rafforzare gli account di servizio

Applichi il principio del privilegio minimo alle identità.

  • Imposti automountServiceAccountToken: false nei casi in cui il pod non necessiti dell'accesso all'API.
  • Assegni a ogni workload un account di servizio dedicato e con ambito minimo.
  • Eviti l'account di servizio default per i workload reali.
  • Utilizzi token proiettati a breve durata con audience; li ruoti e li associ.
  • Non associ mai i workload a cluster-admin.

Testare RBAC in modo etico

Quando valuta RBAC, preferisca verifiche non distruttive (auth can-i, dry-run) alla creazione effettiva di binding a cluster-admin in produzione. Se deve dimostrare un'escalation, la limiti a un namespace di test e rimuova ogni binding o pod creato.

Segnali i ruoli e i binding esatti che hanno consentito l'escalation, così che possano essere resi più restrittivi.

Verifica rapida

Verifichi la propria comprensione di RBAC.

Riepilogo

Ha appreso come RBAC e gli account di servizio governano e mettono a rischio l'accesso al cluster.

  • RBAC associa i soggetti ai verbi sulle risorse; cluster-admin garantisce il controllo totale.
  • I pod montano token SA; auth can-i ne rivela il raggio d'azione.
  • create-pods, binding, secret-read e impersonate sono primitivi di escalation.
  • Gli account con privilegi minimi e l'auto-mount disattivato rafforzano il cluster.

Prossimo argomento: sicurezza dei pod e policy di rete.

Domande Frequenti

La lezione «RBAC e account di servizio» è gratuita?

Sì — il testo completo di «RBAC e account di servizio» è 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 «RBAC e account di servizio»?

Proteggere l'accesso al 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 2 di 4.

Quanto tempo richiede la lezione «RBAC e account di servizio»?

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

  1. Modello delle minacce di Kubernetes
  2. RBAC e account di servizio
  3. Sicurezza dei pod e policy di rete
  4. Proteggere la supply chain e i secret
← Torna a Cyber Security Academy