Configurare l'isolamento rete per il servizio Azure Kubernetes

Completato

Quando si gestiscono i cluster nel servizio Azure Kubernetes, spesso è necessario isolare team e carichi di lavoro. Il servizio Azure Kubernetes offre flessibilità a livello di esecuzione di cluster multi-tenant e isolamento delle risorse. Per ottimizzare l'investimento in Kubernetes, è importante comprendere le funzionalità di multi-tenancy e isolamento di AKS (Azure Kubernetes Service).

Progettare cluster per multi-tenancy

Kubernetes consente di isolare logicamente i team e i carichi di lavoro nello stesso cluster. L'obiettivo è fornire il numero minimo di privilegi limitati alle risorse necessarie a ciascun team. Uno spazio dei nomi Kubernetes crea un limite di isolamento logico. Altre funzionalità e considerazioni di Kubernetes per l'isolamento e la multi-tenancy includono le aree seguenti:

  • Procedure consigliate per l'isolamento del cluster nel servizio Azure Kubernetes
    • Progettare cluster per multi-tenancy
      • Pianificazione
      • Rete
      • Autenticazione e autorizzazione
      • Contenitori
  • Cluster logicamente isolati
  • Cluster fisicamente isolati

Pianificazione

La pianificazione usa funzionalità di base come quote di risorse e budget di interruzione dei pod.

Le funzionalità più avanzate dell'utilità di pianificazione includono:

  • Contaminazioni e tolleranze.
  • Selettori di nodo.
  • Affinità o antiaffinità tra nodi e pod.

Rete

Networking utilizza criteri di rete per controllare il flusso di traffico in entrata e in uscita dai pod.

Autenticazione e autorizzazione

L'autenticazione e l'autorizzazione usano:

  • Controllo degli accessi in base al ruolo.
  • Integrazione di Microsoft Entra.
  • Identità di lavoro per l'autenticazione dei pod con i servizi Azure.
  • Segreti in Azure Key Vault.

Contenitori

I contenitori includono:

  • Standard di sicurezza dei pod e ammissione di sicurezza dei pod per l'applicazione delle policy di sicurezza.
  • Componente aggiuntivo Criteri di Azure per AKS per applicare la sicurezza dei pod su larga scala.
  • Analisi di immagini e runtime per individuare le vulnerabilità usando Microsoft Defender per contenitori.
  • Uso di App Armor o Seccomp (Secure Computing) per limitare l'accesso dei contenitori al nodo sottostante.

Cluster logicamente isolati

Indicazioni sulle procedure consigliate: separare team e progetti usando l'isolamento logico. Minimizzare il numero di cluster AKS fisici distribuiti per isolare team o applicazioni.

Con l'isolamento logico, è possibile usare un singolo cluster AKS per più carichi di lavoro, team o ambienti. Gli spazi dei nomi Kubernetes costituiscono il limite di isolamento logico per carichi di lavoro e risorse.

Diagramma che mostra un esempio di cluster isolati logicamente.

La separazione logica dei cluster offre in genere una densità di pod superiore rispetto ai cluster fisicamente isolati, con meno capacità di calcolo in eccesso inattiva nel cluster. In combinazione con il ridimensionamento automatico del cluster Kubernetes, è possibile aumentare o ridurre il numero di nodi per soddisfare le esigenze. Questo approccio consigliato riduce al minimo i costi eseguendo solo il numero di nodi richiesto.

Gli ambienti Kubernetes non sono completamente sicuri per l'utilizzo multi-tenant ostile. In un ambiente multitenant, più tenant operano su un'infrastruttura condivisa. Se tutti i tenant non possono essere considerati attendibili, è necessario pianificare in modo aggiuntivo per impedire ai tenant di influire sulla sicurezza e sul servizio di altri utenti.

Altre funzionalità di sicurezza, come Kubernetes RBAC per i nodi, bloccano in modo efficiente gli exploit. Per una vera sicurezza quando si eseguono carichi di lavoro multi-tenant ostili, è consigliabile considerare attendibile solo un hypervisor. Il dominio di sicurezza per Kubernetes diventa l'intero cluster e non un singolo nodo.

Per questi tipi di carichi di lavoro multi-tenant ostili è consigliabile usare cluster fisicamente isolati.

Cluster fisicamente isolati

Indicazioni sulle procedure consigliate: ridurre al minimo l'uso dell'isolamento fisico per ogni distribuzione separata di team o applicazione e usare invece l'isolamento logico.

La separazione fisica dei cluster AKS è un approccio comune all'isolamento del cluster. In questo modello di isolamento, ai team o ai carichi di lavoro viene assegnato il proprio cluster AKS. Anche se l'isolamento fisico potrebbe essere simile al modo più semplice per isolare carichi di lavoro o team, comporta un sovraccarico finanziario e di gestione. Con cluster fisicamente isolati, è necessario gestire più cluster e fornire singolarmente l'accesso e assegnare autorizzazioni. Vengono addebitati anche costi per ogni singolo nodo.

Diagramma che mostra un esempio di cluster isolati fisicamente.

I cluster fisicamente isolati hanno in genere una bassa densità di pod. Poiché ogni team o carico di lavoro ha il proprio cluster del servizio Azure Kubernetes, il cluster spesso è sottoposto a over-provisioning delle risorse di calcolo. Spesso alcuni pod vengono pianificati in tali nodi. La capacità dei nodi non richiesta non può essere usata per applicazioni o servizi in fase di sviluppo da parte di altri team. Queste risorse in eccesso contribuiscono ai costi aggiuntivi in cluster isolati fisicamente.