Modifica

Condividi tramite

Accesso sicuro alla rete Kubernetes

Azure Bastion
DNS di Azure
Servizio Azure Kubernetes
Collegamento privato di Azure
Rete virtuale di Azure

Questo articolo confronta le modalità di rete per servizio Azure Kubernetes (AKS) e Amazon Elastic Kubernetes Service (Amazon EKS). L'articolo descrive come migliorare la sicurezza della connessione al server API gestito di un cluster del servizio Azure Kubernetes e le diverse opzioni per limitare l'accesso alla rete pubblica.

Nota

Questo articolo fa parte di una serie di articoli che aiutano i professionisti che hanno familiarità con Amazon EKS per comprendere servizio Azure Kubernetes (servizio Azure Kubernetes).

Modalità di rete amazon EKS

Con Amazon Virtual Private Cloud (Amazon VPC) è possibile avviare le risorse di Amazon Web Services (AWS) in una rete virtuale composta da subnet pubbliche e private o da intervalli di indirizzi IP nel VPC. Una subnet pubblica ospita risorse che devono essere connesse a Internet e una subnet privata ospita risorse che non sono connesse alla rete Internet pubblica. Amazon EKS può effettuare il provisioning di gruppi di nodi gestiti in subnet pubbliche e private.

Il controllo di accesso degli endpoint consente di configurare se l'endpoint del server API è raggiungibile dalla rete Internet pubblica o tramite il VPC. Il servizio Azure Kubernetes 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.

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

Solo endpoint pubblico

L'esposizione del piano di controllo tramite un endpoint pubblico è la modalità predefinita per i nuovi cluster Amazon EKS. Quando è abilitato solo l'endpoint pubblico per il cluster, le richieste API Kubernetes provenienti dall'interno di Amazon VPC, ad esempio il nodo di lavoro per controllare la comunicazione del piano, lasciano il VPC ma non lasciano la rete di Amazon. Affinché i nodi si connettano al piano di controllo, devono usare un indirizzo IP pubblico e una route a un gateway Internet o una route a un gateway NAT (Network Address Translation) in cui possono usare l'indirizzo IP pubblico del gateway NAT.

Endpoint pubblici e privati

Quando gli endpoint pubblici e privati sono abilitati, le richieste API Kubernetes dall'interno del VPC comunicano al piano di controllo tramite le interfacce di rete elastiche gestite dal servizio Azure Kubernetes (ENI) gestite da Amazon EKS nel VPC. Il server API del cluster è accessibile da Internet.

Solo endpoint privato

