View a markdown version of this page

Limita il traffico di Pod con le policy di rete di Kubernetes - Amazon EKS
Panoramica diPolitica di rete standardPolitica di rete dell'amministratore (o del cluster)Note importantiConsiderazioni

Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina su che si trova nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Limita il traffico di Pod con le policy di rete di Kubernetes

Panoramica di

Per impostazione predefinita, in Kubernetes non ci sono restrizioni per indirizzi IP, porte o connessioni tra qualsiasi Pod nel cluster o tra i pod e le risorse in qualsiasi altra rete. È possibile utilizzare la policy di rete di Kubernetes per limitare il traffico di rete da e verso i pod. Per ulteriori informazioni, consulta Network Policies nella documentazione Kubernetes.

Politica di rete standard

È possibile utilizzare lo standard NetworkPolicy per segmentare il traffico da pod a pod nel cluster. Queste policy di rete operano ai livelli 3 e 4 del modello di rete OSI, consentendoti di controllare il flusso di traffico a livello di indirizzo IP o porta all'interno del tuo cluster Amazon EKS. Le politiche di rete standard sono limitate a livello di namespace.

Casi d’uso

  • Segmenta il traffico di rete tra i carichi di lavoro per garantire che solo le applicazioni correlate possano comunicare tra loro.

  • Isola i tenant a livello di namespace utilizzando politiche per imporre la separazione della rete.

Esempio

Nella politica riportata di seguito, il traffico in uscita dai pod delle webapp nel namespace sun è limitato. 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webapp-egress-policy
  namespace: sun
spec:
  podSelector:
    matchLabels:
      role: webapp
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: moon
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080
  - to:
    - namespaceSelector:
        matchLabels:
          name: stars
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

La politica si applica ai pod con l'etichetta nel namespace. role: webapp sun

  • Traffico consentito: pod con l'etichetta role: frontend nel namespace sulla porta TCP moon 8080

  • Traffico consentito: pod con l'etichetta role: frontend nello spazio dei nomi sulla porta TCP stars 8080

  • Traffico bloccato: tutto il resto del traffico in uscita dai pod viene negato implicitamente webapp

Politica di rete dell'amministratore (o del cluster)

Illustrazione dell'ordine di valutazione delle politiche di rete in EKS

È possibile utilizzare il ClusterNetworkPolicy per applicare uno standard di sicurezza di rete che si applica all'intero cluster. Invece di definire e mantenere ripetutamente una policy distinta per ogni namespace, è possibile utilizzare un'unica policy per gestire centralmente i controlli di accesso alla rete per i diversi carichi di lavoro nel cluster, indipendentemente dal rispettivo namespace.

Casi d’uso

  • Gestisci centralmente i controlli di accesso alla rete per tutti (o un sottoinsieme di) carichi di lavoro nel tuo cluster EKS.

  • Definisci un livello di sicurezza di rete predefinito in tutto il cluster.

  • Estendi gli standard di sicurezza organizzativi all'ambito del cluster in un modo più efficiente dal punto di vista operativo.

Esempio

Nella policy riportata di seguito, è possibile bloccare esplicitamente il traffico del cluster proveniente da altri namespace per impedire l'accesso di rete a un namespace sensibile dei carichi di lavoro.

apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: protect-sensitive-workload
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: earth
  ingress:
    - action: Deny
      from:
      - namespaces:
          matchLabels: {} # Match all namespaces.
      name: select-all-deny-all

Note importanti

Le policy di rete nel plug-in Amazon VPC CNI per Kubernetes sono supportate nelle configurazioni elencate di seguito.

  • Versione 1.21.0 (o successiva) del plug-in Amazon VPC CNI per le policy di rete standard e amministrative.

  • Cluster configurato per indirizzi IPv4 o IPv6.

  • È possibile utilizzare le policy di rete con i gruppi di sicurezza per pod. Con le policy di rete, è possibile controllare tutte le comunicazioni all’interno del cluster. Con i gruppi di sicurezza per Pods, puoi controllare l'accesso ai AWS servizi dalle applicazioni all'interno di un Pod.

  • È possibile utilizzare le policy di rete con le reti personalizzate e la delega del prefisso.

