Procedure consigliate per la connettività e la sicurezza di rete in Servizio Azure Kubernetes (AKS)

Durante la creazione e la gestione dei cluster in Servizio Azure Kubernetes (AKS), è possibile fornire connettività di rete per i nodi e le applicazioni. Queste risorse di rete includono gli intervalli di indirizzi IP, i servizi di bilanciamento del carico e i controller in ingresso.

Questo articolo sulle procedure consigliate è incentrato sulla sicurezza e la connettività di rete per gli operatori del cluster. In questo articolo vengono illustrate le operazioni seguenti:

Scegliere il modello di rete appropriato

Materiale sussidiario sulle procedure consigliate

Usare Azure overlay CNI per la maggior parte degli scenari. Se i carichi di lavoro richiedono l'accesso diretto agli IP dei pod dalle reti collegate, usare una rete piatta con Azure CNI Pod Subnet.

Le reti virtuali forniscono la connettività di base per consentire ai clienti e ai nodi del servizio Azure Kubernetes di accedere alle applicazioni. Esistono due diversi modi per distribuire i cluster del servizio Azure Kubernetes nelle reti virtuali:

• Rete di sovrapposizione: Azure CNI Overlay assegna gli indirizzi IP dei pod da un CIDR di pod separato. Il traffico che lascia il cluster viene convertito nell'indirizzo IP del nodo e i pod non sono direttamente accessibili dai rispettivi indirizzi IP privati dalle reti connesse.
• Rete piatta: Azure CNI Pod Subnet o legacy Azure CNI Node Subnet assegnano gli indirizzi IP dei pod dallo spazio della rete virtuale. I pod possono essere raggiunti dai rispettivi indirizzi IP privati dalle reti connesse.

Per altre informazioni sulla selezione di un modello di rete, vedere Pianificare la rete dei pod per AKS.

Panoramica della rete CNI Azure

Azure CNI fornisce la gestione degli indirizzi IP e la connettività per pod e nodi. L'opzione IPAM è separata dal data plane di rete. Ad esempio, è possibile usare Azure CNI basato su Cilium con Azure CNI Overlay o un'opzione di rete flat.

Il diagramma seguente mostra due nodi del servizio Azure Kubernetes, ognuno connesso tramite un bridge di rete a una rete virtuale condivisa Azure.

Azure rete CNI consente la separazione del controllo e della gestione delle risorse. Dal punto di vista della sicurezza, è spesso preferibile che siano team diversi a gestire e proteggere tali risorse. Le caratteristiche di connettività dipendono dal modello di rete. I pod sovrapposti avviano le connessioni alla rete virtuale e alle risorse locali tramite l'indirizzo IP del nodo. I pod di rete flat possono comunicare direttamente con le risorse connesse tramite gli indirizzi IP privati.

Quando si usa la rete Azure CNI, la risorsa di rete virtuale si trova in un gruppo di risorse separato rispetto al cluster AKS. Delegare le autorizzazioni per l'identità del cluster del servizio Azure Kubernetes per accedere e gestire queste risorse. L'identità usata dal cluster del servizio Azure Kubernetes deve avere almeno le autorizzazioni di Collaboratore di rete per la subnet all'interno della rete virtuale.

Se si vuole definire un ruolo personalizzato invece di usare il ruolo predefinito Collaboratore di rete, sono necessarie le autorizzazioni seguenti:

Per impostazione predefinita, il servizio Azure Kubernetes usa un'identità gestita per l'identità del cluster. Tuttavia, è possibile usare un'entità servizio.

• Per altre informazioni sulla delega dell'entità servizio del servizio Azure Kubernetes, vedere Delegare l'accesso ad altre risorse di Azure.
• Per altre informazioni sulle identità gestite, vedere Usare le identità gestite.

Pianificare gli intervalli di indirizzi in base al modello di rete. Tenere presenti i criteri seguenti:

• Con Azure CNI Overlay, ridimensionare la subnet per i nodi e usare un CIDR privato separato per i pod. Ogni nodo riceve uno spazio di indirizzi /24 dal blocco CIDR del pod.
• Con una rete piatta, dimensionare le subnet della rete virtuale sia per i nodi sia per i pod. Azure CNI Pod Subnet usa subnet separate per nodi e pod, mentre Azure CNI Node Subnet legacy usa un'unica subnet per entrambi.
• Evitare di usare intervalli di indirizzi IP che si sovrappongono alle risorse di rete esistenti.
  • È necessario consentire la connettività alle reti locali o con peering in Azure.
• Per gestire gli eventi di scalabilità orizzontale o gli aggiornamenti del cluster, sono necessari indirizzi IP aggiuntivi disponibili nella subnet assegnata.
  • Questo spazio di indirizzi aggiuntivo è particolarmente importante se si usano contenitori Windows Server, poiché questi pool di nodi richiedono un aggiornamento per applicare le patch di sicurezza più recenti. Per altre informazioni sui nodi Windows Server, vedere Aggiornamento di un pool di nodi in AKS.

Per calcolare lo spazio degli indirizzi IP necessario, vedere Pianificazione degli indirizzi IP per i cluster AKS.

Quando si crea un cluster con Azure rete CNI, si specificano altri intervalli di indirizzi per il cluster, ad esempio l'indirizzo IP del servizio DNS e l'intervallo di indirizzi del servizio. In generale, assicurarsi che questi intervalli di indirizzi non si sovrappongano tra loro né a qualsiasi rete associata al cluster, incluse eventuali reti virtuali, subnet, reti on-premises e reti connesse tramite peering.

Per informazioni dettagliate su modelli di rete, limiti e dimensioni degli indirizzi, vedere Azure panoramica delle reti CNI.

Distribuire il traffico in ingresso

Materiale sussidiario sulle procedure consigliate

Per distribuire il traffico HTTP o HTTPS alle applicazioni, usare risorse e controller in ingresso. Rispetto a un servizio di bilanciamento del carico Azure, i controller di ingresso offrono funzionalità aggiuntive e possono essere gestiti come risorse Kubernetes native.

Anche se un bilanciatore del carico Azure può distribuire il traffico dei clienti alle applicazioni nel cluster AKS, è limitato nella comprensione di quel traffico. Una risorsa di bilanciamento del carico funziona al livello 4 e distribuisce il traffico in base al protocollo o alle porte.

La maggior parte delle applicazioni Web che usano HTTP o HTTPS deve usare risorse e controller di ingresso Kubernetes, che funzionano al livello 7. I controller e le risorse in ingresso possono distribuire il traffico in base all'URL dell'applicazione e gestire la terminazione TLS/SSL. Il traffico in ingresso riduce anche il numero di indirizzi IP esposti e mappati.

Con un servizio di bilanciamento del carico, ogni applicazione necessita in genere di un indirizzo IP pubblico che è stato assegnato e di cui viene eseguito il mapping al servizio nel cluster del servizio Azure Kubernetes. Con una risorsa in ingresso, un singolo indirizzo IP può distribuire il traffico a più applicazioni.

Il diagramma mostra un singolo indirizzo IP pubblico che riceve traffico esterno e un controller di ingresso che distribuisce il traffico a più servizi nel cluster del servizio Azure Kubernetes.

L'ingresso include due componenti: una risorsa di ingresso e un controller di ingresso.

Risorsa in ingresso

La risorsa in ingresso è un manifesto YAML di kind: Ingress. Definisce l'host, i certificati e le regole per instradare il traffico ai servizi in esecuzione nel cluster del servizio Azure Kubernetes.

Il manifesto YAML di esempio seguente usa la classe NGINX Ingress gestita del componente aggiuntivo di routing dell'applicazione. Distribuisce il traffico per myapp.com a uno dei due servizi, blogservice o storeservice e indirizza il cliente a un servizio o all'altro in base all'URL a cui accede.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

Il ingressClassName campo seleziona la classe in ingresso e deve corrispondere a una classe configurata in un controller di ingresso nel cluster. Il valore webapprouting.kubernetes.azure.com seleziona il controller di ingresso NGINX gestito fornito dal componente aggiuntivo di routing dell'applicazione. Sostituirlo con il nome della classe per il controller di ingresso se si usa un'implementazione diversa.

Controller di ingresso

Un controller di ingresso ospitato nel cluster viene eseguito come carico di lavoro in un nodo del servizio Azure Kubernetes e controlla le richieste in ingresso. Il traffico in ingresso viene quindi distribuito in base alle regole definite nella risorsa di ingresso associata a tale controller. Anche se il controller di ingresso più comune è basato su NGINX, il servizio Azure Kubernetes non limita l'utente a un controller specifico. È possibile usare Application Gateway for Containers, Contour, HAProxy, Traefik e altri.

È necessario pianificare i controller in ingresso ospitati nel cluster in un nodo Linux. Indicare che la risorsa deve essere eseguita in un nodo basato su Linux usando un selettore di nodo nel manifesto YAML o nella distribuzione del grafico Helm. Per altre informazioni, vedere Usare i selettori di nodo per controllare dove sono pianificati i pod nel servizio Azure Kubernetes.

Ingresso con il componente aggiuntivo di routing dell'applicazione

Il componente aggiuntivo per il routing delle applicazioni fornisce implementazioni di Ingress gestite per AKS. Per le nuove distribuzioni destinate a durare nel tempo, usa l'implementazione dell'API Gateway per il routing delle applicazioni quando soddisfa i requisiti richiesti. L'API gateway è lo standard a lungo termine per la gestione del traffico in ingresso e di livello 7 di Kubernetes.

L'implementazione di NGINX gestita offre le funzionalità seguenti:

• Configurazione semplice dei controller di ingresso NGINX gestiti basati sul controller di ingresso NGINX di Kubernetes.
• Integrazione con DNS di Azure per la gestione della zona pubblica e privata.
• Terminazione SSL con certificati archiviati in Azure Key Vault.

Per altre informazioni, vedere Configurare l'ingresso con l'API del gateway di routing dell'applicazione e l'ingresso NGINX gestito con il componente aggiuntivo di routing dell'applicazione.

Proteggere il traffico con un web application firewall (WAF)

Materiale sussidiario sulle procedure consigliate

Per analizzare il traffico in ingresso e individuare potenziali attacchi, utilizzare un firewall per applicazioni Web (WAF), ad esempio Barracuda WAF for Azure o Web application firewall di Azure su Application Gateway for Containers. Application Gateway for Containers instrada il traffico HTTP, HTTPS, gRPC, WebSocket e di inferenza dell'IA e supporta la terminazione TLS.

Un controller Ingress ospitato nel cluster viene eseguito come carico di lavoro Kubernetes nel cluster AKS e indirizza il traffico verso servizi e applicazioni. Usa alcune risorse del nodo, ad esempio CPU, memoria e larghezza di banda di rete. In ambienti di dimensioni maggiori è consigliabile considerare quanto segue:

• Eseguire l'offload di parte di questo routing del traffico o la terminazione TLS a una risorsa di rete all'esterno del cluster del servizio Azure Kubernetes.
• Analizzare il traffico in ingresso per individuare potenziali attacchi.

Il diagramma illustra il traffico esterno che passa attraverso gateway applicazione di Azure per i contenitori. Quando la protezione WAF è configurata, le regole WAF filtrano le richieste prima che Application Gateway for Containers inoltri il traffico consentito ai servizi nel cluster AKS.

Per questo livello aggiuntivo di sicurezza, un web application firewall (WAF) filtra il traffico in ingresso. Le regole gestite e personalizzate proteggono da attacchi quali il cross-site scripting e l'iniezione SQL. Application Gateway for Containers è un servizio di bilanciamento del carico e gestione del traffico di livello 7 che supporta Azure WAF.

La protezione WAF non si abilita con la sola distribuzione di Application Gateway per contenitori. È necessario creare un criterio WAF e completare entrambe le configurazioni seguenti prima che WAF controlli il traffico:

• Creare una risorsa figlio di Azure SecurityPolicy che fa riferimento al criterio WAF.
• Applica una risorsa personalizzata di Kubernetes WebApplicationFirewallPolicy che faccia riferimento allo stesso criterio WAF e abbia come destinazione la risorsa Gateway o HTTPRoute da proteggere.

Dopo aver completato entrambe le configurazioni, verifica lo stato della risorsa personalizzata e i log di WAF prima di fare affidamento sulla policy per la protezione. Per altre informazioni, vedere Web application firewall di Azure su Application Gateway for Containers.

Poiché anche altre soluzioni di terze parti eseguono queste funzioni, è possibile continuare a usare investimenti o competenze esistenti nel prodotto preferito.

Il servizio di bilanciamento del carico o le risorse di ingresso vengono continuamente eseguite nel cluster del servizio Azure Kubernetes e affinano la distribuzione del traffico. gateway applicazione di Azure per contenitori può essere gestito centralmente come controller di ingresso con una definizione di risorsa. Per iniziare, crea un Application Gateway for Containers, quindi configura separatamente la protezione WAF.

Controllare il flusso del traffico con criteri di rete

Materiale sussidiario sulle procedure consigliate

Usare i criteri di rete per consentire o negare il traffico verso i pod. Per impostazione predefinita, è consentito tutto il traffico tra i pod in un cluster. Per garantire maggiore sicurezza, definire regole che limitino la comunicazione dei pod.

I criteri di rete sono una funzionalità Kubernetes disponibile nel servizio Azure Kubernetes che consente di controllare il flusso del traffico tra pod. Si consente o nega il traffico al pod in base a impostazioni quali le etichette assegnate, lo spazio dei nomi o la porta di traffico. I criteri di rete sono un metodo nativo del cloud per controllare il flusso del traffico per i pod. Poiché i pod vengono creati dinamicamente in un cluster del servizio Azure Kubernetes, i criteri di rete necessari possono essere applicati automaticamente.

Per usare i criteri di rete in AKS, selezionare un motore dei criteri di rete che supporti i sistemi operativi dei nodi e il piano dati di rete. È possibile abilitare un motore di criteri durante la creazione del cluster o in un cluster supportato esistente.

