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

  • Articolo

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

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

Kubernetes include componenti di sicurezza, ad esempio standard di sicurezza pod e 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 a:

  • Specificare 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 del pod sicuro e l'accesso alle credenziali sensibili.

Questo articolo illustra i concetti di base che proteggono le applicazioni nel servizio Azure Kubernetes.

Sicurezza di compilazione

Come punto di ingresso per la Supply Chain, è importante condurre l'analisi statica delle compilazioni di immagini prima di essere promosse verso il basso della pipeline. Ciò include la valutazione della vulnerabilità e della conformità. Non si tratta di un errore di compilazione perché ha una vulnerabilità, in quanto interrompe lo sviluppo. Si tratta di esaminare lo stato fornitore per segmentare in base alle vulnerabilità che sono utilizzabili dai team di sviluppo. Usare anche i periodi di tolleranza per consentire agli sviluppatori di risolvere i problemi identificati.

Sicurezza del Registro di sistema

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 collegare le firme alle immagini per assicurarsi che le distribuzioni vengano provenienti da una posizione attendibile.

Sicurezza del cluster

Nel servizio Azure Kubernetes i componenti master di Kubernetes fanno parte del servizio gestito fornito, gestito e gestito da Microsoft. Ogni cluster del servizio Azure Kubernetes ha un proprio master kubernetes a tenant singolo per fornire il server API, l'utilità di pianificazione e così via. Per informazioni su come Microsoft gestisce le vulnerabilità di sicurezza e informazioni dettagliate sul rilascio degli aggiornamenti della sicurezza per l'analisi gestita di cluster del servizio Azure Kubernetes, vedere Gestione delle vulnerabilità per servizio Azure Kubernetes.

Per impostazione predefinita, il server dell'API Kubernetes usa un indirizzo IP pubblico e un 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 Azure Active Directory con il servizio Azure Kubernetes.

Sicurezza dei nodi

I nodi del servizio Azure Kubernetes sono macchine virtuali di Azure gestite e gestite.

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

Quando un cluster del servizio Azure Kubernetes viene creato o fatto passare a un piano superiore, i nodi vengono distribuiti automaticamente con le configurazioni e gli aggiornamenti della sicurezza del sistema operativo più recenti.

Nota

Cluster del servizio Azure Kubernetes con:

  • Kubernetes versione 1.19 e successiva per i pool di nodi Linux usano containerd come runtime del contenitore. L'uso containerd con i pool di nodi di Windows Server 2019 è attualmente in anteprima. Per altre informazioni, vedere Aggiungere un pool di nodi di Windows Server con containerd.
  • Kubernetes prima della versione 1.19 per i pool di nodi Linux usa Docker come runtime del contenitore. Per i pool di nodi di Windows Server 2019, Docker è il runtime predefinito del contenitore.

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

Autorizzazione nodo

L'autorizzazione del nodo è una modalità di autorizzazione speciale che autorizza in modo specifico le richieste API effettuate da kubelets per proteggere da attacchi East-West. L'autorizzazione del nodo è abilitata per impostazione predefinita nei cluster del servizio Azure Kubernetes 1.24 + .

Distribuzione del nodo

I nodi vengono distribuiti in una subnet di rete privata virtuale, senza indirizzi IP pubblici assegnati. Per la risoluzione dei problemi e la gestione, SSH è abilitato per impostazione predefinita e accessibile solo usando l'indirizzo IP interno.

Archiviazione dei nodi

Per fornire spazio di archiviazione, i nodi usano Azure Managed Disks. Per la maggior parte delle dimensioni dei nodi vm, Azure Managed Disks sono dischi Premium supportati da SSD a prestazioni elevate. I dati inattivi archiviati nei dischi gestiti vengono automaticamente crittografati 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 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 elevato grado di isolamento da altri carichi di lavoro dei clienti. Per questi carichi di lavoro, Azure fornisce macchine virtuali isolate da usare come nodi agente in un cluster del servizio Azure Kubernetes. Queste macchine virtuali sono isolate in un tipo di hardware specifico e dedicate 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.

Aggiornamenti dei cluster

Azure offre strumenti di orchestrazione di aggiornamento per aggiornare un cluster e i componenti del servizio Azure Kubernetes, mantenere la sicurezza e la conformità e accedere alle funzionalità più recenti. Questa orchestrazione dell'aggiornamento include sia il master che i componenti agente di Kubernetes.

Per avviare il processo di aggiornamento, specificare una delle versioni disponibili di Kubernetes elencate. Azure quindi impedisce in modo sicuro e svuota ogni nodo del servizio Azure Kubernetes e gli aggiornamenti.

Blocco e svuotamento

Durante il processo di aggiornamento, i nodi del servizio Azure Kubernetes vengono delimitati singolarmente dal cluster per impedire la pianificazione dei nuovi pod. I nodi vengono quindi svuotati e aggiornati nel modo seguente:

  1. Un nuovo nodo viene distribuito nel pool di nodi.
    • Il nodo esegue l'immagine e le patch più recenti del sistema operativo.
  2. Uno dei nodi esistenti viene identificato per l'aggiornamento.
  3. I pod nel nodo identificato vengono terminati correttamente e pianificati negli altri nodi nel pool di nodi.
  4. Il nodo svuotato viene eliminato dal cluster del servizio Azure Kubernetes.
  5. I passaggi da 1 a 4 vengono ripetuti fino a quando tutti i nodi non vengono sostituiti correttamente come parte del processo di aggiornamento.

Per altre informazioni, vedere Aggiornare un cluster del servizio Azure Kubernetes.

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 tramite VPN da sito a sito di Azure o Express Route. Definire i controller in ingresso Kubernetes con indirizzi IP privati e interni 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 IP di origine e di destinazione, le porte e i protocolli consentiti o negati 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 specifica la propria subnet per il cluster del servizio Azure Kubernetes (se si usa Azure CNI o Kubenet), non modificare il gruppo di sicurezza di rete a livello di scheda 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. Verificare che non interferiscano con la gestione del traffico necessaria, ad esempio l'accesso al servizio di bilanciamento del carico, la comunicazione con il piano di controllo e l'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 consentire o negare percorsi di rete specifici all'interno del cluster in base agli spazi dei nomi e ai selettore di etichette.

Sicurezza dell'applicazione

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

Segreti di Kubernetes

Con un segreto Kubernetes, si inserisce dati sensibili nei pod, ad esempio le credenziali di accesso o le chiavi.

  1. Creare un segreto usando l'API 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 dai tmpf 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 Segreti riduce le informazioni riservate definite nel manifesto YAML del pod o 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 segreto non elaborati contengono i dati segreti in formato base64 (vedere la documentazione ufficiale per altri dettagli). Trattare questi file come informazioni riservate e non eseguirne mai il commit nel controllo del codice sorgente.

I segreti kubernetes vengono archiviati in etcd, un archivio chiave-valore distribuito. 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 principali del servizio Kubernetes e del servizio Azure Kubernetes, vedere: