**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](https://kubernetes.io/docs/concepts/services-networking/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](https://docs.aws.amazon.com/it_it/eks/latest/userguide/images/evaluation-order.png) È 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](security-groups-for-pods.md). 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. 1. **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. 1. **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). 1. **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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) 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.