Condividi tramite

Concetti relativi alla sicurezza per le applicazioni e i cluster nel servizio Azure Kubernetes

  • Articolo

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

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. Il servizio Azure Kubernetes combina questi componenti di sicurezza per:

  • Fornire una storia completa di autenticazione e autorizzazione.
  • Applicare Criteri di Azure predefiniti del servizio Azure Kubernetes per proteggere le applicazioni.
  • Informazioni dettagliate end-to-end dalla compilazione tramite l'applicazione con Microsoft Defender per contenitori.
  • Mantenere il cluster del servizio Azure Kubernetes che esegue gli aggiornamenti più recenti della 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 principali concetti per proteggere le applicazioni nel servizio Azure Kubernetes.

Sicurezza della compilazione

Come punto di ingresso per la supply chain, è 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 esaminare lo stato fornitore per segmentare in base alle vulnerabilità che possono essere eseguite 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 di sistema rileva la deriva e rileva anche le immagini che non provengono dall'ambiente di compilazione. Usare Notary V2 per allegare firme alle immagini per assicurarsi che le distribuzioni provengano da una posizione attendibile.

Sicurezza del cluster

Nel servizio Azure Kubernetes i componenti master di Kubernetes fanno parte del servizio gestito fornito da Microsoft. Ogni cluster del servizio Azure Kubernetes ha un proprio master di Kubernetes dedicato con tenant singolo per fornire il server dell'API, l'utilità di pianificazione e così via. Per altre informazioni, vedere Gestione delle vulnerabilità per il 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 usando il controllo degli accessi in base al ruolo di Kubernetes e il controllo degli accessi in base al ruolo di Azure. Per altre informazioni, vedere Integrazione di Microsoft Entra con il servizio Azure Kubernetes.

Sicurezza del nodo

I nodi del servizio Azure Kubernetes sono macchine virtuali (VM) di Azure gestite dall'utente.

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

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 successive: i pool di nodi Linux usano containerd come runtime del contenitore. I pool di nodi di Windows Server 2019 e Windows Server 2022 usano containerd come runtime del contenitore. Per ulteriori informazioni, consultare Aggiungere un pool di nodi di Windows Server con containerd.
  • Kubernetes versione 1.19 e precedenti: i pool di nodi Linux usano Docker come runtime del contenitore.

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

I cluster del servizio Azure Kubernetes che eseguono macchine virtuali di seconda generazione includono il supporto per l'avvio attendibile, che protegge dalle tecniche di attacco avanzate e persistenti combinando tecnologie che possono essere abilitate in modo indipendente, ad esempio l'avvio protetto e la versione virtualizzata del modulo VTPM (Trusted Platform Module). 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.

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 rendere disponibile l'archiviazione, i nodi usano Managed Disks di Azure. Per la maggior parte delle dimensioni dei nodi della macchina virtuale, i dischi gestiti di Azure sono dischi Premium supportati da unità SSD a prestazioni elevate. I dati archiviati nei dischi gestiti vengono crittografati automaticamente inattivi all'interno della piattaforma Azure. Per migliorare la ridondanza, questi Managed Disk di Azure vengono anche replicati in modo sicuro nel 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 controllo degli accessi in base al ruolo di Kubernetes per i nodi, bloccano in modo efficiente gli exploit. Per una vera sicurezza quando si eseguono carichi di lavoro multi-tenant ostili, considerare attendibile solo 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 del 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 offre:

  • Contenitori isolati del kernel da usare come nodi agente in un cluster del servizio Azure Kubernetes. Questi contenitori sono completamente isolati in un tipo di hardware specifico e isolati dall'infrastruttura host di 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, nonché dal kernel del sistema operativo del nodo della macchina virtuale. I contenitori riservati (anteprima) usano la crittografia della memoria basata su hardware (SEV-SNP).
  • Il sandboxing dei pod (anteprima) fornisce un limite 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 sicurezza con le reti locali, è possibile distribuire il cluster del servizio Azure Kubernetes nelle subnet di rete virtuale di Azure esistenti. Queste reti virtuali si connettono alla rete locale usando la VPN da sito a sito di Azure o ExpressRoute. Definire controller di ingresso Kubernetes con indirizzi IP interni privati per limitare l'accesso ai servizi alla connessione di rete interna.

Gruppi di sicurezza di rete di Azure

Per filtrare il flusso del traffico di rete virtuale, Azure usa le 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 del servizio Azure Kubernetes (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 dal servizio Azure Kubernetes. 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.

Criteri di rete di Kubernetes

Per limitare il traffico di rete tra i pod nel cluster, il servizio Azure Kubernetes offre supporto per i criteri 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 nel servizio Azure Kubernetes, 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 di escalation o accesso radice. 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][secure-container-access].

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 pianificato 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 dei segreti riduce le informazioni riservate definite nel pod o nel manifesto 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 riservate e non eseguirne mai il commit nel controllo del codice sorgente.

I segreti Kubernetes vengono archiviati in etcd, ovvero un archivio chiave-valore. Il servizio Azure Kubernetes gestisce completamente l'archivio etcd e i dati vengono crittografati inattivi all'interno della piattaforma Azure.

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 altre informazioni sui concetti di base di Kubernetes e del servizio Azure Kubernetes, vedere: