0Pricing
Cyber Security Academy · Lezione

Sicurezza dei pod e policy di rete

Isolare i workload.

Sicurezza dei pod e policy di rete è una lezione Cyber Security Academy gratuita su CoddyKit. Questa è la lezione 3 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.

Isolamento dei carichi di lavoro

Due controlli limitano ciò che un pod compromesso può fare: Pod Security limita i privilegi di un pod, mentre le Network Policies limitano quali pod possono comunicare tra loro. Insieme contengono il raggio d'impatto.

  • Pod Security impedisce le evasioni verso il nodo.
  • Le Network Policies impediscono i movimenti laterali tra i pod.

Impostazioni pericolose dei pod

Se consentiti, diversi campi della specifica di un pod ampliano notevolmente il rischio.

  • privileged: true concede un accesso quasi completo all'host.
  • hostPID, hostNetwork, hostIPC interrompono l'isolamento dei namespace.
  • I volumi hostPath montano directory del nodo.
  • Capabilities aggiuntive come SYS_ADMIN consentono l'evasione.
  • Esecuzione come root (runAsUser: 0).

Pod Security Admission

Pod Security Admission (PSA) ha sostituito PodSecurityPolicy. Applica tre standard integrati per ogni namespace.

  • Privileged: senza restrizioni (da evitare per i carichi di lavoro).
  • Baseline: blocca le escalation dei privilegi note.
  • Restricted: best practice rafforzata (non-root, nessun privilegio, capabilities rimosse).
# Enforce the restricted standard on a namespace
kubectl label namespace prod \
  pod-security.kubernetes.io/enforce=restricted

Un securityContext rafforzato

Definisca il principio del privilegio minimo a livello di pod e container tramite un securityContext.

  • Esegua il processo con un utente non root e utilizzi un filesystem root in sola lettura.
  • Rimuova tutte le capabilities Linux, quindi aggiunga solo quelle necessarie.
  • Disabiliti l'escalation dei privilegi.
# securityContext fields (YAML)
# runAsNonRoot: true
# readOnlyRootFilesystem: true
# allowPrivilegeEscalation: false
# capabilities: drop: [ALL]
kubectl apply -f hardened-deploy.yaml

Oltre gli standard: motori di policy

Per regole più avanzate rispetto a PSA, i controller di ammissione applicano policy personalizzate.

  • OPA Gatekeeper valuta i vincoli Rego.
  • Kyverno utilizza policy YAML e può eseguire mutazioni oltre che convalidare.

Questi strumenti possono vietare hostPath, richiedere immagini firmate o imporre label in tutto il cluster.

# Apply a Kyverno policy that disallows privileged pods
kubectl apply -f disallow-privileged.yaml

Rete aperta per impostazione predefinita

Per impostazione predefinita, tutti i pod possono raggiungere tutti gli altri pod in tutti i namespace. Non esiste alcuna segmentazione finché non si aggiungono Network Policies. Questa rete piatta spiega perché un singolo pod compromesso può analizzare e attaccare l'intero cluster.

# From a pod, the flat network lets you reach any service
curl http://internal-db.prod.svc.cluster.local:5432

Nozioni di base sulle Network Policies

Le Network Policies sono regole con ambito di namespace che selezionano i pod e consentono ingressi e uscite specifici. Sono additive: l'applicazione di una qualsiasi policy a un pod lo porta a utilizzare il comportamento di negazione predefinita per la direzione interessata.

  • I selettori identificano i pod in base alle label.
  • Le regole consentono il traffico da o verso pod, namespace o CIDR specifici.
  • È necessaria una CNI che supporti le policy (Calico, Cilium).

Nega tutto per impostazione predefinita, poi consenti

Il modello consigliato prevede una baseline di negazione predefinita per ogni namespace, seguita da regole di autorizzazione esplicite per i flussi necessari.

# Default-deny all ingress in a namespace (YAML)
# kind: NetworkPolicy spec: podSelector: {} policyTypes: [Ingress]
kubectl apply -f default-deny.yaml

# Then allow only frontend -> backend
kubectl apply -f allow-frontend.yaml

Blocco dell'egress e dei metadati

Le policy di egress sono importanti quanto quelle di ingress.

  • Limiti gli endpoint esterni che i pod possono raggiungere (limitando l'esfiltrazione e il C2).
  • Blocchi dai pod l'IP dei metadati cloud 169.254.169.254 per impedire il furto delle credenziali del nodo.
  • Limiti il DNS e il traffico interno est-ovest.

Difesa a runtime

La policy statica è integrata dal rilevamento a runtime.

  • Falco genera avvisi in caso di syscall sospette (shell nel container, mount sensibili).
  • I profili seccomp limitano le syscall che un container può eseguire.
  • AppArmor/SELinux aggiungono il controllo obbligatorio degli accessi sul nodo.
# Apply the runtime/default seccomp profile (securityContext)
# seccompProfile: type: RuntimeDefault
kubectl apply -f seccomp-deploy.yaml

Test dell'isolamento

Per convalidare il contenimento, tenti connessioni tra pod e primitive di evasione da un pod di test, verificando che le policy le blocchino. Esegua questa attività in un namespace controllato e rimuova i pod di test al termine.

Segnali ogni pod eseguito con privilegi o ogni namespace privo di negazione predefinita, indicando la correzione esatta del manifest.

Verifica rapida

Verifichi le proprie conoscenze sull'isolamento.

Riepilogo

Ha imparato a isolare i carichi di lavoro.

  • Pod Security Admission (restricted) e securityContext impediscono le evasioni.
  • Gatekeeper/Kyverno applicano policy di ammissione personalizzate.
  • La rete è aperta per impostazione predefinita: applichi prima la negazione predefinita, poi autorizzazioni esplicite.
  • Le regole di egress, il blocco dei metadati e Falco aggiungono ulteriori livelli di protezione.

Prossimo argomento: protezione della catena di fornitura e dei secret.

Domande Frequenti

La lezione «Sicurezza dei pod e policy di rete» è gratuita?

Sì — il testo completo di «Sicurezza dei pod e policy di rete» è 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 «Sicurezza dei pod e policy di rete»?

Isolare i workload. 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 3 di 4.

Quanto tempo richiede la lezione «Sicurezza dei pod e policy di rete»?

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