Concetti di sicurezza per applicazioni e cluster in Servizio Azure Kubernetes (AKS)

La sicurezza dei contenitori protegge l'intera pipeline end-to-end dalla compilazione ai carichi di lavoro dell'applicazione in esecuzione in Servizio Azure Kubernetes (AKS).

Secure Supply Chain include l'ambiente di compilazione e il registro.

Kubernetes include componenti di sicurezza, ad esempio gli standard di sicurezza dei pod e i segreti. Azure include componenti come Active Directory, Microsoft Defender per contenitori, Criteri di Azure, Azure Key Vault, gruppi di sicurezza di rete e aggiornamenti del cluster orchestrati. AKS combina questi componenti di sicurezza per:

• Fornire una storia completa di autenticazione e autorizzazione.
• Applica le policy integrate di AKS di Azure per proteggere le tue applicazioni.
• Informazioni dettagliate end-to-end dalla compilazione alla propria applicazione con Microsoft Defender per contenitori.
• Mantieni il cluster AKS aggiornato con le ultime correzioni di sicurezza del sistema operativo e le versioni di Kubernetes.
• Fornire il traffico sicuro dei pod e l'accesso alle credenziali sensibili.

Questo articolo introduce i concetti principali che proteggono le applicazioni in AKS.

Creazione della sicurezza

Come punto di ingresso per la catena di approvvigionamento, è importante eseguire l'analisi statica delle compilazioni di immagini prima che vengano alzate di livello nella pipeline. Ciò include la valutazione della vulnerabilità e della conformità. Non si tratta di un errore di compilazione perché presenta una vulnerabilità, in quanto interrompe lo sviluppo. Si tratta di guardare lo stato del fornitore per segmentare in base alle vulnerabilità che possono essere affrontate dai team di sviluppo. Usare anche i periodi di tolleranza per consentire agli sviluppatori di risolvere i problemi identificati.

Sicurezza del registro

La valutazione dello stato di vulnerabilità dell'immagine nel Registro individua la deriva e cattura le immagini che non provengono dal tuo ambiente di build. Usare Notary V2 per allegare firme alle immagini per assicurarsi che le distribuzioni provengano da una posizione attendibile.

Sicurezza del cluster

Nel servizio AKS, i componenti principali di Kubernetes fanno parte del servizio gestito, fornito e mantenuto da Microsoft. Ciascun cluster AKS ha un proprio master Kubernetes a tenant singolo per fornire l'API Server, l'Utilità di pianificazione e così via. Per ulteriori informazioni, si veda Gestione delle vulnerabilità per Servizio Azure Kubernetes.

Per impostazione predefinita, il server API di Kubernetes usa un indirizzo IP pubblico e il nome di dominio completo (FQDN). È possibile limitare l'accesso all'endpoint del server dell'API usando intervalli IP autorizzati. È anche possibile creare un cluster completamente privato per limitare l'accesso del server dell'API alla rete virtuale.

È possibile controllare l'accesso al server API utilizzando il controllo degli accessi in base al ruolo (RBAC) di Kubernetes e il controllo degli accessi in base al ruolo (RBAC) di Azure. Per altre informazioni, vedere l'integrazione di Microsoft Entra con AKS.

Sicurezza del nodo

I nodi AKS sono macchine virtuali Azure (VM) che gestisci e mantieni.

• I nodi Linux eseguono versioni ottimizzate di Ubuntu o Azure Linux.
• Windows Server nodi eseguono una versione di Windows Server ottimizzata usando il runtime del contenitore containerd.

Quando un cluster del servizio Azure Kubernetes viene creato o aumentato, i nodi vengono distribuiti automaticamente con gli aggiornamenti e le configurazioni di sicurezza del sistema operativo più recenti.

Per ulteriori informazioni sul processo di aggiornamento della sicurezza per i nodi di lavoro Linux e Windows, vedere Nodi di patch di sicurezza.