Considerazioni

Architettura

  • Quando si applicano le policy di rete del plug-in CNI di Amazon VPC per Kubernetes al cluster con il plug-in CNI di Amazon VPC per Kubernetes, è possibile applicare le policy solo ai nodi Amazon EC2 Linux. Non è possibile applicare le policy ai nodi Fargate o Windows.

  • Le politiche di rete si applicano solo a uno IPv4 IPv6 degli indirizzi, ma non a entrambi. In un IPv4 cluster, il VPC CNI assegna un IPv4 indirizzo ai pod e applica le policy. IPv4 In un IPv6 cluster, il VPC CNI assegna un IPv6 indirizzo ai pod e applica le policy. IPv6 Tutte le regole di policy di rete IPv4 applicate a un cluster IPv6 vengono ignorate. Tutte le regole di policy di rete IPv6 applicate a un cluster IPv4 vengono ignorate.

Policy di rete

  • Amazon EKS ottimizza l'applicazione delle policy di rete per i pod con un set di campi. metadata.ownerReferences Ciò include i pod gestiti da controller come Deployments, StatefulSets, DaemonSets Jobs e. CronJobs I pod autonomi creati direttamente senza un controller non sono metadata.ownerReferences impostati e l'applicazione delle policy di rete potrebbe non funzionare in modo affidabile per questi pod.

  • È possibile applicare più policy di rete allo stesso pod. Quando sono configurate due o più policy che selezionano lo stesso pod, al pod vengono applicate tutte le policy.

  • Il numero massimo di combinazioni di porte e protocolli per un singolo intervallo di indirizzi IP (CIDR) è 24 per tutte le policy di rete. Selettori come namespaceSelector risolvono verso uno o più CIDR. Se più selettori si risolvono in un unico CIDR o si specifica lo stesso CIDR diretto più volte nella stessa policy di rete o in diverse policy di rete, tutti questi fattori vengono conteggiati ai fini di questo limite.

  • Per ognuno dei servizi di Kubernetes, la porta del servizio deve essere uguale a quella del container. Se si utilizzano porte con un nome assegnato, è necessario utilizzare lo stesso nome anche nelle specifiche del servizio.

Politiche di rete di amministrazione

  1. Criteri del livello amministrativo (valutati per primi): tutti i livelli di amministrazione ClusterNetworkPolicies vengono valutati prima di qualsiasi altra politica. All'interno del livello Amministratore, le politiche vengono elaborate in ordine di priorità (prima il numero con la priorità più bassa). Il tipo di azione determina cosa succede dopo.

    • Azione di rifiuto (precedenza massima): quando una politica di amministrazione con un'azione Nega corrisponde al traffico, tale traffico viene immediatamente bloccato indipendentemente da qualsiasi altra politica. Non vengono elaborate ClusterNetworkPolicy ulteriori NetworkPolicy regole. Ciò garantisce che i controlli di sicurezza a livello di organizzazione non possano essere sostituiti da policy a livello di namespace.

    • Consenti azione: dopo aver valutato le regole di rifiuto, le politiche di amministrazione con azioni Consenti vengono elaborate in ordine di priorità (prima il numero con la priorità più bassa). Quando un'azione Consenti corrisponde, il traffico viene accettato e non viene effettuata alcuna ulteriore valutazione della policy. Queste policy possono concedere l'accesso a più namespace in base a selettori di etichette, fornendo un controllo centralizzato su quali carichi di lavoro possono accedere a risorse specifiche.

    • Passare all'azione: le azioni passate nelle policy di livello amministrativo delegano il processo decisionale ai livelli inferiori. Quando il traffico corrisponde a una regola Pass, la valutazione ignora tutte le restanti regole di livello di amministratore per quel traffico e passa direttamente al livello. NetworkPolicy Ciò consente agli amministratori di delegare esplicitamente il controllo di determinati modelli di traffico ai team applicativi. Ad esempio, potresti utilizzare le regole Pass per delegare la gestione del traffico all'interno dello spazio dei nomi agli amministratori dello spazio dei nomi mantenendo controlli rigorosi sull'accesso esterno.

  2. Livello di policy di rete: se nessun criterio di livello di amministrazione corrisponde a Nega o Consenti, o se corrisponde un'azione Pass, le risorse con ambito di namespace vengono valutate successivamente. NetworkPolicy Queste policy forniscono un controllo dettagliato all'interno dei singoli namespace e sono gestite dai team applicativi. Namespace-scoped le policy possono essere solo più restrittive delle policy di amministrazione. Non possono sovrascrivere la decisione di rifiuto di una politica di amministrazione, ma possono limitare ulteriormente il traffico consentito o passato dai criteri di amministrazione.

  3. Politiche di amministrazione di livello base: se nessuna politica amministrativa o con ambito di namespace corrisponde al traffico, viene valutato il livello Baseline. ClusterNetworkPolicies Questi forniscono posizioni di sicurezza predefinite che possono essere sostituite da policy con ambito di namespace, consentendo agli amministratori di impostare impostazioni predefinite a livello di organizzazione e offrendo ai team la flessibilità di personalizzarle in base alle esigenze. Le politiche di base vengono valutate in ordine di priorità (prima il numero con la priorità più bassa).

  4. Nega predefinita (se nessuna politica corrisponde): questo comportamento di negazione per impostazione predefinita garantisce che siano consentite solo connessioni esplicitamente consentite, mantenendo un elevato livello di sicurezza.

Migrazione

  • Se il cluster utilizza attualmente una soluzione di terze parti per la gestione delle policy di rete di Kubernetes, è possibile utilizzare le stesse policy con il plug-in CNI di Amazon VPC per Kubernetes. Tuttavia, è necessario rimuovere la soluzione esistente in modo che non gestisca le stesse policy.

avvertimento

Dopo aver rimosso una soluzione di policy di rete, si consiglia di sostituire tutti i nodi a cui era stata applicata la soluzione di policy di rete. Questo perché le regole del traffico potrebbero essere ignorate da un pod della soluzione se questa si interrompe all’improvviso.

Installazione

  • La funzionalità di policy di rete crea e richiede una PolicyEndpoint Custom Resource Definition (CRD) denominata policyendpoints.networking.k8s.aws. Gli oggetti PolicyEndpoint della Custom Resource sono gestiti da Amazon EKS. È sconsigliabile modificare o eliminare queste risorse.

  • Se si eseguono pod che utilizzano le credenziali IAM del ruolo di istanza o si connettono all’IMDS EC2, occorre accertarsi che non siano presenti policy di rete che bloccherebbero l’accesso all’IMDS EC2. Potrebbe essere necessario aggiungere una policy di rete per consentire l’accesso all’IMDS EC2. Per ulteriori informazioni, consulta Metadati dell’istanza e dati dell’utente nella Guida per l’utente di Amazon EC2 per le istanze Linux.

    I pod che utilizzano i ruoli IAM per gli account di servizio o EKS Pod Identity non accedono all’IMDS EC2.

  • Il plug-in CNI di Amazon VPC per Kubernetes non applica le policy di rete alle interfacce di rete aggiuntive per ogni pod, ma solo all’interfaccia principale per ogni pod (eth0). Ciò influisce sulle seguenti architetture:

    • Pod IPv6 con la variabile ENABLE_V4_EGRESS impostata su true. Questa variabile abilita la funzionalità di uscita IPv4 per connettere i pod IPv6 a endpoint IPv4 come quelli esterni al cluster. La funzionalità di uscita IPv4 opera creando un’interfaccia di rete supplementare con un indirizzo IPv4 di loopback locale.

    • In caso di utilizzo di plugin di rete concatenati come Multus. Poiché questi plug-in aggiungono interfacce di rete a ciascun pod, le policy di rete non vengono applicate ai plug-in di rete concatenati.