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

Si applica a: ✔️ Servizio Azure Kubernetes Standard automatico ✔️ Servizio Azure Kubernetes standard

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). Si apprenderà 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.

Responsabilità di sicurezza in modalità cluster di AKS

AKS supporta due modalità del cluster: AKS Automatico e AKS Standard. Gli obiettivi di sicurezza sono gli stessi in entrambe le modalità, ma la responsabilità dell'implementazione è diversa.

AKS Automatic include una baseline rafforzata con più controlli preconfigurati per le configurazioni supportate. AKS Standard offre un controllo di configurazione diretto più ampio, che aumenta la responsabilità dell'operatore per la configurazione di base e le operazioni in corso.

Area AKS Automatico Servizio Azure Kubernetes Standard
Baseline di autenticazione e autorizzazione del cluster Altre impostazioni predefinite preconfigurate nelle configurazioni supportate Comunemente configurato in modo esplicito dagli operatori
Protezione avanzata della rete del server API Maggiore comportamento della linea di base preconfigurata nelle configurazioni supportate Scelte esplicite di irrobustimento da parte degli operatori
Criteri e controlli di sicurezza di base Altre impostazioni predefinite preconfigurate nelle configurazioni supportate Attivazione esplicita del criterio e selezione della modalità
Controlli di igiene delle immagini Controlli di base disponibili nelle configurazioni supportate Abilitazione esplicita e responsabilità del ciclo di vita
Operazioni del pool di nodi di sistema Altro comportamento gestito dal servizio Altro comportamento gestito dall'operatore
Aggiornare la proprietà Altre impostazioni predefinite per gli aggiornamenti gestiti Strategia e governance dell'implementazione selezionati dall'operatore

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.

Queste indicazioni si applicano a entrambe le modalità. Anche quando AKS Automatic offre impostazioni di sicurezza predefinite, l'integrazione della protezione dalle minacce e i flussi di lavoro di risposta agli avvisi rimangono responsabilità operative del team.

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.

In AKS Automatic, l'autorizzazione e le baseline di sicurezza sono maggiormente preconfigurate nelle configurazioni supportate, quindi gli operatori si concentrano sulla convalida, sulla governance e sulla gestione delle eccezioni. In AKS Standard, gli operatori in genere configurano direttamente questi controlli e ne gestiscono il ciclo di vita.

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.

Note

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

In AKS Standard, assicurarsi che il modello di rete e il motore dei criteri selezionati supportino questo percorso dei criteri. In AKS Automatic, applicare restrizioni equivalenti in uscita a livello di spazio dei nomi, se supportate dalla configurazione del cluster.

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.

L'utilizzo degli spazi dei nomi utente migliora l'isolamento dell'host e limita lo spostamento laterale in caso di violazioni del contenitore. Questi miglioramenti sono significativi indipendentemente dal fatto che il pod sia in esecuzione come radice o meno.

Per un controllo ancora più granulare delle azioni dei contenitori, è anche possibile usare funzionalità di sicurezza predefinite di Linux, come AppArmor e seccomp.

Anche se AKS Automatic fornisce impostazioni predefinite rafforzate, i controlli di sicurezza a livello del carico di lavoro restano di competenza dei team applicativi e della piattaforma.

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.

In AKS Automatic, il comportamento relativo agli aggiornamenti è maggiormente preconfigurato nelle configurazioni supportate e gli operatori devono concentrarsi sulla convalida della preparazione dei carichi di lavoro e sulla governance delle versioni. In AKS Standard gli operatori scelgono e regolano la strategia di aggiornamento e la tempistica dell'implementazione più direttamente.

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

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

È quindi possibile aggiornare il cluster AKS usando 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 potrebbe 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.

Per altre informazioni sugli aggiornamenti nel servizio Azure Kubernetes, vedere Versioni di Kubernetes supportate nel servizio Azure Kubernetes ed Eseguire l'aggiornamento di 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.

In AKS Automatic, il comportamento di aggiornamento dei nodi è maggiormente preconfigurato nelle configurazioni supportate. In AKS Standard gli operatori definiscono in genere la governance delle patch e del riavvio con controlli operativi espliciti.

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.

Contenuti correlati

Per altre informazioni sul servizio Azure Kubernetes e sulla protezione del cluster del servizio Azure Kubernetes, vedere gli articoli seguenti:

  • Last updated on