Procedure consigliate per la sicurezza di rete per Servizio Azure Kubernetes (AKS)

Kubernetes, per impostazione predefinita, opera come rete flat in cui tutti i pod possono comunicare liberamente tra loro. Questa connettività senza restrizioni può essere utile per gli sviluppatori, ma comporta rischi significativi per la sicurezza quando le applicazioni vengono ridimensionate. Si supponga che un'organizzazione distribuisca più microservizi, ognuno dei quali gestisca dati sensibili, transazioni dei clienti o operazioni back-end. Senza restrizioni, qualsiasi pod compromesso potrebbe accedere a dati non autorizzati o interrompere i servizi.

La sicurezza di rete di produzione richiede controlli sia per la comunicazione del carico di lavoro che per l'esposizione degli endpoint. Usare i criteri di rete Kubernetes per limitare il traffico tra carichi di lavoro, scegliere il tipo di servizio Kubernetes meno esposto che soddisfa i requisiti di ogni applicazione e limitare l'accesso al server API Kubernetes.

Pianificare l'esposizione del servizio e del cluster

Iniziare con l'accesso privato e aggiungere l'esposizione pubblica solo quando il carico di lavoro lo richiede. I criteri di rete sono complementari, ma non sostituiscono, i servizi Kubernetes, i controlli in ingresso, i web application firewall (WAF) o i controlli di accesso al server API.

Usare le linee guida seguenti per pianificare un cluster AKS di produzione:

Servizi usati solo all'interno del cluster

Raccomandazione: usare un ClusterIP servizio, ovvero il tipo di servizio predefinito.

Applicare criteri di rete in entrata e in uscita in modo che solo i pod e i namespace autorizzati possano raggiungere i pod di backend del servizio.

Servizi usati da una rete privata

Raccomandazione: usare un servizio interno LoadBalancer o un controller di ingresso interno.

L'INDIRIZZO IP privato limita l'accesso alle reti con connettività alla rete virtuale. Limitare anche le reti di origine con gruppi di sicurezza di rete, firewall e criteri di rete.

Servizi pubblici non HTTP o non HTTPS

Raccomandazione: usare un servizio pubblico LoadBalancer solo quando è necessario l'accesso esterno diretto.

Limitare gli intervalli IP di origine consentiti, esporre solo le porte necessarie ed evitare di usare NodePort come meccanismo di esposizione diretta alla produzione.

Applicazioni HTTP o HTTPS pubbliche

Raccomandazione: posizionare i servizi dietro un controller di ingresso o un'implementazione dell'API gateway invece di assegnare un indirizzo IP pubblico a ogni servizio.

Centralizzare la terminazione TLS, il routing, l'autenticazione e la gestione degli indirizzi IP pubblici. Configurare i servizi back-end come ClusterIP quando non è necessario l'accesso esterno diretto.

Api e applicazioni Web con connessione Internet

Raccomandazione: inserire un web application firewall (WAF) Azure davanti al livello di ingresso, ad esempio con gateway applicazione di Azure per contenitori.

Usare regole WAF gestite e personalizzate per proteggere da exploit Web comuni. Limita l'accesso diretto all'origine di ingresso in modo che i client non possano aggirare il WAF.

Server API di Kubernetes

Raccomandazione: Preferire un cluster AKS privato quando gli amministratori e l'automazione possono connettersi tramite una rete privata.

Un cluster privato mantiene il traffico del server API su un endpoint privato. Pianificare DNS, VPN, ExpressRoute, peering o un host di gestione protetto per l'accesso amministrativo.

Server API Kubernetes pubblico

Raccomandazione: se è necessario un endpoint pubblico, configurare gli intervalli IP autorizzati del server API e usare Microsoft Entra ID con RBAC con privilegi minimi.

Consenti solo intervalli IP di origine noti per la gestione e l'automazione. Non lasciare aperto il server API a tutti gli indirizzi IP di origine. Valutare API Server VNet Integration quando la configurazione prevede connettività di rete privata o la modifica dell'accesso pubblico dopo la creazione del cluster.

Eseguire l'inventario di ogni percorso in ingresso prima della distribuzione e documentare se deve essere interno al cluster, privato alle reti connesse o pubblico. Evitare percorsi pubblici paralleli che aggirano il livello di ingresso approvato e il WAF. Riserva gli indirizzi IP pubblici per gli endpoint per i quali è documentata la necessità di accesso a Internet ed esamina periodicamente gli endpoint pubblici LoadBalancer, gli endpoint di ingresso e gli endpoint del server API per verificarne la continua necessità.

Che cos'è un criterio di rete Kubernetes?

Un criterio di rete Kubernetes è un set di regole che controllano il modo in cui i pod comunicano tra loro e con i servizi esterni. Fornisce un controllo granulare sul traffico di rete, consentendo agli amministratori di applicare sicurezza e segmentazione a livello di spazio dei nomi. Implementando i criteri di rete, si ottengono:

• Comportamento di sicurezza più forte: impedire lo spostamento laterale non autorizzato all'interno del cluster.
• Conformità e governance: applicare i requisiti normativi controllando i percorsi di comunicazione.
• Raggio di esplosione ridotto: limitare l'impatto di un carico di lavoro compromesso limitandone l'accesso alla rete.

I criteri di rete inizialmente gestiti al livello 3 (IP) e al livello 4 (TCP/UDP) del modello OSI, abilitano il controllo di base sulle comunicazioni da pod a pod e esterne. I motori avanzati dei criteri di rete, ad esempio Cilium, estendono l'imposizione dei criteri al livello 7 (livello applicazione), consentendo un maggiore controllo sul traffico delle applicazioni per le applicazioni native del cloud moderne.

I criteri di rete sono limitati al namespace, il che significa che ogni criterio si applica ai carichi di lavoro all'interno di un namespace specifico. I componenti principali di un criterio di rete includono:

• Selettore pod: definisce i pod a cui si applicano i criteri in base alle etichette.
• Regole di ingresso: specificare le connessioni in ingresso consentite.
• Regole di uscita: specificare le connessioni in uscita consentite.
• Tipi di criteri: Definisci se i criteri si applicano al traffico in ingresso, in uscita o a entrambi.

Fondamenti per la creazione di criteri di rete efficaci

I criteri di rete efficaci richiedono la comprensione dell'architettura dell'applicazione, dei modelli di traffico e dei requisiti di sicurezza prima di scrivere configurazioni.

Informazioni sulla connettività del carico di lavoro

Prima di implementare i criteri di rete, è necessario avere visibilità sul modo in cui i carichi di lavoro comunicano tra loro e con i servizi esterni. Questo passaggio garantisce che i criteri non blocchino inavvertitamente il traffico critico limitando in modo efficace l'esposizione non necessaria.

• Usare gli strumenti di visibilità: oltre ai requisiti di rete forniti dal team dell'applicazione, usare strumenti come Cilium Hubble e Retina per analizzare il traffico da pod a pod, identificare quali servizi devono comunicare e definire le dipendenze in ingresso e in uscita. Ad esempio, un front-end potrebbe dover raggiungere un'API back-end, ma non deve comunicare direttamente con un database.

• Usare le etichette nei criteri di rete: tradizionalmente, i criteri di sicurezza di rete si basano su indirizzi IP statici per definire le regole di traffico. Questo approccio è problematico in Kubernetes perché i pod sono temporanei, creati ed eliminati di frequente, spesso con indirizzi IP assegnati dinamicamente. La gestione delle regole di sicurezza basata su indirizzi IP in continua evoluzione richiede aggiornamenti continui, rendendo inefficiente e soggetta a errori la gestione dei criteri.

Le etichette risolveranno questa sfida fornendo un modo stabile per raggruppare i carichi di lavoro. Invece di basarsi su indirizzi IP fissi, i criteri di rete Kubernetes usano etichette per definire regole di sicurezza coerenti anche quando i pod vengono riavviati o spostati tra i nodi. Ad esempio, un criterio può consentire la comunicazione tra pod etichettati app: frontend e app: backend, assicurando i flussi di traffico previsti indipendentemente dalle modifiche ip dei pod. Questo approccio basato su etichette è fondamentale per ottenere una sicurezza di rete scalabile basata sulle finalità in ambienti nativi del cloud.

Una strategia di etichettatura ben definita semplifica la gestione dei criteri, riduce le configurazioni errate e migliora l'applicazione della sicurezza tra i cluster.

• Definire la microsegmentazione: l'organizzazione dei carichi di lavoro in zone di sicurezza, ad esempio front-end, back-end e zone di database, consente di applicare il principio dei privilegi minimi. Ad esempio, isolare i microservizi che gestiscono le transazioni dei clienti da applicazioni per utilizzo generico.

Approccio di sicurezza a più livelli per Kubernetes

Affidarsi esclusivamente ai criteri di rete Kubernetes di base potrebbe non essere sufficiente per tutte le esigenze di sicurezza. Un approccio a più livelli garantisce una protezione completa tra diversi livelli di comunicazione di rete.

• Criteri L3/L4: controllare il traffico in base alle etichette dei pod e agli spazi dei nomi a livello di IP, porta e protocollo.
• Criteri basati su FQDN: limitare il traffico in uscita a domini esterni specifici, assicurando che i carichi di lavoro possano raggiungere solo i servizi esterni approvati( ad esempio, consentendo solo l'accesso a microsoft.com per le chiamate API).
• Criteri di livello 7: filtrare le richieste in base a metodi, intestazioni e percorsi HTTP per proteggere le API e applicare criteri di sicurezza a livello di applicazione.

Gestire i criteri di rete

I team che gestiscono i criteri di rete dipendono dalla struttura e dai requisiti di sicurezza dell'organizzazione. Un approccio bilanciato consente ai team di sicurezza e agli sviluppatori di applicazioni di collaborare in modo efficace.

• Amministrazione centralizzata della sicurezza: i team di sicurezza o di rete devono definire criteri di base per applicare i requisiti di sicurezza globali, ad esempio le regole di negazione predefinite o le restrizioni basate sulla conformità.
• Autonomia degli sviluppatori con protezioni: I team delle applicazioni devono essere in grado di definire politiche di rete specifiche per servizio all'interno dei namespace, consentendo la sicurezza mantenendo al contempo l'agilità.
• Gestione del ciclo di vita dei criteri: la revisione e l'aggiornamento periodici dei criteri garantisce che la sicurezza rimanga allineata alle architetture delle applicazioni in continua evoluzione. Gli strumenti di osservabilità consentono di rilevare errori di configurazione dei criteri e regole mancanti.

Esempio: Proteggere un'applicazione Web multilivello con criteri di rete

Passaggio 1: Comprendere la connettività del carico di lavoro

Usare Cilium Hubble per osservare il modo in cui i pod comunicano.

Eseguire il mapping della connettività necessaria:

Passaggio 2: Applicare etichette per l'imposizione dei criteri

Etichettando correttamente i carichi di lavoro, i criteri possono rimanere stabili anche se gli INDIRIZZI IP dei pod cambiano.

• app: frontend per i pod dell'interfaccia utente.
• app: backend per i pod API.
• app: database per i pod di database.

Passaggio 3: Implementare criteri di rete a livello di applicazione

Questo esempio usa due livelli di criteri di rete: criteri L3/L4 per controllare il traffico tra microservizi e un criterio FQDN (Domain Name) completo per controllare il traffico in uscita verso un gateway di pagamento esterno.

Consentire il traffico dal frontend al backend

Applicare criteri in uscita e in ingresso in modo che i pod front-end possano raggiungere i pod back-end solo sulla porta TCP 8080.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Consentire il traffico del backend verso il database

Applicare criteri in uscita e in ingresso in modo che i pod back-end possano raggiungere i pod del database solo sulla porta TCP 5432.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 5432

Consentire il traffico del back-end verso un'API di pagamento esterna

Applica una policy di rete Cilium in modo che i pod backend possano risolvere e connettersi a payments.example.com solo tramite la porta TCP 443.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-payment-api
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchName: payments.example.com
    - toFQDNs:
        - matchName: payments.example.com
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

Passaggio 4: Gestire e gestire i criteri

La tabella seguente riepiloga i livelli dei criteri che i team devono applicare tra i cluster.

Assicurarsi che i criteri di rete delle applicazioni siano conformi ai requisiti di base, della piattaforma e della sicurezza, consentendo al tempo stesso la comunicazione del carico di lavoro necessaria.

Azure CNI con tecnologia Cilium

Azure Container Network Interface (CNI) basato su Cilium usa eBPF (extended Berkeley Packet Filter) per fornire funzionalità di rete, osservabilità e sicurezza elevate per i carichi di lavoro Kubernetes. A differenza delle reti cni tradizionali che si basano sul filtro dei pacchetti basati su iptables, Azure CNI basato su Cilium usa eBPF per operare a livello di kernel, abilitando l'applicazione efficiente e scalabile dei criteri di rete. Cilium è il motore dei criteri di rete consigliato per i carichi di lavoro Linux in Servizio Azure Kubernetes (AKS). Per altre informazioni sugli altri motori supportati e sul supporto della piattaforma offerto da ciascuno, vedi Opzioni dei criteri di rete in AKS. Il servizio Azure Kubernetes integra Cilium come componente gestito, semplificando l'applicazione della sicurezza di rete. Gli amministratori possono definire direttamente le risorse CiliumNetworkPolicy nei propri cluster AKS senza richiedere controller esterni.

Le identità di Cilium estendono l'applicazione dei criteri basati su etichette. I cluster di grandi dimensioni con varianza elevata dei pod potrebbero riscontrare problemi di scalabilità perché i nodi devono aggiornare costantemente i filtri IP. Le identità Cilium sono associate alle etichette e consentono di avviare le connessioni non appena l'identità viene risolta, senza attendere gli aggiornamenti dei filtri su ciascun nodo.

Con Azure CNI con tecnologia Cilium, non è necessario installare un motore di criteri di rete separato, ad esempio Azure Network Policy Manager o Calico.

Creare un cluster AKS con Azure CNI basato su Cilium

L'esempio seguente crea un cluster AKS con Azure CNI Overlay basato su Cilium. L'opzione --network-plugin-mode overlay configura la rete overlay di Azure CNI, --pod-cidr 192.168.0.0/16 assegna l'intervallo di indirizzi IP dei pod e --network-dataplane cilium seleziona Cilium come piano dati. Le opzioni di creazione del cluster e i valori degli indirizzi possono differire per altre configurazioni di rete del servizio Azure Kubernetes. Usare i valori appropriati per la configurazione di rete.

az aks create \
  --name <clusterName> \
  --resource-group <resourceGroupName> \
  --location <location> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16 \
  --network-dataplane cilium \
  --generate-ssh-keys

Risorse e componenti delle policy di rete di Cilium

Con Azure CNI basato su Cilium, è possibile configurare i criteri di rete in modo nativo in Kubernetes usando due formati disponibili:

• La risorsa standardNetworkPolicy, che supporta i criteri L3 e L4 in ingresso o in uscita del pod.
• Il formato CiliumNetworkPolicy esteso, disponibile come CustomResourceDefinition che supporta la specifica dei criteri a livelli 3-7 per il traffico in ingresso e in uscita.

Usare queste definizioni di risorse personalizzate per definire i criteri di sicurezza. Kubernetes distribuisce automaticamente i criteri a tutti i nodi del cluster.

I criteri di rete sono costituiti da diversi componenti chiave:

• Pod selector: specifica i pod a cui si applica il criterio utilizzando le etichette.

• Tipi di criteri: determina se i criteri si applicano ai dati in ingresso (traffico in ingresso), in uscita (traffico in uscita) o a entrambi.

• Regole di ingresso: definisce le origini consentite (pod, spazi dei nomi o intervalli IP) e porte.

• Regole di uscita: definisce le destinazioni e le porte consentite.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: frontend-egress
    namespace: default
  spec:
    podSelector:
      matchLabels:
        app: frontend
    policyTypes:
      - Egress
    egress:
      - to:
          - podSelector:
              matchLabels:
                app: backend
        ports:
          - protocol: TCP
            port: 8080
  

Criteri di rete avanzati con ACNS

servizio Azure Kubernetes offre Advanced Container Networking Services (ACNS), una suite di servizi progettata per migliorare le capacità di rete dei cluster AKS.

Una funzionalità chiave di ACNS è La sicurezza di rete dei contenitori, che offre funzionalità di sicurezza avanzate per proteggere i carichi di lavoro in contenitori. Queste funzionalità includono i criteri di filtro dei nomi di dominio completi (FQDN) e I criteri di livello 7 (L7) per il controllo granulare sul traffico in uscita e sulla comunicazione a livello di applicazione.

La sicurezza di rete dei contenitori è un'offerta a pagamento per i pool di nodi Linux che richiede Azure CNI con tecnologia Cilium e Kubernetes versione 1.29 o successiva. Per informazioni dettagliate sui prezzi, vedere Prezzi avanzati di Servizi di rete dei contenitori.

Proteggere il traffico in uscita con il filtro FQDN

Tradizionalmente, i criteri di rete Kubernetes si basano sugli indirizzi IP. Negli ambienti dinamici in cui gli indirizzi IP dei pod cambiano frequentemente, questi criteri possono essere difficili da gestire. Il filtro FQDN consente di definire criteri con nomi di dominio anziché indirizzi IP, semplificando il controllo del traffico.

Il filtro FQDN richiede un cluster AKS che usa Azure CNI supportato da Cilium, esegue Kubernetes 1.29 o versione successiva e ha ACNS abilitato. Configurare un CiliumNetworkPolicy oggetto per definire i domini a cui possono accedere i pod selezionati.

Per abilitare Advanced Container Networking Services (ACNS) in Servizio Azure Kubernetes (AKS), usare il --enable-acns flag .

Esempio: Abilitare i servizi di rete avanzati per container in un cluster esistente

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns

Questo comando abilita ACNS, incluso il filtro FQDN, in un cluster esistente che usa il piano dati Cilium.

Esempio: Creare criteri di rete che consentano il traffico verso bing.com e i relativi sottodomini

I criteri seguenti consentono ai pod selezionati di risolvere e connettersi a bing.com e ai relativi sottodomini. Le regole dns consentono la risoluzione dei nomi e le regole toFQDNs consentono le connessioni in uscita verso gli indirizzi risolti.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-bing-fqdn"
spec:
  endpointSelector:
    matchLabels:
      app: demo-container
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchName: "bing.com"
              - matchPattern: "*.bing.com"
    - toFQDNs:
        - matchName: "bing.com"
        - matchPattern: "*.bing.com"

Protezione e sicurezza per le API con criteri L7

I criteri di livello 7 (L7) nel servizio Azure Kubernetes usano CiliumNetworkPolicy risorse per filtrare il traffico dell'applicazione in base a attributi quali metodi e percorsi HTTP, percorsi gRPC e argomenti Kafka. Richiedono ACNS in un cluster del servizio Azure Kubernetes che usa Azure CNI basato su Cilium. I criteri di rete standard controllano il traffico al livello 3 (IP) e al livello 4 (TCP/UDP), ma non controllano questi attributi a livello di applicazione.

I criteri di livello 7 (L7) offrono i vantaggi e le funzionalità seguenti:

• Sicurezza granulare delle API: applicare criteri basati su dati di richiesta HTTP, gRPC o Kafka, anziché solo indirizzi IP e porte.
• Superficie di attacco ridotta: impedire l'accesso non autorizzato e attenuare gli attacchi basati sull'API filtrando il traffico a livello di applicazione.
• Conformità e controllo: garantire la conformità agli standard di sicurezza registrando e controllando interazioni API specifiche.
• Gestione semplificata delle policy: evita il peso operativo di ulteriori sidecar proxy sfruttando i controlli L7 integrati di Cilium.

I criteri L7 supportano protocolli HTTP, HTTPS, gRPC e Kafka.

Esempio: Attivare i criteri ACNS e L7 su un cluster esistente

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns \
  --acns-advanced-networkpolicies L7

Questo comando abilita l'imposizione dei criteri ACNS e L7 nel cluster esistente. L'impostazione su --acns-advanced-networkpoliciesL7 abilita anche il filtro FQDN.

Esempio: consentire solo le richieste GET a /api dal pod front-end al servizio back-end sulla porta 8080

I criteri seguenti consentono ai pod front-end selezionati di inviare solo GET le richieste a /api sulla porta TCP 8080 degli endpoint back-end selezionati.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

Strategie dei criteri di rete per i workload di AKS

Le strategie seguenti consentono di applicare regole di traffico con privilegi minimi nei carichi di lavoro del servizio Azure Kubernetes.

Adottare un modello di Zero Trust

Per impostazione predefinita, Kubernetes consente la comunicazione senza restrizioni tra tutti i pod in un cluster. Un approccio Zero Trust richiede di negare il traffico per impostazione predefinita e consentire in modo esplicito i percorsi di comunicazione necessari. Un criterio di rete predefinito di negazione totale garantisce che tra i carichi di lavoro fluisca solo il traffico necessario.

Esempio di criteri deny-all:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Segmentazione di spazio dei nomi e multi-tenancy

Negli ambienti multi-tenant gli spazi dei nomi consentono di isolare i carichi di lavoro. I diversi team gestiscono in genere le applicazioni all'interno di spazi dei nomi dedicati, garantendo l'isolamento logico tra i carichi di lavoro. Questa separazione è fondamentale quando più applicazioni vengono eseguite l'una accanto all'altra. L'applicazione dei criteri di rete nell'ambito dello spazio dei nomi è spesso il primo passaggio per la protezione dei carichi di lavoro, in quanto impedisce lo spostamento laterale senza restrizioni tra le applicazioni gestite da team diversi.

Ad esempio, limitare tutto il traffico in ingresso a uno spazio dei nomi, consentendo solo il traffico dallo stesso spazio dei nomi:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

Microsegmentazione per l'isolamento del carico di lavoro

Sebbene la segmentazione basata su spazio dei nomi sia un primo passaggio essenziale per proteggere i cluster Kubernetes multi-tenant, la microsegmentazione a livello di applicazione offre un controllo granulare sul modo in cui i carichi di lavoro interagiscono all'interno di uno spazio dei nomi. L'isolamento dello spazio dei nomi da solo non impedisce comunicazioni impreviste o non autorizzate tra applicazioni diverse all'interno dello stesso spazio dei nomi. Questo è il punto in cui la segmentazione a livello di pod diventa critica.

Ad esempio, se un servizio front-end deve comunicare solo con un servizio back-end all'interno dello stesso spazio dei nomi, un criterio che usa etichette pod può applicare questa restrizione:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-to-backend
  namespace: team-a
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080

Ciò impedisce ai pod front-end di stabilire connessioni indesiderate ad altri servizi, riducendo il rischio di accessi non autorizzati o di spostamento laterale all'interno dello spazio dei nomi.

Combinando l'isolamento a livello di spazio dei nomi con criteri a livello di applicazione con granularità fine, i team possono implementare un modello di sicurezza multilivello che impedisce il traffico non autorizzato, consentendo al contempo la comunicazione necessaria per le funzionalità dell'applicazione.

Approccio alla sicurezza a più livelli

La sicurezza di rete deve essere implementata nei livelli, combinando più livelli di imposizione:

• Criteri L3/L4: limitare il traffico a livello di IP e porta (ad esempio: consentire il traffico TCP sulla porta 443).
• Filtro basato su FQDN: limitare la comunicazione esterna in base ai nomi di dominio anziché agli indirizzi IP.
• Criteri L7: controllare la comunicazione in base agli attributi a livello di applicazione (ad esempio: consentire solo le richieste HTTP GET a percorsi API specifici).

Ad esempio, un criterio Cilium L7 può limitare i servizi front-end solo per inviare richieste GET all'API back-end:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

Ciò impedisce al front-end di effettuare richieste POST o DELETE, limitando la superficie di attacco.

Integra RBAC con la gestione delle policy di rete

Il controllo degli accessi in base al ruolo svolge un ruolo fondamentale per garantire che solo gli utenti o i team autorizzati possano creare, modificare o eliminare criteri di rete. Senza controlli di accesso appropriati, un criterio non configurato correttamente potrebbe esporre i carichi di lavoro ad accessi non autorizzati o bloccare involontariamente il traffico critico dell'applicazione.

Sfruttando l'RBAC di Kubernetes in combinazione con le policy di rete, le organizzazioni possono far rispettare la separazione dei ruoli tra gli amministratori della piattaforma, i team di sicurezza e gli sviluppatori applicativi. Un approccio tipico è:

• Definire i criteri di sicurezza di base tramite i team della piattaforma o della sicurezza per applicare la conformità e limitare l'accesso esterno.
• Concedi ai team applicativi autorizzazioni limitate per creare o aggiornare le policy di rete solo per i rispettivi namespace.

Ad esempio, il criterio RBAC seguente consente agli sviluppatori di creare e modificare i criteri di rete, ma solo all'interno del namespace assegnato:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: network-policy-editor
  namespace: team-a
rules:
  - apiGroups: ["networking.k8s.io"]
    resources: ["networkpolicies"]
    verbs: ["get", "list", "create", "update", "delete"]

Associare questo ruolo a un team specifico usando :RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-network-policy-binding
  namespace: team-a
subjects:
  - kind: User
    name: developer@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: network-policy-editor
  apiGroup: rbac.authorization.k8s.io

Limitando le modifiche dei criteri di rete ai team e agli spazi dei nomi designati, le organizzazioni possono impedire configurazioni accidentali o modifiche non autorizzate, consentendo comunque agli sviluppatori di implementare criteri di sicurezza specifici dell'applicazione.

Questo approccio rafforza il principio dei privilegi minimi garantendo al tempo stesso che le strategie di segmentazione di rete rimangano coerenti, sicure e allineate ai criteri dell'organizzazione.

Soluzioni legacy e di terze parti

Azure Network Policy Manager (NPM)

Gestione criteri di rete di Azure è una soluzione legacy per l'applicazione di criteri di rete Kubernetes nel servizio Azure Kubernetes.

Per i nodi Linux, Microsoft consiglia la transizione da NPM a Cilium, che offre prestazioni, scalabilità e sicurezza avanzata migliori tramite l'imposizione basata su eBPF. Per indicazioni sulla migrazione, vedere Eseguire l'aggiornamento da Azure Network Policy Manager a Cilium.

NetworkPolicysupporto per i nodi di Windows

Azure CNI basato su Cilium supporta solo i nodi Linux. Per i carichi di lavoro Windows, AKS supporta Calico, che è integrato in AKS per semplificare la distribuzione. È possibile abilitarlo usando il flag --network-policy calico durante la creazione di un cluster. NPM supporta anche i nodi Windows fino al 30 settembre 2026, ma le nuove sottoscrizioni non possono più registrare il feature flag necessario per abilitarlo.

Calico open source: soluzione di terze parti

Calico open source è una soluzione di terze parti per applicare i criteri di rete Kubernetes nei nodi Linux e Windows. Tigera mantiene il progetto Calico e le relative immagini. Il supporto Microsoft è limitato a garantire che Calico sia integrato con AKS e funzioni come previsto sulla piattaforma. Rivolgere alla community open source di Calico o a Tigera i bug del progetto upstream, le richieste di nuove funzionalità e le richieste di assistenza per la risoluzione dei problemi che vanno oltre l'integrazione con AKS.

Per i nodi Linux, Microsoft consiglia di usare Cilium per l'imposizione dei criteri di rete. Per Windows nodi, Microsoft consiglia di usare Calico.

Conclusione

I criteri di rete sono una parte fondamentale della sicurezza di Kubernetes, consentendo alle organizzazioni di controllare il flusso del traffico, applicare l'isolamento del carico di lavoro e ridurre la superficie di attacco. Man mano che gli ambienti nativi del cloud si evolvono, l'uso esclusivo dei criteri di livello 3/4 di base non è più sufficiente. Soluzioni avanzate, ad esempio il filtro di livello 7 e i criteri basati su FQDN, offrono la sicurezza granulare e la flessibilità necessarie per proteggere le applicazioni moderne.

Seguendo procedure come un modello di Zero Trust e microsegmentazione e adottando Azure CNI con tecnologia Cilium, i team possono migliorare la sicurezza mantenendo al contempo l'efficienza operativa. Gli approcci moderni basati sull'osservabilità consentono di proteggere i carichi di lavoro man mano che la rete Kubernetes si evolve.