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 la rete Azure CNI in Azure Kubernetes Service per l'integrazione con reti virtuali esistenti o reti on-premises. Questo modello di rete consente una maggiore separazione delle risorse e dei controlli in un ambiente aziendale.

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:

• Azure CNI networking: viene distribuito in una rete virtuale e usa il plug-in Kubernetes Azure CNI. Ai pod vengono assegnati IP singoli che possono essere instradati ad altri servizi di rete o a risorse locali.

Azure CNI è un'opzione valida per le distribuzioni di produzione.

Rete CNI

Azure CNI è un protocollo indipendente dal fornitore che consente al runtime del contenitore di effettuare richieste a un provider di rete. Assegna indirizzi IP a pod e nodi e fornisce funzionalità di gestione degli indirizzi IP durante la connessione a reti virtuali Azure esistenti. Ogni nodo e risorsa pod riceve un indirizzo IP nella rete virtuale Azure. Non è necessario un routing aggiuntivo per comunicare con altre risorse o servizi.

In particolare, Azure rete CNI per la produzione 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. Con Azure rete CNI, ci si connette alle risorse Azure esistenti, alle risorse locali o ad altri servizi direttamente tramite indirizzi IP assegnati a ogni pod.

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:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

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

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

Quando ogni nodo e pod riceve il proprio indirizzo IP, pianificare gli intervalli di indirizzi per le subnet del servizio Azure Kubernetes. Tenere presenti i criteri seguenti:

• La subnet deve essere sufficientemente grande da fornire indirizzi IP per ogni nodo, pod e risorsa di rete distribuita.
  • Con Azure rete CNI, ogni nodo in esecuzione ha limiti predefiniti al numero di pod.
• Evitare di usare intervalli di indirizzi IP che si sovrappongono alle risorse di rete esistenti.
  • È necessario consentire la connettività a reti locali o reti 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 l'indirizzo IP necessario, vedere Configurare la rete Azure CNI in AKS.

Quando si crea un cluster con Azure rete CNI, si specificano altri intervalli di indirizzi per il cluster, ad esempio l'indirizzo del bridge Docker, l'IP del servizio DNS e l'intervallo di indirizzi del servizio. In generale, assicurarsi che questi intervalli di indirizzi non si sovrappongano tra loro o a qualsiasi rete associata al cluster, incluse le reti virtuali, le subnet, le reti locali e con peering.

Per informazioni dettagliate sui limiti e sul dimensionamento per questi intervalli di indirizzi, vedere Configurare la rete CNI di Azure in AKS.

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.

Esistono due componenti per l'ingresso:

1. Una risorsa in ingresso
2. Un controller in 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 distribuisce il traffico per myapp.com a uno dei due servizi, servizio blog o servizio di archiviazione, 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: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

Controller di ingresso

Un controller di ingresso è un daemon che viene eseguito in un nodo del servizio Azure Kubernetes e controlla le richieste in arrivo. Il traffico viene quindi distribuito in base alle regole definite nella risorsa in ingresso. 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 per container, Contour, HAProxy, Traefik e così via.

I controller di ingresso devono essere pianificati 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 di routing dell'applicazione è il modo consigliato per configurare un controller di ingresso nel servizio Azure Kubernetes. Il componente aggiuntivo di routing dell'applicazione è un controller di ingresso completamente gestito per Servizio Azure Kubernetes (AKS) che fornisce 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 sul componente aggiuntivo di routing dell'applicazione, vedere 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 per individuare potenziali attacchi, usare un web application firewall (WAF), ad esempio Barracuda WAF per Azure o gateway applicazione di Azure per contenitori. Queste risorse di rete più avanzate possono anche instradare il traffico oltre le connessioni HTTP e HTTPS o la terminazione TLS di base.

In genere, un controller di ingresso è una risorsa Kubernetes nel cluster del servizio Azure Kubernetes che distribuisce il traffico ai servizi e alle applicazioni. Il controller viene eseguito come daemon in un nodo del servizio Azure Kubernetes e usa alcune delle risorse del nodo, ad esempio CPU, memoria e larghezza di banda di rete. In ambienti di grandi dimensioni, è 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.

Per questo livello aggiuntivo di sicurezza, un web application firewall (WAF) filtra il traffico in ingresso. Con un insieme di regole, l'Open Web Application Security Project (OWASP) controlla attacchi come il cross-site scripting (XSS) o l'avvelenamento dei cookie. gateway applicazione di Azure per contenitori è un WAF che si integra con i cluster del servizio Azure Kubernetes, bloccando queste funzionalità di sicurezza prima che il traffico raggiunga il cluster e le applicazioni del servizio Azure Kubernetes.

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 l'Application Gateway per contenitori.

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 nel servizio Azure Kubernetes, la funzionalità può essere abilitata durante la creazione del cluster o in un cluster del servizio Azure Kubernetes esistente. Se prevedete di usare le politiche di rete, assicuratevi che la funzionalità sia abilitata nel cluster AKS.

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

Abilitare LocalDNS nei pool di nodi del servizio Azure Kubernetes per migliorare le prestazioni, l'affidabilità e ridurre il carico sui pod CoreDNS centralizzati.

La risoluzione DNS è fondamentale per la comunicazione da servizio a servizio in Kubernetes. Per impostazione predefinita, tutte le query DNS inviate dai pod vengono indirizzate ai pod centralizzati di CoreDNS, che possono rappresentare un collo di bottiglia a livello di scala. AKS offre LocalDNS, che implementa un proxy DNS come systemd servizio in ogni nodo. Questo proxy gestisce le query DNS in locale, riducendo gli hop di rete e la latenza di risoluzione.

LocalDNS elimina anche le conntrack voci di tabella per il traffico DNS, impedendo l'esaurimento conntrack delle tabelle 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à consente di mantenere la connettività dei pod e l'affidabilità del servizio durante le interruzioni DNS temporanee.

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 tramite un bastion host

Materiale sussidiario sulle procedure consigliate

Non esporre la connettività remota ai nodi del servizio Azure Kubernetes. Creare un bastion host, o una jump box, in una rete virtuale di gestione. Usare il bastion host per instradare in modo sicuro il traffico nel cluster del servizio Azure Kubernetes alle attività di gestione remota.

È possibile completare la maggior parte delle operazioni in Azure Kubernetes Service utilizzando gli strumenti di gestione di Azure o tramite il server API Kubernetes. I nodi del servizio Azure Kubernetes sono disponibili solo in una rete privata e non sono connessi alla rete Internet pubblica. Per connettersi ai nodi e fornire manutenzione e supporto, indirizzare le connessioni tramite un host bastion o una box jump. Verificare che questo host si trovi in una rete virtuale di gestione separata con peering sicuro alla rete virtuale del cluster del servizio Azure Kubernetes.

È anche necessario proteggere la rete di gestione per l'host bastion. Usare un gateway Azure ExpressRoute o VPN per connettersi a una rete locale e controllare l'accesso usando 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)