Per i pool di nodi Linux, usare Azure CNI con tecnologia Cilium e l'applicazione dei criteri di rete Cilium predefinita. Cilium non è supportato per i pool di nodi Windows. Per i carichi di lavoro Windows, usa Calico.

I criteri di rete vengono creati come risorsa Kubernetes usando un manifesto YAML. I criteri vengono applicati ai pod definiti, con regole in ingresso o in uscita che definiscono il flusso di traffico.

L'esempio seguente applica i criteri di rete ai pod a cui è stata applicata l'etichetta app: backend. La regola di ingresso consente solo il traffico dai pod con l'app : etichetta front-end.

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

Per iniziare a usare i criteri, vedere Traffico sicuro tra pod che usano i criteri di rete in Servizio Azure Kubernetes (AKS).

Ottimizzare la risoluzione DNS con LocalDNS

Materiale sussidiario sulle procedure consigliate

Usare LocalDNS per migliorare le prestazioni e l'affidabilità del DNS e ridurre il carico sui pod CoreDNS centralizzati. LocalDNS è preconfigurato in AKS Automatic. In AKS Standard, abilitare e configurare il LocalDNS per pool di nodi.

LocalDNS distribuisce un proxy DNS come systemd servizio in ogni nodo per gestire le query DNS in locale. Per impostazione predefinita, i pod inviano tutte le query DNS ai pod CoreDNS centralizzati. Su larga scala, la centralizzazione di queste query può creare un collo di bottiglia, mentre la risoluzione locale riduce i passaggi di rete e la latenza.

LocalDNS elimina anche le voci di tabella conntrack per il traffico DNS, impedendo l'esaurimento delle tabelle conntrack e le condizioni di competizione che possono causare l'interruzione delle connessioni. Le connessioni dalla cache locale a CoreDNS vengono aggiornate a TCP, consentendo il ribilanciamento della connessione e la pulizia più rapida delle voci di rilevamento.

Per i carichi di lavoro che richiedono disponibilità DNS elevata, LocalDNS supporta la gestione di risposte memorizzate nella cache non aggiornate per una durata configurabile quando il DNS upstream non è disponibile. Questa funzionalità ottimale consente di mantenere la connettività dei pod e l'affidabilità dei servizi durante le interruzioni DNS temporanee, ma non garantisce che sia disponibile un record non aggiornato.

In AKS Standard, l'abilitazione di LocalDNS in un pool di nodi esistente reimposta l'immagine dei nodi. Pianificare l'implementazione per tenere conto di questa interruzione.

Per ulteriori informazioni sull'architettura e sulle funzionalità di LocalDNS, vedere Risoluzione DNS in AKS. Per istruzioni di configurazione, vedere Configurare LocalDNS.

Connettersi in modo sicuro ai nodi

Materiale sussidiario sulle procedure consigliate

Non esporre la connettività remota ai nodi del servizio Azure Kubernetes. Per la risoluzione dei problemi dei nodi Linux di routine, usare kubectl debug tramite l'API Kubernetes. Quando è necessario l'accesso SSH, connettersi tramite rete privata o Azure Bastion.

È possibile eseguire la maggior parte delle operazioni in AKS usando gli strumenti di gestione di Azure o il server API di Kubernetes. I nodi del servizio Azure Kubernetes sono disponibili solo in una rete privata e non sono connessi alla rete Internet pubblica. Per i nodi Linux, usare kubectl debug per avviare un contenitore di debug con privilegi tramite l'API Kubernetes. Questo approccio non richiede la connettività SSH diretta al nodo.

Se l'accesso all'API Kubernetes non è adatto o è necessario SSH, usare l'indirizzo IP privato del nodo da una rete connessa. Azure Bastion può fornire connettività privata senza esporre un indirizzo IP pubblico nel nodo. Per i nodi Windows, usare un contenitore di processo host o connettersi tramite un nodo proxy Linux. Azure Bastion è un'alternativa se il nodo proxy non è disponibile. Per altre informazioni, vedere Connettersi ai nodi del cluster del servizio Azure Kubernetes per la manutenzione o la risoluzione dei problemi.

Il diagramma illustra una rete virtuale di gestione che contiene un bastion host che instrada le connessioni tramite un collegamento con peering protetto alla rete virtuale del cluster AKS.

Se si utilizza un bastion host o una jump box, collocarlo in una rete virtuale di gestione separata, collegata tramite peering sicuro. Proteggere la rete di gestione usando Azure ExpressRoute o un gateway VPN per connettersi a una rete locale e controllare l'accesso con i gruppi di sicurezza di rete.

Passaggi successivi

Questo articolo è stato incentrato sulla sicurezza e la connettività di rete. Per altre informazioni sulle nozioni di base sulla rete in Kubernetes, vedere Concetti di rete per le applicazioni in Servizio Azure Kubernetes (AKS)