Quando è abilitato 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. È possibile implementare questa modalità di accesso usando AWS Virtual Private Network (AWS 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.

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

Accesso alla rete del servizio Azure Kubernetes al server API

Esistono due opzioni per proteggere l'accesso di rete all'API Kubernetes nel servizio Azure Kubernetes, un cluster del servizio Azure Kubernetes privato o intervalli IP autorizzati.

Cluster del servizio Azure Kubernetes privato

Un cluster privato del servizio Azure Kubernetes garantisce che il traffico di rete tra il server API e i pool di nodi rimanga all'interno della rete virtuale. In un cluster del servizio Azure Kubernetes privato, il piano di controllo o il server API ha un indirizzo IP interno accessibile solo tramite un endpoint privato di Azure che si trova nella stessa rete virtuale. Qualsiasi macchina virtuale (VM) nella stessa rete virtuale può comunicare privatamente con il piano di controllo tramite l'endpoint privato. Il piano di controllo o il server API è ospitato nella sottoscrizione gestita di Azure, mentre il cluster del servizio Azure Kubernetes e i relativi pool di nodi si trovano nella sottoscrizione del cliente.

Il diagramma seguente illustra una configurazione del cluster privato.

Diagramma che mostra un cluster del servizio Azure Kubernetes 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 privata. Facoltativamente, il servizio Azure Kubernetes può anche creare un FQDN pubblico con un record di indirizzo (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. È possibile creare un cluster privato quando si usa Terraform con Azure, Bicep, modelli arm, interfaccia della riga di comando di Azure, modulo di Azure PowerShell o API REST di Azure per creare il cluster.

È 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, qualsiasi macchina virtuale che accede al server, ad esempio un agente self-hosted di Azure DevOps o uno strumento di esecuzione self-hosted di GitHub Actions, deve 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.

Per un cluster del servizio Azure Kubernetes privato, si disabilita 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 altre informazioni, vedere Creare un cluster privato del servizio Azure Kubernetes.

Opzioni di distribuzione del cluster privato

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

  • authorizedIpRanges (string) specifica gli intervalli IP consentiti in formato CIDR.
  • disableRunCommand (Boolean) specifica se disabilitare o meno il run comando per il cluster.
  • enablePrivateCluster (Boolean) specifica se creare o meno il cluster come privato.
  • enablePrivateClusterPublicFQDN (Boolean) specifica se creare o meno un altro FQDN pubblico per il cluster privato.
  • 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 l'impostazione predefinita è DNS pubblico, quindi il servizio Azure Kubernetes 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 la distribuzione di un cluster del servizio Azure Kubernetes privato:

opzioni di zona DNS privato enablePrivateClusterPublicFQDN: true enablePrivateClusterPublicFQDN: false
Di sistema I nodi agente e qualsiasi altra macchina virtuale nella rete virtuale del cluster del servizio Azure Kubernetes o a qualsiasi rete virtuale connessa alla zona DNS privata, usano il record di zona A DNS privato per risolvere l'indirizzo IP privato dell'endpoint privato.

Qualsiasi altra macchina virtuale usa il nome di dominio completo pubblico del server API.		 I nodi agente e qualsiasi altra macchina virtuale nella rete virtuale del cluster del servizio Azure Kubernetes o a qualsiasi rete virtuale connessa alla zona DNS privata, usano il record di zona A DNS privato per risolvere l'indirizzo IP privato dell'endpoint privato.

Non è disponibile alcun nome di dominio completo del server API pubblico.
Nessuno Tutte le macchine virtuali, inclusi i nodi agente, usano il nome di dominio completo pubblico del server API disponibile tramite un A record in una zona DNS pubblica gestita da Azure. Configurazione errata. Il cluster del servizio Azure Kubernetes privato richiede almeno una zona DNS pubblica o privata per la risoluzione dei nomi del server API.
ID risorsa della zona DNS privato I nodi agente e qualsiasi altra macchina virtuale nella rete virtuale del cluster del servizio Azure Kubernetes o a qualsiasi rete virtuale connessa alla zona DNS privata, usano il record di zona A DNS privato per risolvere l'indirizzo IP privato dell'endpoint privato.

Tutte le altre macchine virtuali usano il nome di dominio completo pubblico del server API.		 I nodi agente e qualsiasi altra macchina virtuale nella rete virtuale del cluster del servizio Azure Kubernetes o a qualsiasi rete virtuale connessa alla zona DNS privata, usano il record di zona A DNS privato per risolvere l'indirizzo IP privato dell'endpoint privato.

Non è disponibile alcun nome di dominio completo del server API pubblico.

Connettività e gestione dei cluster privati

Sono disponibili diverse opzioni per stabilire la connettività di rete al cluster privato.

  • Creare macchine virtuali nella stessa rete virtuale del cluster del servizio Azure Kubernetes.

  • Usare le macchine virtuali in una rete virtuale separata e configurare il peering di rete virtuale con la rete virtuale del cluster del servizio Azure Kubernetes.

  • Usare una connessione Azure ExpressRoute o VPN .

  • Usare il comando az aks command invoke dell'interfaccia della riga di comando di Azure per eseguire kubectl i comandi e helm nel cluster privato senza connettersi direttamente al cluster.

  • Usare una connessione endpoint privato di Azure.

È possibile gestire un cluster del servizio Azure Kubernetes privato usando lo strumento da riga di comando kubectl da una macchina virtuale di gestione nella stessa rete virtuale o in una rete virtuale con peering.

È possibile usare Azure Bastion nella stessa rete virtuale o in una rete virtuale con peering per connettersi a una macchina virtuale di gestione jumpbox. Azure Bastion è una piattaforma distribuita come servizio (PaaS) completamente gestita che consente di connettersi a una macchina virtuale usando il browser e il portale di Azure. Azure Bastion offre connettività SICURA e facile di Remote Desktop Protocol (RDP) o SSH (Secure Shell) tramite Transport Layer Security (TLS) direttamente dalla 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.

È anche possibile usare il comando az aks invoke per eseguire kubectl o helm comandi nel cluster del servizio Azure Kubernetes privato senza dover connettersi a una macchina virtuale jumpbox.

Intervalli IP autorizzati

La seconda opzione per migliorare la sicurezza del cluster e ridurre al minimo gli attacchi al server API consiste nell'usare intervalli IP autorizzati. Gli 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. Per altre informazioni, vedere Proteggere l'accesso al server API usando intervalli di indirizzi IP autorizzati in servizio Azure Kubernetes (servizio Azure Kubernetes).

Il comando dell'interfaccia della riga di comando di Azure seguente az aks update autorizza gli intervalli IP:

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

Considerazioni sulla connettività del servizio Azure Kubernetes

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

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

  • I cluster privati non supportano gli agenti ospitati da Azure DevOps. Prendere in considerazione l'uso di agenti self-hosted.

  • Per consentire Registro Azure Container di usare un cluster del servizio Azure Kubernetes privato, configurare un collegamento privato per il registro contenitori nella rete virtuale del cluster. In alternativa, configurare il peering tra la rete virtuale del Registro Container e la rete virtuale del cluster privato.

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

  • Se si elimina o si modifica l'endpoint privato nella subnet del cliente di un cluster privato, il cluster smetterà di funzionare.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

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

Passaggi successivi

I riferimenti seguenti forniscono collegamenti alla documentazione e agli esempi di automazione per distribuire cluster del servizio Azure Kubernetes con un'API protetta: