Migliorare la sicurezza dell'accesso alla rete a Kubernetes

Questo articolo confronta le modalità di rete per il servizio Azure Kubernetes e il servizio Amazon Elastic Kubernetes. Descrive come migliorare la sicurezza della connessione al server API gestito di un cluster AKS. Include anche opzioni per limitare l'accesso alla rete pubblica.

Modalità di rete amazon EKS

È possibile usare Amazon Virtual Private Cloud (VPC) per avviare le risorse di Amazon Web Services (AWS) in una rete virtuale con subnet pubbliche e private. Le subnet sono intervalli di indirizzi IP all'interno del VPC. Una subnet pubblica ospita risorse che si connettono a Internet. Una subnet privata ospita risorse che non si connettono a Internet pubblico. Amazon EKS può effettuare il provisioning di gruppi di nodi gestiti in subnet pubbliche e private.

Il controllo di accesso agli endpoint consente di configurare se l'endpoint del server API è raggiungibile da Internet pubblico o tramite il VPC. Amazon EKS offre diversi modi per controllare l'accesso all'endpoint del cluster. È possibile abilitare l'endpoint pubblico predefinito, un endpoint privato o entrambi gli endpoint contemporaneamente. Quando si abilita l'endpoint pubblico, è possibile aggiungere restrizioni CIDR (Classless Inter-Domain Routing) per limitare gli indirizzi IP client che possono connettersi all'endpoint pubblico.

L'impostazione dell'endpoint del cluster determina il modo in cui i nodi amazon EKS si connettono al piano di controllo Kubernetes gestito. È possibile modificare le impostazioni dell'endpoint tramite la console amazon EKS o l'API. Per altre informazioni, vedere Controllo di accesso degli endpoint del cluster Amazon EKS.

Solo endpoint pubblico

La modalità predefinita per i nuovi cluster Amazon EKS espone il piano di controllo tramite un endpoint pubblico. Quando è abilitato solo l'endpoint pubblico per il cluster, le richieste API Kubernetes provenienti dall'interno del VPC lasciano il VPC, ma non lasciano la rete di Amazon. Queste richieste includono la comunicazione dal nodo di lavoro al piano di controllo. I nodi si connettono al piano di controllo tramite un indirizzo IP pubblico e una route a un gateway Internet. In alternativa, possono usare un percorso verso un gateway NAT (Network Address Translation), per utilizzare l'indirizzo IP pubblico del gateway NAT.

Endpoint pubblici e privati

Quando si abilitano sia gli endpoint pubblici che privati, le richieste API Kubernetes dall'interno del VPC comunicano al piano di controllo tramite le interfacce di rete elastica gestite da Amazon EKS (ENI) nel VPC. Il server API del cluster è raggiungibile da Internet.

Solo endpoint privato

Quando si abilita solo l'endpoint privato, tutto il traffico verso il server API del cluster, ad esempio kubectl o helm comandi, deve provenire dall'interno del VPC del cluster o da una rete connessa. L'accesso pubblico al server API da Internet è disabilitato. Per implementare questa modalità di accesso, usare AWS Virtual Private Network (VPN) o AWS DirectConnect al VPC. Per limitare l'accesso all'endpoint senza VPN AWS o DirectConnect, è possibile aggiungere restrizioni CIDR all'endpoint pubblico per limitare le connessioni senza configurare più rete.

Se si disabilita l'accesso pubblico per l'endpoint server dell'API Kubernetes del cluster, è possibile accedere all'endpoint server dell'API Kubernetes in uno dei modi seguenti:

• Rete connessa: Connettere la rete al VPC usando un gateway di transito AWS e quindi usare un computer nella rete connessa. In alternativa, è possibile usare altre opzioni di connettività. Assicurarsi che il gruppo di sicurezza del piano di controllo Amazon EKS contenga regole per consentire il traffico in ingresso sulla porta 443 dalla rete connessa.

• Bastion host Amazon EC2: È possibile avviare un'istanza di Amazon EC2 in una subnet pubblica nel VPC del cluster. Accedere a tale istanza tramite Secure Shell (SSH) per eseguire kubectl comandi. Assicuratevi che il gruppo di sicurezza del piano di controllo Amazon EKS contenga regole per consentire il traffico in ingresso sulla porta 443 dal bastion host. Per altre informazioni, vedere Visualizzare i requisiti del gruppo di sicurezza Amazon EKS per i cluster.
  
  Quando si configura kubectl per l'host bastion, usare le credenziali AWS che corrispondono alla configurazione del controllo degli accessi in base al ruolo del cluster. In alternativa, è possibile aggiungere l'entità di sicurezza di AWS Identity and Access Management (IAM) che il bastion utilizza alla configurazione RBAC (Role-Based Access Control) prima di rimuovere l'accesso pubblico all'endpoint. Per altre informazioni, vedere Concedere agli utenti e ai ruoli IAM l'accesso alle API Kubernetes e accesso non autorizzato o negato (kubectl).

• AWS Cloud9 IDE: AWS Cloud9 è un ambiente di sviluppo integrato (IDE) basato sul cloud che è possibile usare per scrivere, eseguire ed eseguire il debug del codice solo con un browser. È possibile creare un IDE AWS Cloud9 nel VPC del cluster e usare l'IDE per comunicare con il cluster. Per altre informazioni, vedere Creare un ambiente in AWS Cloud9. Assicurati che il gruppo di sicurezza del piano di controllo di Amazon EKS contenga regole per consentire il traffico in ingresso sulla porta 443 dal gruppo di sicurezza del tuo IDE. Per altre informazioni, vedere Visualizzare i requisiti del gruppo di sicurezza Amazon EKS per i cluster.
  
  Quando si configura kubectl per l'IDE di AWS Cloud9, utilizzare le credenziali AWS che corrispondano alla configurazione RBAC del cluster. In alternativa, è possibile aggiungere l'entità IAM utilizzata dall'IDE alla configurazione RBAC prima di rimuovere l'accesso pubblico all'endpoint. Per altre informazioni, vedere Concedere agli utenti e ai ruoli IAM l'accesso alle API Kubernetes e accesso non autorizzato o negato (kubectl).

Per altre informazioni sulle opzioni di connettività, vedere Accedere a un server API solo privato.

Accesso di rete del Servizio Azure Kubernetes al server API

Per proteggere l'accesso di rete all'API Kubernetes nel servizio Azure Kubernetes, è possibile usare un cluster del servizio Azure Kubernetes privato o intervalli di indirizzi IP autorizzati.

Cluster AKS privato

Un cluster AKS privato aiuta a garantire che il traffico di rete tra il server API e i nodi dell'agente rimanga all'interno della rete virtuale. In un cluster AKS privato, il piano di controllo o il server API ha indirizzi IP interni. Un cluster privato garantisce che il traffico di rete tra il server API e i pool di nodi rimanga solo nella rete privata.

In un cluster AKS privato, il server API ha un indirizzo IP interno raggiungibile solo tramite un endpoint privato di Azure situato nella stessa rete virtuale. Le macchine virtuali nella stessa rete virtuale possono comunicare privatamente con il piano di controllo tramite questo endpoint privato. Il piano di controllo o il server API è ospitato nella sottoscrizione gestita da Azure. Il cluster AKS e le relative pool di nodi sono nella sottoscrizione del cliente.

Il diagramma seguente illustra una configurazione di un cluster AKS privato.

Scaricare un file di Visio di questa architettura.

Per effettuare il provisioning di un cluster del servizio Azure Kubernetes privato, il provider di risorse del servizio Azure Kubernetes crea un nome di dominio completo privato (FQDN) per il gruppo di risorse del nodo in una zona DNS (Domain Name System) privato. Facoltativamente, il servizio Azure Kubernetes può anche creare un FQDN pubblico con un record di indirizzi A corrispondente nella zona DNS pubblica di Azure. I nodi dell'agente usano il A record nella zona DNS privata per risolvere l'indirizzo IP dell'endpoint privato per la comunicazione con il server API.

Il provider di risorse del servizio Azure Kubernetes può creare la zona DNS privata nel gruppo di risorse del nodo oppure è possibile creare la zona DNS privata e passare il relativo ID risorsa al sistema di provisioning. Per creare un cluster privato, è possibile usare Terraform con Azure, Bicep, modelli di Azure Resource Manager, l'interfaccia della riga di comando di Azure, il modulo Di Azure PowerShell o l'API REST di Azure.

È possibile abilitare un FQDN pubblico per il server API durante il provisioning o usando il comando az aks update con il --enable-public-fqdn parametro nei cluster esistenti. Se si abilita il nome di dominio completo pubblico, le macchine virtuali che accedono al server devono trovarsi nella stessa rete virtuale che ospita il cluster o in una rete connessa tramite peering di rete virtuale o VPN da sito a sito. Esempi di queste macchine virtuali includono un agente autogestito di Azure DevOps o un runner autogestito di GitHub Actions.

Per un cluster del servizio Azure Kubernetes privato, disabilitare il nome di dominio completo pubblico del server API. Per comunicare con il piano di controllo privato, una macchina virtuale deve trovarsi nella stessa rete virtuale o in una rete virtuale con peering con un collegamento di rete virtuale alla zona DNS privata. Il A record nella zona DNS privata risolve il nome di dominio completo del server API nell'indirizzo IP dell'endpoint privato che comunica con il piano di controllo sottostante. Per ulteriori informazioni, consultare Creare un cluster AKS privato.

Opzioni di distribuzione del cluster privato

Il provider di risorse del servizio Azure Kubernetes espone i parametri seguenti per personalizzare le distribuzioni del cluster del servizio Azure Kubernetes privato:

• La authorizedIpRanges stringa specifica gli intervalli di indirizzi IP consentiti in formato CIDR.

• Il disableRunCommand valore booleano specifica se disabilitare il run comando per il cluster.

• Il enablePrivateCluster valore booleano specifica se creare il cluster come privato.

• Il enablePrivateClusterPublicFQDN valore Boolean specifica se creare un altro FQDN pubblico per il cluster privato.

• La privateDnsZone stringa specifica una zona DNS privata nel gruppo di risorse del nodo. Se non si specifica un valore, il provider di risorse crea la zona. È possibile specificare i valori seguenti:

  • System è il valore predefinito.

  • None è impostato su DNS pubblico, quindi AKS non crea una zona DNS privata.

  • <Your own private DNS zone resource ID> usa una zona DNS privata creata nel formato privatelink.<region>.azmk8s.io o <subzone>.privatelink.<region>.azmk8s.io.

La tabella seguente illustra le opzioni di configurazione DNS per distribuire un cluster del servizio Azure Kubernetes privato:

Connettività e gestione dei cluster privati

In un cluster del servizio Azure Kubernetes privato l'endpoint del server API non ha un indirizzo IP pubblico. Per stabilire la connettività di rete al cluster privato, è possibile usare una delle opzioni seguenti:

• Creare una VM nella stessa rete virtuale del cluster AKS che utilizza il comando az vm create con il flag --vnet-name.

• Usare una macchina virtuale in una rete virtuale separata e configurare il peering della rete virtuale con la rete virtuale del cluster AKS.

• Configurare un gateway VPN o ExpressRoute di Azure per connettersi alla rete virtuale del cluster.

• Creare una connessione ad un endpoint privato di Azure all'interno di una rete virtuale diversa.

• Usare un'istanza di Azure Cloud Shell distribuita in una subnet connessa al server API per il cluster.

Usare l'interfaccia della riga di comando di Azure per eseguire il comando az aks command invoke per accedere ai cluster privati senza configurare un gateway VPN o ExpressRoute. Usare questo comando per richiamare in remoto altri comandi, ad esempio kubectl e helm, nel cluster privato tramite l'API di Azure, senza connettersi direttamente al cluster. Per usare command invoke, configurare le autorizzazioni necessarie per le azioni Microsoft.ContainerService/managedClusters/runcommand/action e Microsoft.ContainerService/managedclusters/commandResults/read.

Nel portale di Azure è possibile usare la Run command funzionalità per eseguire comandi nel cluster privato. Questa funzionalità usa la command invoke funzionalità per eseguire i comandi nel cluster. La funzionalità Run command crea un pod che fornisce strumenti kubectl e helm per gestire il cluster. Anche Run command fornisce un ambiente Bash all'interno del pod che include strumenti come jq, xargs, grep, e awk.

È possibile usare Azure Bastion nella stessa rete virtuale o in una rete virtuale con peering per connettersi a una macchina virtuale di gestione jump box. Azure Bastion è una piattaforma distribuita come servizio (PaaS) completamente gestita che è possibile usare per connettersi a una macchina virtuale tramite il browser e il portale di Azure. Azure Bastion offre connettività RDP (Remote Desktop Protocol) o SSH altamente sicura e trasparente tramite TLS (Transport Layer Security) direttamente dal portale di Azure. Quando le macchine virtuali si connettono tramite Azure Bastion, non richiedono un indirizzo IP pubblico, un agente o un software client speciale.

Integrazione della rete virtuale del server API

Un cluster AKS configurato con API Server VNet Integration proietta l'endpoint del server API direttamente in una subnet delegata. La subnet si trova nella rete virtuale in cui viene distribuito AKS. L'integrazione rete virtuale del server API consente la comunicazione di rete tra il server API e i nodi del cluster, senza collegamento privato o tunnel. Il server API è disponibile dietro un indirizzo VIP del servizio di bilanciamento del carico interno che si trova nella subnet delegata. I nodi sono configurati per utilizzare l'VIP (Virtual IP) del bilanciatore del carico interno. Usare l'integrazione rete virtuale del server API per assicurarsi che il traffico di rete tra il server API e i pool di nodi rimanga solo nella rete privata.

