Progettazione di architetture di rete sicure per Azure Kubernetes Service (AKS)

La tendenza nell’adottare applicativi basati su microservizi impone l’utilizzo di soluzioni all’avanguardia in grado di gestire un numero elevato di container e le modalità con le quali questi interagiscono applicativamente tra di loro, come Azure Kubernetes Service (AKS). Nell’ambito della progettazione delle architetture Azure Kubernetes Service (AKS) diversi sono gli elementi che devono essere valutati per ottenere una topologia di rete appropriata in grado di garantire la massima efficienza e sicurezza. In questo articolo vengono riportati i principali aspetti da prendere in considerazione, accompagnati da alcune proposte, per effettuare delle scelte consapevoli nella progettazione delle architetture di rete per AKS.

Che cos’è Azure Kubernetes Service (AKS)?

Azure Kubernetes Service (AKS) è il servizio Azure completamente gestito che permette l’attivazione di un cluster Kubernetes, ideale per semplificare il deployment e la gestione di architetture basate su microservizi. Grazie alle funzionalità offerte da AKS è possibile scalare automaticamente in base all’utilizzo, utilizzare controlli per garantire l’integrità dei servizi, implementare politiche di bilanciamento del carico e gestire i secret. In architetture basate su microservizi è frequente anche l’adozione del componente Azure Container Registry che consente di creare, archiviare e gestire le immagini dei container e gli artifacts in un registry privato. L’utilizzo di questo servizio gestito viene integrato con le pipeline di sviluppo e di deployment dei container.

La topologia di rete

Nell’architettura di rete di tipologia Hub and Spoke, l’Hub è una rete virtuale in Azure che funge da punto di connettività verso la rete on-premises. Tale connettività può avvenire tramite VPN Site to site oppure tramite ExpressRoute. Gli Spoke sono le reti virtuali che eseguono il peering con l’Hub e possono essere usate per isolare i carichi di lavoro.

Questa topologia di rete è consigliata anche per le architetture AKS in quanto è in grado di offrire diversi vantaggi, tra i quali:

• Segregazione dell’ambiente per applicare più agevolmente politiche di governance ed ottenere un maggiore controllo. Questa topologia supporta anche il concetto di “landing zone” contemplando la separazione dei compiti.
• Riduzione al minimo dell’esposizione diretta delle risorse di Azure alla rete pubblica (Internet).
• Possibilità di contemplare workload attestati su differenti subscription Azure, diventando di fatto una scelta naturale in questi scenari.
• Possibilità di estendere facilmente l’architettura per accogliere nuove funzionalità oppure nuovi workload, semplicemente aggiungendo ulteriori virtual network di spoke.
• Possibilità di centralizzare in un’unica posizione i servizi Azure condivisi da più workload (attestati su VNet differenti), come ad esempio i server DNS ed eventuali appliance virtuali di rete. Si riducono inoltre i VPN Gateway necessari per fornire connettività verso l’ambiente on-premises, con un conseguente risparmio sui costi Azure ed una semplificazione dell’architettura.

Hub Virtual Network

Nella rete di Hub è possibile valutare l’adozione dei seguenti servizi:

• Gateway VPN oppure ExpressRoute: necessario per fornire connettività verso l’ambiente on-premises.
• Soluzioni Firewall, necessarie nel caso si voglia controllare il traffico dal proprio ambiente AKS, come pod oppure nodi del cluster, in uscita verso servizi esterni. In questo ambito la scelta può ricadere tra:
  • Azure Firewall, la soluzione di firewall-as-a-service (FWaaS) che consente di mettere in sicurezza le risorse presenti nelle Virtual Network e di governare i relativi flussi di rete.
  • Network Virtual Appliances (NVAs) fornite da vendor di terze parti. Tali soluzioni sono numerose e possono offrire funzionalità avanzate, ma tipicamente la configurazione di queste soluzioni è più articolata e il costo è tendenzialmente più elevato rispetto alla soluzione fornita dalla piattaforma Azure. Una comparativa tra il nuovo Azure Firewall e le virtual appliance di terze parti è possibile consultarla in questo articolo.

