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 in servizio Azure Kubernetes (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 della sicurezza del sistema operativo più recenti e le versioni di Kubernetes.
  • Fornire il traffico sicuro dei pod e l'accesso alle credenziali sensibili.

Questo articolo presenta i concetti di base che proteggono 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 promosse verso il basso nella pipeline, che 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 del 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 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 allegare le firme alle immagini per garantire che le distribuzioni provengano da una posizione attendibile.

Sicurezza del cluster

Nel servizio Azure Kubernetes i componenti master 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 altre informazioni, 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 Linux di Azure.
  • 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 successive per i pool di nodi Linux usano containerd come runtime del contenitore. L'uso con containerd 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 del contenitore predefinito.

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

Autorizzazione del nodo

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

Distribuzione di nodi

I nodi vengono distribuiti in una subnet di rete virtuale privata senza indirizzi IP pubblici assegnati. SSH è abilitato per impostazione predefinita per la risoluzione dei problemi e la gestione ed è accessibile solo tramite 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 della macchina virtuale, Azure Managed Disks sono dischi Premium supportati da unità SSD ad alte prestazioni. 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, come 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 su come 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 fornisce macchine virtuali isolate da usare come nodi agente in un cluster del servizio Azure Kubernetes. Queste macchine virtuali sono isolate per un tipo di hardware specifico e dedicate a un singolo cliente.

Selezionare una delle dimensioni delle macchine virtuali isolate come dimensioni 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 l'aggiornamento di un cluster e componenti del servizio Azure Kubernetes, per 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 e svuota in modo sicuro ogni nodo e aggiornamento del servizio Azure Kubernetes.

Blocco e svuotamento

Durante il processo di aggiornamento, i nodi del servizio Azure Kubernetes vengono separati singolarmente dal cluster per impedire la pianificazione di 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 normalmente e pianificati negli altri nodi del 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 usando 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 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 ,indipendentemente dall'uso di 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. 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 o 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 selettori di etichetta.

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 un'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 credenziali di accesso o 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 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 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 del segreto non elaborato contengono i dati segreti in formato Base64. Per altre informazioni, vedere la documentazione ufficiale. Considerare questi file come informazioni riservate e non eseguirne 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 di base di Kubernetes e del servizio Azure Kubernetes, vedere: