0Pricing
Kubernetes Basics · Lezione

Network Policy per l'isolamento

Controlli il flusso del traffico di rete tra Pod e namespace utilizzando le Network Policy di Kubernetes.

Network Policy per l'isolamento è una lezione Kubernetes Basics 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 Kubernetes Basics, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Kubernetes Basics include 4 lezioni in totale.

Network Policies: i vigili del traffico

In Kubernetes, per impostazione predefinita i Pod possono comunicare liberamente tra loro. Questo offre grande flessibilità, ma non è sempre l'ideale dal punto di vista della sicurezza.

Le Network Policies funzionano come firewall per i Pod e controllano quale traffico di rete è consentito in ingresso (ingress) e in uscita (egress).

Impostazione predefinita: tutti i Pod possono comunicare

Per impostazione predefinita, una volta distribuito, un Pod può comunicare con qualsiasi altro Pod del cluster, indipendentemente dal namespace. Questo modello di "rete piatta" semplifica la configurazione, ma non offre isolamento.

Negli ambienti di produzione è spesso necessario limitare le comunicazioni per aumentare la sicurezza e impedire accessi non autorizzati tra i componenti dell'applicazione.

Regole di ingresso e uscita

Le Network Policies definiscono le regole per le comunicazioni consentite tra i Pod. Si concentrano principalmente su due tipi di traffico:

  • Ingress: traffico in ingresso verso un Pod.
  • Egress: traffico in uscita da un Pod.

Queste regole vengono applicate a Pod specifici mediante le label e possono avere come destinazione altri Pod, namespace o blocchi IP.

Requisito del plugin CNI

Le Network Policies non sono magiche! Per funzionare, il cluster Kubernetes deve avere un plugin Container Network Interface (CNI) che le supporti.

Plugin CNI diffusi come Calico, Cilium e Weave Net offrono questa funzionalità. Senza un CNI compatibile, le Network Policies non avranno alcun effetto.

Anatomia di una policy

Le Network Policies vengono definite utilizzando YAML. I campi principali includono:

  • metadata.name: un nome univoco per la policy.
  • spec.podSelector: seleziona i Pod a cui si applica la policy.
  • spec.policyTypes: specifica se la policy si applica a Ingress, Egress o a entrambi.
  • spec.ingress/spec.egress: elenca le regole per il traffico consentito.

Bloccare tutto il traffico in ingresso

Creiamo una policy per negare tutto il traffico in ingresso ai Pod con la label app: backend nel namespace corrente. Questo è un punto di partenza comune per una strategia di sicurezza "nega per impostazione predefinita".

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-backend-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress: [] # An empty ingress list denies all incoming traffic

Consentire l'ingresso dal frontend

Ora modifichiamo la policy per consentire il traffico in ingresso ai nostri Pod app: backend solo dai Pod con la label app: frontend nello stesso namespace.

Noti la sezione from, che specifica i Pod di origine.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Controllare il traffico in uscita

Come per il traffico in ingresso, è possibile controllare il traffico in uscita (egress). Qui creeremo una policy che consente ai Pod app: backend di effettuare richieste in uscita solo verso i Pod con la label app: database.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-to-db
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database

Indirizzare il traffico verso altri namespace

E se il frontend si trovasse in un namespace diverso, ad esempio web-apps? Può utilizzare namespaceSelector per selezionare i Pod tra namespace diversi.

Questa policy consente il traffico in ingresso verso i Pod app: backend da qualsiasi Pod nel namespace web-apps.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-apps-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: web-apps
      podSelector: {} # All pods in the selected namespace

Sfida sulle policy

Consideri un Pod con le label app: web e env: prod. Quale Network Policy consentirebbe solo il traffico in ingresso dai Pod nel namespace monitoring?

Riepilogo: proteggere la rete

Ottimo lavoro! Ha appreso come le Network Policies di Kubernetes forniscano un isolamento di rete fondamentale per le applicazioni.

  • Funzionano come firewall per i Pod.
  • Controllano il traffico sia in ingresso (in) sia in uscita (out).
  • Richiedono un plugin CNI che le supporti.
  • Vengono definite in YAML con podSelector, policyTypes e le definizioni delle regole.
  • Possono selezionare i Pod tramite label e persino interi namespace.

Le utilizzi per applicare un modello di rete basato sul "minimo privilegio".

Domande Frequenti

La lezione «Network Policy per l'isolamento» è gratuita?

Sì — il testo completo di «Network Policy per l'isolamento» è 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 Kubernetes Basics, passa a CoddyKit PRO. Il corso Kubernetes Basics include 4 lezioni in totale.

Cosa imparerò in «Network Policy per l'isolamento»?

Controlli il flusso del traffico di rete tra Pod e namespace utilizzando le Network Policy di Kubernetes. Eserciti Kubernetes Basics 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 Kubernetes Basics?

Non è richiesta alcuna esperienza precedente. Kubernetes Basics 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 «Network Policy per l'isolamento»?

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 Kubernetes Basics?

Sì. Ogni lezione Kubernetes Basics 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. Role-Based Access Control (RBAC)
  2. Network Policy per l'isolamento
  3. Standard di sicurezza dei Pod
  4. Account di servizio e identità dei workload
← Torna a Kubernetes Basics