• Azure Bastion, il servizio PaaS che offre un accesso RDP ed SSH sicuro e affidabile alle macchine virtuali, direttamente tramite il portale di Azure.

Spoke Virtual Network

Nella rete di Spoke viene posizionato il cluster AKS insieme ad altre risorse strettamente correlate al suo funzionamento. La VNet di Spoke viene suddivisa in differenti subnet per ospitare i seguenti componenti:

• I due gruppi di nodi (node pools) di AKS:

• • AKS System Node pool: il pool di nodi di sistema che ospitano i pod necessari per l’esecuzione dei servizi core del cluster.
  • AKS User Node pool: il pool di nodi user che eseguono i workload applicativi e l’ingress controller.

Per ambienti applicativi multi-tenant o per workload con esigenze avanzate potrebbe essere necessario implementare meccanismi di isolamento dei node pools che richiedono la presenza di differenti subnet.

• AKS Internal Load Balancer: il servizio di bilanciamento per instradare e distribuire il traffico in ingresso per le risorse Kubernetes. In questo caso viene utilizzato il componente Azure Load Balancer, che consente il bilanciamento del carico Layer-4 per tutti i protocolli TCP e UDP, garantendo alte prestazioni e bassissime latenze.

• Azure Application Gateway: si tratta di un servizio gestito dalla piattaforma Azure, con funzionalità intrinseche di alta disponibilità e scalabilità. L’Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, che consente di governare il traffico HTTP e HTTPS delle applicazioni (URL path, host based, round robin, session affinity, redirection). L’Application Gateway è in grado di gestire in modo centralizzato i certificati per la pubblicazione applicativa, tramite policy SSL ed effettuando SSL offload quando necessario. L’Application Gateway può avere assegnato un indirizzo IP Privato oppure un indirizzo IP Pubblico, se la ripubblicazione applicativa deve avvenire verso Internet. In particolare in quest’ultimo caso, è consigliato attivare la funzionalità di Web Application Firewall (WAF), che consente di ottenere una protezione applicativa, basandosi su regole OWASP core rule sets. Il WAF protegge l’applicativo da vulnerabilità e da attacchi comuni, come ad esempio attacchi X-Site Scripting e SQL Injection.

Grazie all’adozione degli Azure Private Link è possibile portare i servizi Azure in una Virtual Network e mapparli con un endpoint privato. In questo modo tutto il traffico viene istradato tramite l’endpoint privato, mantenendolo sulla rete globale di Microsoft. Il dato non transita mai su Internet, questo riduce l’esposizione a minacce e aiuta a rispettare gli standard di compliance.

Negli ambienti AKS gli Azure Private Link vengono solitamente creati nelle subnet della rete virtuale di Spoke per Azure Container Registry ed Azure KeyVault.

Si riporta uno schema con i flussi di rete in ingresso ed in uscita per un ambiente AKS, che prevede anche la presenza di Azure Firewall per controllare il traffico in uscita.

Traffico di Management

Per poter consentire la gestione dell’ambiente, come la creazione di nuove risorse oppure per svolgere le attività per scalare l’ambiente cluster, è opportuno prevedere un accesso alle API Kubernetes. Buona norma è applicare dei filtri di rete per autorizzare in modo puntuale questo accesso.

Cluster AKS privato

Nel caso si voglia implementare un ambiente AKS totalmente privato, dove non viene esposto nessun servizio in Internet, è possibile adottare un cluster AKS in modalità “private”.

Conclusioni

La sempre più frequente richiesta di architetture applicative basate su microservizi che utilizzano Azure Kubernetes Service (AKS) richiede di individuare e realizzare architetture di rete progettate per essere sicure, flessibili e con un elevato livello di integrazione. Il tutto deve avvenire tramite un approccio moderno in grado di sfruttare a pieno le potenzialità offerte in ambito networking da Azure.