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 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 pod-to-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 di porta all'interno del tuo cluster Amazon EKS. Le policy di rete standard sono limitate al 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 policy per imporre la separazione della rete.

Esempio

Nella policy riportata di seguito, il traffico in uscita dai pod delle webapp nello spazio dei nomi 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 nello spazio dei nomi. role: webapp sun

  • Traffico consentito: pod con l'etichetta role: frontend nello spazio dei nomi 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 del cluster, indipendentemente dal relativo 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 una posizione di sicurezza di rete predefinita 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 politica riportata di seguito, puoi bloccare in modo esplicito il traffico del cluster proveniente da altri namespace per impedire l'accesso di rete a uno spazio dei nomi di carico di lavoro riservato.

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 politiche 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 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 policy di rete si applicano solo a uno IPv4 o più IPv6 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

  • Le policy di rete vengono applicate solo ai pod che fanno parte di un’implementazione. Ai pod autonomi che non dispongono di un set metadata.ownerReferences non possono essere applicate policy di rete.

  • È 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. Politiche di livello di amministrazione (valutate per prime): tutte le politiche di livello amministratore ClusterNetworkPolicies vengono valutate prima di qualsiasi altra politica. All'interno del livello di amministrazione, le politiche vengono elaborate in ordine di priorità (prima il numero di priorità più basso). Il tipo di azione determina cosa succede dopo.

    • Nega azione (priorità massima): quando una politica di amministrazione con un'azione Rifiuta 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 politiche a livello di namespace.

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

    • Pass action: le azioni Pass Action nelle policy del livello di amministrazione delegano il processo decisionale ai livelli inferiori. Quando il traffico corrisponde a una regola Pass, la valutazione salta tutte le regole rimanenti del livello di amministratore per quel traffico e passa direttamente al livello. NetworkPolicy Ciò consente agli amministratori di delegare in modo esplicito il controllo di determinati modelli di traffico ai team applicativi. Ad esempio, è possibile utilizzare le regole Pass per delegare la gestione del traffico all'interno del namespace agli amministratori del namespace, mantenendo al contempo controlli rigorosi sull'accesso esterno.

  2. Livello di policy di rete: se nessuna politica del livello di amministratore corrisponde a Deny o Allow, o se è stata soddisfatta un'azione Pass, vengono successivamente valutate le risorse con ambito namespace. NetworkPolicy Queste politiche forniscono un controllo granulare all'interno dei singoli namespace e sono gestite dai team delle applicazioni. Namespace-scoped le politiche possono essere solo più restrittive delle politiche di amministrazione. Non possono ignorare la decisione di rifiuto di una politica di amministrazione, ma possono limitare ulteriormente il traffico consentito o approvato dai criteri di amministrazione.

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

  4. Rifiuto predefinito (se nessuna policy corrisponde): questo comportamento di negazione per impostazione predefinita garantisce che siano consentite solo le 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.