Procedure consigliate per la sicurezza e gli aggiornamenti del cluster nel servizio Azure Kubernetes

  • Articolo

Quando si gestiscono i cluster nel servizio Azure Kubernetes, la sicurezza dei carichi di lavoro e dei dati è una considerazione fondamentale. Quando si eseguono cluster multi-tenant usando l'isolamento logico, è soprattutto necessario proteggere l'accesso alle risorse e ai carichi di lavoro. Ridurre al minimo il rischio di attacco applicando gli ultimi aggiornamenti della sicurezza del sistema operativo Kubernetes e del nodo.

Questo articolo illustra in particolare come proteggere il cluster del servizio Azure Kubernetes (AKS). Scopri come:

  • Usare Microsoft Entra ID e il controllo degli accessi in base al ruolo di Kubernetes per proteggere l'accesso al server API.
  • Proteggere l'accesso del contenitore alle risorse dei nodi.
  • Aggiornare un cluster del servizio Azure Kubernetes alla versione più recente di Kubernetes.
  • Mantenere i nodi aggiornati e applicare automaticamente le patch di protezione.

È anche possibile leggere le procedure consigliate per la gestione delle immagini del contenitore e la sicurezza dei pod.

Abilitare la protezione dalle minacce

Materiale sussidiario sulle procedure consigliate

È possibile abilitare Defender per contenitori per proteggere i contenitori. Defender per contenitori può valutare le configurazioni del cluster e fornire raccomandazioni sulla sicurezza, eseguire analisi delle vulnerabilità e fornire protezione e avvisi in tempo reale per nodi e cluster Kubernetes.

Proteggere l'accesso al server dell'API e ai nodi del cluster

Materiale sussidiario sulle procedure consigliate

Uno dei modi più importanti per proteggere il cluster consiste nel proteggere l'accesso al server API Kubernetes. Per controllare l'accesso al server API, integrare il controllo degli accessi in base al ruolo di Kubernetes con Microsoft Entra ID. Con questi controlli è possibile proteggere il servizio Azure Kubernetes allo stesso modo in cui si protegge l'accesso alle sottoscrizioni di Azure.

Il server dell'API Kubernetes fornisce un singolo punto di connessione per le richieste di esecuzione di azioni all'interno di un cluster. Per proteggere e controllare l'accesso al server API, limitare l'accesso e fornire i livelli di autorizzazione più bassi possibili. anche se questo approccio non è univoco per Kubernetes, è particolarmente importante quando è stato isolato logicamente il cluster del servizio Azure Kubernetes per l'uso multi-tenant.

Microsoft Entra ID offre una soluzione di gestione delle identità pronta per l'organizzazione che si integra con i cluster del servizio Azure Kubernetes. Poiché Kubernetes non fornisce una soluzione di gestione delle identità, potrebbe essere difficile limitare in modo granulare l'accesso al server API. Con i cluster integrati di Microsoft Entra nel servizio Azure Kubernetes, si usano gli account utente e di gruppo esistenti per autenticare gli utenti nel server API.

Integrazione di Microsoft Entra per i cluster del servizio Azure Kubernetes

Usando il controllo degli accessi in base al ruolo di Kubernetes e Microsoft Entra ID-integration, è possibile proteggere il server API e fornire le autorizzazioni minime necessarie per un set di risorse con ambito, ad esempio un singolo spazio dei nomi. È possibile concedere diversi utenti o gruppi di Microsoft Entra a ruoli Kubernetes diversi. Con autorizzazioni granulari, è possibile limitare l'accesso al server API e fornire un audit trail chiaro delle azioni eseguite.

La procedura consigliata consiste nell'usare dei gruppi per fornire l'accesso a file e cartelle anziché alle singole identità. Ad esempio, usare un'appartenenza al gruppoMicrosoft Entra ID per associare gli utenti ai ruoli Kubernetes anziché ai singoli utenti. Man mano che l'appartenenza al gruppo di un utente cambia, le autorizzazioni di accesso nel cluster del servizio Azure Kubernetes cambiano di conseguenza.

Nel frattempo, si supponga di associare l'utente singolo direttamente a un ruolo e alle modifiche della funzione del processo. Mentre le appartenenze ai gruppi di Microsoft Entra si aggiornano, le relative autorizzazioni per il cluster del servizio Azure Kubernetes non vengono aggiornate. In questo scenario, l'utente finisce con più autorizzazioni di quelle necessarie.

Per altre informazioni sull'integrazione di Microsoft Entra, sul controllo degli accessi in base al ruolo di Kubernetes e sul controllo degli accessi in base al ruolo di Azure, vedere Procedure consigliate per l'autenticazione e l'autorizzazione nel servizio Azure Kubernetes.

Limitare l'accesso all'API metadati dell'istanza

Materiale sussidiario sulle procedure consigliate

Aggiungere un criterio di rete in tutti gli spazi dei nomi utente per bloccare l'uscita dei pod all'endpoint dei metadati.

Nota

Per implementare i criteri di rete, includere l'attributo --network-policy azure durante la creazione del cluster del servizio Azure Kubernetes. Usare il comando seguente per creare il cluster: az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

Proteggere l'accesso del contenitore alle risorse

Materiale sussidiario sulle procedure consigliate

Limitare l'accesso alle azioni che i contenitori possono eseguire. Concedere il minor numero possibile di autorizzazioni ed evitare l'uso dell'accesso radice o dell'escalation dei privilegi.

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.

Per un controllo ancora più granulare delle azioni dei contenitori, è anche possibile usare funzionalità di sicurezza predefinite di Linux, come AppArmor e seccomp. Per altre informazioni, vedere Proteggere l'accesso del contenitore alle risorse.

Eseguire regolarmente l'aggiornamento alla versione più recente di Kubernetes

Materiale sussidiario sulle procedure consigliate

Per rimanere aggiornati sulle nuove funzionalità e sulle correzioni di bug, aggiornare regolarmente la versione di Kubernetes nel cluster del servizio Azure Kubernetes.

Kubernetes rilascia nuove funzionalità con maggiore frequenza rispetto alle piattaforme di infrastruttura più tradizionali. Gli aggiornamenti di Kubernetes includono:

  • Nuove funzionalità
  • Correzioni di bug o sicurezza

Le nuove funzionalità in genere passano attraverso lo stato alfa e beta prima che diventino stabili. Una volta stabili, sono disponibili a livello generale e consigliati per l'uso in produzione. Il nuovo ciclo di rilascio delle funzionalità di Kubernetes consente di aggiornare Kubernetes senza incontrare regolarmente modifiche di rilievo o modificare le distribuzioni e i modelli.

Il servizio Azure Kubernetes supporta tre versioni secondarie di Kubernetes. Dopo aver introdotto una nuova versione di patch secondaria, le versioni secondarie meno recenti e le versioni patch supportate vengono ritirate. Gli aggiornamenti secondari di Kubernetes vengono eseguiti periodicamente. Per rimanere all'interno del supporto, assicurarsi di disporre di un processo di governance per verificare la presenza di aggiornamenti necessari. Per altre informazioni, vedere Versioni Kubernetes supportate nel servizio Azure Kubernetes.

Per verificare le versioni disponibili per il cluster in uso, usare il comando az aks get-upgrades come illustrato nell'esempio seguente:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

È quindi possibile aggiornare il cluster AKS tramite il comando az aks upgrade. Il processo di aggiornamento è sicuro:

  • Blocca e svuota un nodo alla volta.
  • Pianifica i pod nei nodi rimanenti.
  • Distribuisce un nuovo nodo che esegue le versioni più recenti del sistema operativo e Kubernetes.

Importante

Testare le nuove versioni secondarie in un ambiente di test di sviluppo e verificare che il carico di lavoro rimanga integro con la nuova versione di Kubernetes.

Kubernetes può deprecare le API (ad esempio nella versione 1.16) su cui si basano i carichi di lavoro. Quando si apportano nuove versioni nell'ambiente di produzione, è consigliabile usare più pool di nodi in versioni separate e aggiornare singoli pool uno alla volta per eseguire progressivamente l'aggiornamento in un cluster. Se si eseguono più cluster, aggiornare un cluster alla volta per monitorare progressivamente l'impatto o le modifiche.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

Per altre informazioni sugli aggiornamenti nel servizio Azure Container, vedere Versioni Kubernetes supportate nel servizio Azure Kubernetes e Aggiornare un cluster del servizio Azure Kubernetes.

Elaborare gli aggiornamenti dei nodi Linux

Ogni sera, i nodi Linux nel servizio Azure Kubernetes ottengono patch di sicurezza tramite il canale di aggiornamento della distribuzione. Questo comportamento viene configurato automaticamente quando i nodi vengono distribuiti in un cluster del servizio Azure Kubernetes. Per ridurre al minimo le interruzioni del servizio e l'impatto sui carichi di lavoro in esecuzione, i nodi non vengono riavviati automaticamente se una patch di protezione o un aggiornamento del kernel lo richiede. Per altre informazioni su come gestire i riavvii dei nodi, vedere Applicare aggiornamenti di sicurezza e del kernel ai nodi nel servizio Azure Kubernetes.

Aggiornamenti delle immagini del nodo

Gli aggiornamenti automatici applicano aggiornamenti al sistema operativo del nodo Linux, ma l'immagine usata per creare nodi per il cluster rimane invariata. Se viene aggiunto un nuovo nodo Linux al cluster, l'immagine originale viene usata per creare il nodo. Questo nuovo nodo riceverà tutti gli aggiornamenti della sicurezza e del kernel disponibili durante il controllo automatico ogni notte, ma rimarrà senza patch fino al completamento di tutti i controlli e i riavvii. È possibile usare l'aggiornamento dell'immagine del nodo per verificare la presenza e aggiornare le immagini del nodo usate dal cluster. Per altre informazioni sull'aggiornamento delle immagini del nodo, vedere Aggiornamento dell'immagine del nodo del servizio Azure Kubernetes.

Elaborare gli aggiornamenti dei nodi di Windows Server

Per i nodi di Windows Server, eseguire regolarmente un'operazione di aggiornamento dell'immagine del nodo per completare e svuotare in modo sicuro i pod e distribuire nodi aggiornati.