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 Microsoft Entra ID, 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 i criteri di Azure predefiniti di AKS per proteggere le tue applicazioni.
  • Visibilità completa end-to-end dalla compilazione fino all'applicazione con Microsoft Defender per i 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.

Il servizio Azure Kubernetes supporta due modalità cluster: Servizio Azure Kubernetes Automatico e Standard del servizio Azure Kubernetes. I concetti relativi alla sicurezza in questo articolo si applicano a entrambe le modalità, se non diversamente specificato. AKS Automatic include una baseline di sicurezza rafforzata con diversi controlli configurati per impostazione predefinita, mentre AKS Standard offre una maggiore flessibilità di configurazione.

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

Importante

A partire da November 30, 2025, Servizio Azure Kubernetes (AKS) non supporta più o fornisce aggiornamenti della sicurezza per Azure Linux 2.0. L'immagine del nodo Azure Linux 2.0 è congelata alla versione 202512.06.0. A partire dal 31 marzo 2026, le immagini dei nodi verranno rimosse e non sarà possibile ridimensionare i pool di nodi. Effettuare la migrazione a una versione supportata di Linux su Azure aggiornando i pool di nodi a una versione supportata di Kubernetes o effettuando la migrazione a osSku AzureLinux3. Per altre informazioni, vedere Retirement GitHub issue e annuncio di ritiro degli aggiornamenti di Azure. Per rimanere informati sugli annunci e sugli aggiornamenti, segui le note di rilascio di AKS.

Creare la sicurezza

La sicurezza del processo di build è il punto di partenza per la tua supply chain sicura. Prima che le immagini vengano promosse negli ambienti di distribuzione, eseguire in CI l'analisi statica e la valutazione delle vulnerabilità e della conformità.

In entrambe le modalità di AKS, utilizzare il triage basato sul rischio anziché bloccare tutte le build in presenza di qualsiasi vulnerabilità. Classificare in ordine di priorità la correzione usando lo stato e la gravità del fornitore e applicare periodi di tolleranza per eccezioni non sfruttabili o con limiti di tempo.

AKS Automatic contribuisce a ridurre la deriva nelle configurazioni a valle facendo partire i cluster da una configurazione di base rafforzata con controlli di sicurezza preconfigurati. Ciò rende ancora più importante la convalida in fase di build della qualità delle immagini e della conformità alle policy, perché le immagini attendibili sono promosse con maggiore coerenza in una baseline di esecuzione sicura.

AKS Standard offre maggiore flessibilità a livello di cluster, pertanto le pipeline di compilazione devono applicare esplicitamente la baseline dell'organizzazione per la provenienza delle immagini, le soglie di vulnerabilità e i gate dei criteri prima della distribuzione.

Sicurezza del Registro di sistema

La sicurezza del registro verifica che siano disponibili per la distribuzione solo immagini attendibili e conformi e aiuta a rilevare modifiche non intenzionali dopo la compilazione. Valutare lo stato di vulnerabilità dell'immagine nel Registro di sistema in modo continuo, non solo in fase di compilazione. L'analisi del Registro di sistema rileva le nuove vulnerabilità e le immagini che ignorano i percorsi di compilazione approvati. Usare la firma e la verifica delle immagini, ad esempio Notary V2, per assicurarsi che i carichi di lavoro vengano distribuiti da origini attendibili con prove verificabili.

Per AKS Automatic, in cui diverse funzionalità di sicurezza del runtime sono preconfigurate, i controlli del registro rimangono un punto di controllo critico a monte per mantenere pulita la catena di fornitura del runtime. Per AKS Standard, applicare gli stessi controlli del registro e allinearli ai criteri di ammissione del cluster e alla configurazione dei criteri per imporre in modo coerente l'uso di immagini attendibili.

Sicurezza del cluster

In AKS, i componenti principali di Kubernetes fanno parte del servizio gestito fornito, gestito e mantenuto da Microsoft. Ogni cluster AKS dispone di una propria istanza primaria di Kubernetes dedicata e a tenant singolo per fornire il Server API, lo Scheduler e così via. Per altre informazioni, vedere 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.

Per AKS Automatic, l'integrazione della rete virtuale del server API è preconfigurata come parte della configurazione di sicurezza predefinita. In AKS Standard la stessa funzionalità è disponibile e può essere abilitata in base ai requisiti di progettazione e sicurezza della rete.

È 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. In AKS Automatic, Azure RBAC per l'autorizzazione di Kubernetes è preconfigurato. In AKS Standard è possibile scegliere e configurare il modello di autorizzazione più adatto al proprio ambiente. Per altre informazioni, vedere l'integrazione di Microsoft Entra con AKS.

AKS Impostazioni predefinite di sicurezza automatiche

AKS Automatic include una baseline rafforzata con controlli di sicurezza preconfigurati per impostazione predefinita, tra cui:

  • Controllo degli accessi in base al ruolo di Azure (RBAC) per l'autorizzazione di Kubernetes
  • Integrazione della rete virtuale del server API
  • Identità del carico di lavoro ed emittente OIDC
  • Protezioni della distribuzione e standard di base per la sicurezza dei pod in modalità enforce
  • Pulizia delle immagini per la rimozione di immagini vulnerabili inutilizzate
  • Restrizioni di sicurezza gestite per il pool di nodi di sistema che preservano la separazione tra i carichi di lavoro dei clienti e l'infrastruttura gestita da AKS

AKS Standard supporta queste funzionalità con una maggiore flessibilità di implementazione, ma potrebbero richiedere l'abilitazione esplicita e la gestione operativa.

Sicurezza del nodo

I nodi di AKS sono macchine virtuali di Azure (VM). In AKS Standard, gestisci le opzioni di configurazione e del ciclo di vita del pool di nodi. In AKS Automatic, AKS gestisce per conto dell'utente i pool di nodi di sistema e i componenti di sistema di base, inclusi il ridimensionamento e gli aggiornamenti, con restrizioni di sicurezza per l'infrastruttura di sistema gestita.

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.

Nota

Cluster del servizio Azure Kubernetes in esecuzione:

  • Kubernetes versione 1.19 e versioni successive: i pool di nodi Linux usano containerd come runtime dei contenitori. I pool di nodi di Windows Server 2019 e di Windows Server 2022 usano containerd come runtime del contenitore. Per altre informazioni, vedere Aggiungi un pool di nodi Windows Server con containerd.
  • Kubernetes versione 1.19 e precedenti: i pool di nodi Linux usano Docker come runtime del contenitore.

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

Azure Container Linux (ACL) è un sistema operativo immutabile, ottimizzato per i contenitori, per AKS. ACL deriva dal progetto Flatcar Container Linux e si basa sulla collaudata architettura immutabile, incentrata sui container, di Flatcar, integrando al contempo i pacchetti di Azure Linux, la manutenzione e l'integrazione con la piattaforma. Ciò consente a ACL di rimanere strettamente allineati con l'innovazione flatcar upstream, rispettando al contempo i requisiti di produzione, sicurezza e conformità di Azure. Per altre informazioni su Flatcar Container Linux, vedere la documentazione di Flatcar.

ACL è generalmente disponibile (GA) come opzione del sistema operativo in AKS a partire dalla versione 1.34. È possibile distribuire pool di nodi ACL in un nuovo cluster del servizio Azure Kubernetes, aggiungere pool di nodi ACL ai cluster esistenti ed eseguire la migrazione dei pool di nodi Linux esistenti a ACL.

Per altre informazioni su ACL, vedere Panoramica di Azure Container Linux (ACL) per AKS.

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.

In AKS Automatic, le funzionalità di rete virtuale gestita e le impostazioni predefinite principali per il traffico in ingresso e in uscita sono preconfigurate per fornire una configurazione di base sicura. In AKS Standard, i modelli di rete e i controlli in uscita/in ingresso sono più flessibili e devono essere selezionati in base all'architettura di sicurezza.

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.

In AKS Automatic, l'identità del carico di lavoro e l'emittente OIDC sono preconfigurati per semplificare l'accesso sicuro dei carichi di lavoro ai servizi Azure. In AKS Standard queste funzionalità sono disponibili e possono essere abilitate come parte del comportamento di sicurezza di base.

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.

Nota

I file manifesto dei segreti non elaborati contengono i dati segreti in formato base64. Per altre informazioni, vedere la documentazione ufficiale. Considerare questi file come informazioni sensibili e non inserirli mai nel controllo del codice sorgente.

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.

Contenuti correlati

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

Se si valutano impostazioni predefinite e responsabilità operative specifiche della modalità, vedere Che è Servizio Azure Kubernetes (AKS) Automatico?

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:

  • Last updated on