Procedure consigliate per la sicurezza e la connettività di rete nel servizio Azure Kubernetes

Quando si creano e si gestiscono cluster nel servizio Azure Kubernetes, viene fornita la connettività di rete per nodi e 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 CNI di Azure nel servizio Azure Kubernetes per l'integrazione con reti virtuali esistenti o reti locali. 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:

• Networking CNI di Azure: esegue la distribuzione in una rete virtuale e usa il plug-in Azure CNI Kubernetes. Ai pod vengono assegnati IP singoli che possono essere instradati ad altri servizi di rete o a risorse locali.
• Funzionalità di rete Kubenet: Azure gestisce le risorse di rete virtuale durante la distribuzione del cluster e usa il plug-in kubenet di Kubernetes.

Azure CNI e kubenet sono entrambe opzioni valide 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 alle reti virtuali di Azure esistenti. Ogni nodo e risorsa pod riceve un indirizzo IP nella rete virtuale di Azure. Non è necessario un routing aggiuntivo per comunicare con altre risorse o servizi.

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

Quando si usano le funzionalità di rete Azure CNI, la risorsa di rete virtuale si trova in un gruppo di risorse separato rispetto al cluster del servizio Azure Kubernetes. 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 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 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.

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 la rete kubenet e Azure 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à 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 di Windows Server, in quanto questi pool di nodi richiedono un aggiornamento per applicare le patch di sicurezza più recenti. Per altre informazioni sui nodi di Windows Server, vedere Aggiornare un pool di nodi nel servizio Azure Kubernetes.

Per calcolare l'indirizzo IP richiesto, vedere Configure Azure CNI networking in Azure Kubernetes Service (AKS) (Configurare le funzionalità di rete Azure CNI nel servizio Azure Kubernetes).

Quando si crea un cluster con la rete CNI di Azure, 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 specifiche sui limiti e il dimensionamento per questi intervalli di indirizzi, vedere Configurare la rete CNI di Azure nel servizio Azure Kubernetes.

Rete Kubenet

Anche se kubenet non richiede di configurare le reti virtuali prima di distribuire il cluster, esistono degli svantaggi nell'attesa, ad esempio:

• Poiché i nodi e i pod vengono posizionati in subnet IP diverse, il routing definito dall'utente e l'inoltro IP instradano il traffico tra pod e nodi. Questo routing aggiuntivo può ridurre le prestazioni di rete.
• Le connessioni alle reti locali esistenti o le operazioni di peering con altre reti virtuali di Azure possono risultare complesse.

Poiché non si creano la rete virtuale e le subnet separatamente dal cluster del servizio Azure Kubenet, Kubenet è ideale per gli scenari seguenti:

• Carichi di lavoro di sviluppo o test di piccole dimensioni.
• Siti Web semplici con traffico basso.
• Lifting e spostamento dei carichi di lavoro in contenitori.

Per le distribuzioni di produzione, sia kubenet sia Azure CNI sono opzioni valide. Per gli ambienti che richiedono la separazione del controllo e della gestione, Azure CNI può essere l'opzione preferita. Kubenet è inoltre adatto solo per gli ambienti Linux in cui la conservazione dell'intervallo di indirizzi IP è una priorità.

È anche possibile configurare gli intervalli di indirizzi IP e le reti virtuali usando kubenet. Analogamente alla rete CNI di Azure, questi intervalli di indirizzi non devono sovrapporsi tra loro o a reti associate al cluster (reti virtuali, subnet, reti locali e peering).

Per informazioni dettagliate specifiche sui limiti e il dimensionamento per questi intervalli di indirizzi, vedere Usare la rete kubenet con gli intervalli di indirizzi IP personalizzati nel servizio Azure Kubernetes.

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 di Azure, i controller di ingresso offrono funzionalità aggiuntive e possono essere gestiti come risorse Kubernetes native.

Anche se un servizio di bilanciamento del carico di Azure può distribuire il traffico dei clienti alle applicazioni nel cluster del servizio Azure Kubernetes, è limitato a comprendere tale 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 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 il servizio Azure Kubernetes 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 delle zone pubbliche e private.

• 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. 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 set di regole, Open Web Application Security Project (OWASP) controlla gli attacchi come scripting intersito o avvelenamento da cookie. Il gateway applicazione di Azure (attualmente in anteprima nel servizio Azure Kubernetes) è 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. Il gateway applicazione può essere gestito centralmente come controller in ingresso con una definizione delle risorse. Per iniziare, creare un controller in ingresso del gateway applicazione.

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.

Criteri di rete è una funzionalità Kubernetes disponibile nel servizio Azure Kubernetes che consente di controllare il flusso di traffico tra i pod. È possibile consentire o rifiutare il traffico verso il pod in base alle impostazioni, ad esempio etichette assegnate, spazio dei nomi o porta del traffico. I criteri di rete sono un modo nativo del cloud per controllare il flusso di 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, abilitare la funzionalità quando si crea un nuovo cluster del servizio Azure Kubernetes. Non è possibile abilitare criteri di rete in un cluster esistente del servizio Azure Kubernetes. Pianificare in anticipo l'abilitazione dei criteri di rete nei cluster necessari.

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 Proteggere il traffico tra i pod usando criteri di rete nel servizio Azure Kubernetes.

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 nel servizio Azure Kubernetes usando gli strumenti di gestione di Azure o 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 servizio 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 della rete in Kubernetes, vedere Concetti relativi alla rete per le applicazioni nel servizio Azure Kubernetes