I cluster AKS che eseguono macchine virtuali Azure di seconda generazione includono il supporto per Avvio attendibile. Questa funzionalità protegge dalle tecniche di attacco avanzate e persistenti combinando tecnologie che è possibile abilitare in modo indipendente, ad esempio l'avvio protetto e una versione virtualizzata del modulo della piattaforma attendibile (vTPM). Gli amministratori possono distribuire i nodi di lavoro del servizio Azure Container con bootloader verificati e firmati, kernel del sistema operativo e driver per garantire l'integrità di tutta la catena di avvio della macchina virtuale sottostante.

Opzioni del sistema operativo ottimizzate per il contenitore e la sicurezza

AKS ha rilasciato il supporto per due nuove opzioni ottimizzate del sistema operativo Linux. Azure Linux OS Guard (anteprima) è stato creato da Microsoft e ottimizzato per Azure. OS Guard è basato su Azure Linux con configurazione specializzata per supportare carichi di lavoro in contenitori con ottimizzazioni di sicurezza. Flatcar Container Linux per AKS (anteprima) è un sistema operativo immutabile ottimizzato per contenitori indipendente dal fornitore basato su CNCF, più adatto per l'esecuzione in ambienti multicloud e locali. Queste opzioni del sistema operativo offrono maggiore sicurezza rispetto ad altre opzioni del sistema operativo Linux, ad esempio:

• Sia Azure Linux OS Guard che Flatcar Container Linux per il servizio Azure Kubernetes hanno un sistema operativo non modificabile che non è possibile modificare in fase di esecuzione. Tutti i file binari del sistema operativo, le librerie e la configurazione statica sono di sola lettura e l'integrità bit-for-bit è spesso protetta in modo crittografico. Questi sistemi operativi speciali vengono forniti come immagini autonome e vengono forniti senza alcun tipo di gestione dei pacchetti o altri mezzi tradizionali per modificare il sistema operativo. I carichi di lavoro utente vengono eseguiti in ambienti isolati, ad esempio contenitori, in modalità sandbox dal sistema operativo.
• Sia Azure Linux OS Guard che Flatcar Container Linux per Azure Kubernetes Service usano SELinux per il controllo di accesso obbligatorio.
• Azure Linux OS Guard applica FIPS e Avvio attendibile, offrendo una migliore conformità e protezione da attacchi avanzati e persistenti combinando l'avvio sicuro e la versione virtualizzata del modulo della piattaforma attendibile (vTPM).

Quando si decide tra le opzioni del sistema operativo ottimizzate per i contenitori da usare, AKS (Azure Kubernetes Service) consiglia quanto segue:

• Usare Flatcar Container Linux per AKS (anteprima) se si sta cercando un sistema operativo non modificabile neutrale dal punto di vista del fornitore con supporto multicloud.
• Usare Azure Linux OS Guard (anteprima) se si sta cercando un sistema operativo non modificabile pronto per l'organizzazione, consigliato da Microsoft.
• Usare Ubuntu se si sta cercando un sistema operativo indipendente dal fornitore e per utilizzo generico con supporto tra cloud.
• Usare Azure Linux se si sta cercando un sistema operativo per utilizzo generico aziendale consigliato da Microsoft.

Autorizzazione del nodo

L'autorizzazione del nodo è una modalità di autorizzazione speciale che autorizza in modo specifico le richieste API kubelet a proteggersi dagli attacchi East-West. L'autorizzazione del nodo è abilitata per impostazione predefinita nei cluster del servizio Azure Kubernetes 1.24 e versioni successive.

Distribuzione del nodo

I nodi vengono distribuiti in una subnet di rete privata virtuale, senza indirizzi IP pubblici assegnati. Ai fini della risoluzione dei problemi e della gestione, SSH è abilitato per impostazione predefinita e accessibile solo tramite l'indirizzo IP interno. La disabilitazione di SSH durante la creazione del cluster e del pool di nodi o per un cluster o un pool di nodi esistente è disponibile in anteprima. Per altre informazioni, vedere Gestire l'accesso SSH .

Archiviazione nodi

Per fornire spazio di archiviazione, i nodi usano Azure Managed Disks. Per la maggior parte delle dimensioni dei nodi della macchina virtuale, Azure Managed Disks sono dischi Premium supportati da UNITÀ SSD a prestazioni elevate. I dati archiviati nei dischi gestiti vengono crittografati automaticamente all'interno della piattaforma Azure. Per migliorare la ridondanza, Azure Managed Disks vengono replicati in modo sicuro all'interno del data center di Azure.

Carichi di lavoro multi-tenant ostili

Attualmente, gli ambienti Kubernetes non sono sicuri per l'utilizzo multi-tenant ostile. Funzionalità di sicurezza aggiuntive, ad esempio i criteri di sicurezza dei pod o il RBAC di Kubernetes per i nodi, bloccano gli exploit in modo efficace. Per una vera sicurezza quando si eseguono carichi di lavoro multi-tenant ostili, fidarsi solo di un hypervisor. Il dominio di sicurezza per Kubernetes diventa l'intero cluster, non un singolo nodo.

Per questi tipi di carichi di lavoro multi-tenant ostili è consigliabile usare cluster fisicamente isolati. Per altre informazioni sui modi per isolare i carichi di lavoro, vedere Procedure consigliate per l'isolamento del cluster nel servizio Azure Kubernetes.

Isolamento delle risorse di calcolo

A causa dei requisiti normativi o di conformità, alcuni carichi di lavoro possono richiedere un livello elevato di isolamento da altri carichi di lavoro dei clienti. Per questi carichi di lavoro, Azure fornisce:

• Contenitori isolati del kernel da utilizzare come nodi agenti in un cluster AKS. Questi contenitori sono completamente isolati in un tipo di hardware specifico e isolati dall'infrastruttura host Azure, dal sistema operativo host e dall'hypervisor. Sono dedicati a un singolo cliente. Selezionare una delle dimensioni delle macchine virtuali isolate come dimensione del nodo durante la creazione di un cluster del servizio Azure Kubernetes o l'aggiunta di un pool di nodi.
• I contenitori riservati (anteprima), basati anche su contenitori riservati Kata, crittografano la memoria del contenitore e impediscono che i dati in memoria durante il calcolo siano in testo non crittografato, in formato leggibile e manomissione. Consente di isolare i contenitori da altri gruppi di contenitori/pod e dal kernel del sistema operativo del nodo della macchina virtuale. I contenitori riservati (anteprima) usano la crittografia della memoria basata su hardware (SEV-SNP).
• Pod Sandboxing (anteprima) fornisce un confine di isolamento tra l'applicazione contenitore e il kernel condiviso e le risorse di calcolo (CPU, memoria e rete) dell'host contenitore.

Sicurezza di rete

Per la connettività e la sicurezza con le reti locali, è possibile distribuire il cluster AKS nelle subnet di rete virtuale esistenti di Azure. Queste reti virtuali si connettono alla rete locale usando Azure VPN da sito a sito o ExpressRoute. Definire controller di ingresso Kubernetes con indirizzi IP interni privati per limitare l'accesso ai servizi alla connessione di rete interna.

Azure gruppi di sicurezza di rete

Per filtrare il flusso del traffico di rete virtuale, Azure usa regole del gruppo di sicurezza di rete. Queste regole definiscono gli intervalli degli IP, le porte e i protocolli sorgente e destinazione a cui è consentito o negato l'accesso alle risorse. Vengono create regole predefinite per consentire il traffico TLS al server dell'API Kubernetes. È possibile creare servizi con servizi di bilanciamento del carico, mapping delle porte o route in ingresso. Il servizio Azure Kubernetes modifica automaticamente il gruppo di sicurezza di rete per il flusso del traffico.

Se si fornisce la propria subnet per il cluster AKS (indipendentemente dal fatto che sia in uso Azure CNI o Kubenet), non modificare il gruppo di sicurezza di rete a livello di scheda di interfaccia di rete gestito da AKS. Creare invece più gruppi di sicurezza di rete a livello di subnet per modificare il flusso del traffico. Assicurarsi che non interferiscano con il traffico necessario per la gestione del cluster, ad esempio l'accesso al servizio di bilanciamento del carico, la comunicazione con il piano di controllo e il traffico in uscita.

Politica di rete di Kubernetes

Per limitare il traffico di rete tra i pod nel cluster, AKS offre supporto per le politiche di rete Kubernetes. Con i criteri di rete è possibile scegliere di consentire o negare percorsi di rete specifici all'interno del cluster in base agli spazi dei nomi e ai selettori di etichette.

Sicurezza delle applicazioni

Per proteggere i pod in esecuzione su AKS, prendere in considerazione Microsoft Defender per contenitori per rilevare e limitare gli attacchi informatici contro le applicazioni in esecuzione nei pod. Eseguire un'analisi continua per rilevare la deriva nello stato di vulnerabilità dell'applicazione e implementare un processo "blue/green/canary" per applicare patch e sostituire le immagini vulnerabili.

Proteggere l'accesso del contenitore alle risorse

Allo stesso modo in cui è necessario concedere agli utenti o ai gruppi i privilegi minimi necessari, è anche necessario limitare i contenitori solo alle azioni e ai processi necessari. Per ridurre al minimo il rischio di attacco, evitare di configurare applicazioni e contenitori che richiedono privilegi elevati o accesso root. Le funzionalità di sicurezza predefinite di Linux, ad esempio AppArmor e seccomp , sono consigliate come procedure consigliate per proteggere l'accesso ai contenitori alle risorse.

Segreti di Kubernetes

Un segreto di Kubernetes viene usato per inserire nei pod i dati sensibili, ad esempio chiavi o credenziali di accesso.

1. Creare un segreto usando l'API di Kubernetes.
2. Definire il pod o la distribuzione e richiedere un segreto specifico.
   • I segreti vengono forniti solo ai nodi con un pod programmato che li richiede.
   • Il segreto viene archiviato in tmpfs, non scritto su disco.
3. Quando si elimina l'ultimo pod in un nodo che richiede un segreto, il segreto viene eliminato dal tmpfs del nodo.
   • I segreti vengono archiviati all'interno di uno spazio dei nomi specificato e sono accessibili solo dai pod all'interno dello stesso spazio dei nomi.

L'uso di Secrets riduce le informazioni riservate definite nel pod o nel manifest YAML del servizio. Si richiede invece il segreto archiviato nel server dell'API di Kubernetes come parte del manifesto YAML. Questo approccio fornisce solo l'accesso del pod specifico al segreto.

I segreti Kubernetes vengono archiviati in etcd, ovvero un archivio chiave-valore. Il servizio Azure Kubernetes consente la crittografia dei segreti inattivi in etcd usando chiavi gestite dal cliente.

Passaggi successivi

Per acquisire familiarità con la protezione dei cluster del servizio Azure Kubernetes, vedere Aggiornare un cluster del servizio Azure Kubernetes.

Per le procedure consigliate associate, vedere Procedure consigliate per la sicurezza e gli aggiornamenti del cluster nel servizio Azure Kubernetes e Procedure consigliate per la sicurezza dei pod nel servizio Azure Kubernetes.

Per ulteriori informazioni sui concetti di base di Kubernetes e del servizio Azure Kubernetes (AKS), vedere:

• Cluster e carichi di lavoro Kubernetes/AKS
• Identità Kubernetes/AKS
• Reti virtuali di Kubernetes/AKS
• Archiviazione Kubernetes/AKS
• Kubernetes/Ridimensionamento nel servizio Azure Kubernetes