Il piano di controllo o il server API si trova in una sottoscrizione Azure gestita da AKS. Il cluster o il pool di nodi è nel tuo abbonamento Azure. Il server e le macchine virtuali che costituiscono i nodi del cluster possono comunicare tra loro tramite gli indirizzi IP vip e pod del server API proiettati nella subnet delegata.

È possibile usare l'integrazione rete virtuale del server API con cluster pubblici e cluster privati. È possibile aggiungere o rimuovere l'accesso pubblico dopo il provisioning del cluster. A differenza dei cluster che non dispongono dell'integrazione della rete virtuale, i nodi dell'agente comunicano sempre direttamente con l'indirizzo IP privato del servizio di bilanciamento del carico interno del server API senza usare DNS. Il traffico che passa dal nodo al traffico del server API si trova nella rete privata. E la connettività da server api a nodo non richiede un tunnel. I client out-of-cluster possono comunicare con il server API normalmente se l'accesso alla rete pubblica è abilitato. Se l'accesso alla rete pubblica è disabilitato, seguire la stessa metodologia di configurazione DNS dei cluster privati standard. Per ulteriori informazioni, vedere Creare un cluster AKS con integrazione di VNet del server API.

Intervalli di indirizzi IP autorizzati

È anche possibile usare intervalli di indirizzi IP autorizzati per migliorare la sicurezza del cluster e ridurre al minimo gli attacchi al server API. Gli intervalli di indirizzi IP autorizzati limitano l'accesso al piano di controllo di un cluster del servizio Azure Kubernetes pubblico a un elenco noto di indirizzi IP e CIDR. Quando si usa questa opzione, il server API è ancora esposto pubblicamente, ma l'accesso è limitato.

Il comando Azure CLI seguente az aks update autorizza gli intervalli di indirizzi IP:

 az aks update \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --api-server-authorized-ip-ranges  73.140.245.0/24

Considerazioni sulla connettività AKS

Considera i seguenti punti chiave per la connettività di AKS:

• Un cluster privato AKS offre maggiore sicurezza e isolamento rispetto agli intervalli di indirizzi IP autorizzati. Tuttavia, non è possibile convertire un cluster del servizio Azure Kubernetes pubblico esistente in un cluster privato. È invece possibile abilitare gli intervalli di indirizzi IP autorizzati per qualsiasi cluster del servizio Azure Kubernetes esistente.

• Non è possibile applicare intervalli di indirizzi IP autorizzati a un endpoint del server API privato. Si applicano solo al server API pubblico.

• I cluster privati non supportano gli agenti ospitati da Azure DevOps. Dovresti invece utilizzare agenti self-hosted.

• Affinché Azure Container Registry funzioni con un cluster AKS privato, è necessario configurare un collegamento privato per Azure Container Registry nella rete virtuale del cluster. In alternativa, è possibile stabilire il peering tra la rete virtuale del Registro Contenitori e la rete virtuale del cluster privato.

• Le limitazioni del collegamento privato di Azure si applicano ai cluster privati.

• Se l'endpoint privato nella subnet del cliente di un cluster privato viene eliminato o modificato, il cluster smette di funzionare.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

• Paolo Salvatori | Ingegnere del servizio principale
• Martin Gjoševski | Senior Service Engineer
• Laura Nicolas | Senior Cloud Solution Architect

Altri collaboratori:

• Chad Kittel | Principal Software Engineer
• Ed Price | Senior Content Program Manager
• Theano Petersen | Redattore Tecnico

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Creare un cluster privato AKS con una zona DNS pubblica
• Crea un cluster AKS (Azure Kubernetes Service) privato usando Terraform e Azure DevOps
• Creare un cluster AKS pubblico o privato usando Azure Gateway NAT e Azure Gateway applicazioni
• Usare endpoint privati con un cluster AKS privato
• Formazione: Introduzione al collegamento privato
• Formazione: Introduzione all'infrastruttura di rete sicura con la sicurezza di rete di Azure

" output is necessary.)

• AKS per i professionisti di Amazon EKS
• Gestione delle identità e degli accessi Kubernetes
• Monitoraggio e registrazione Kubernetes
• Opzioni di archiviazione per un cluster Kubernetes
• Gestione dei costi per Kubernetes
• Gestione del nodo e del pool di nodi Kubernetes
• Governance del cluster