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 i comandi kubectl o helm, deve provenire dall'interno del VPC del cluster o da un 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.

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

  • di rete connessa: connettere la rete al VPC con un gateway di transito AWS o altre opzioni di connettività e quindi usare un computer nella rete connessa. È necessario 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.
  • host bastion Amazon EC2: è possibile avviare un'istanza di Amazon EC2 in una subnet pubblica nel VPC del cluster e quindi accedere tramite SSH in tale istanza per eseguire comandi kubectl. Per altre informazioni, vedere host Bastion Linux in AWS. È necessario assicurarsi che il gruppo di sicurezza del piano di controllo Amazon EKS contenga regole per consentire il traffico in ingresso sulla porta 443 dall'host bastion. Per altre informazioni, vedere Visualizzare i requisiti del gruppo di sicurezza Amazon EKS per i cluster. Quando si configura kubectl per l'host bastion, assicurarsi di usare le credenziali AWS già mappate alla configurazione del controllo degli accessi in base al ruolo del cluster oppure aggiungere il principale IAM che il bastion userà per la configurazione del controllo degli accessi in base al ruolo 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).
  • IDE di AWS Cloud9: AWS Cloud9 è un ambiente di sviluppo integrato basato sul cloud che consente di 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 Creazione di un ambiente in AWS Cloud9. È necessario assicurarsi che il gruppo di sicurezza del piano di controllo Amazon EKS contenga regole per consentire il traffico in ingresso sulla porta 443 dal gruppo di sicurezza dell'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, assicurarsi di usare le credenziali AWS già mappate alla configurazione del controllo degli accessi in base al ruolo del cluster o aggiungere l'entità IAM che l'IDE userà alla configurazione del controllo degli accessi in base al ruolo 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 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 del servizio Azure Kubernetes privato garantisce che il traffico di rete tra il server API e i nodi dell'agente rimanga all'interno della rete virtuale. In un cluster del servizio Azure Kubernetes privato, il piano di controllo o il server API dispone di indirizzi IP interni definiti nel documento RFC1918 - Allocazione indirizzi per internet privato. Usando un cluster privato, è possibile garantire che il traffico di rete tra il server API e i pool di nodi rimanga solo nella rete privata.

In un cluster del servizio Azure Kubernetes privato 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 questo 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.

Quando si effettua il provisioning di un cluster del servizio Azure Kubernetes privato, il servizio Azure Kubernetes crea per impostazione predefinita un FQDN privato con una zona DNS privata e un FQDN pubblico aggiuntivo con un record A corrispondente nel DNS pubblico di Azure. I nodi dell'agente continuano a usare il record A nella zona DNS privata per risolvere l'indirizzo IP privato dell'endpoint privato per la comunicazione con il server API.

Il diagramma seguente illustra una configurazione del cluster del servizio Azure Kubernetes 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

In un cluster del servizio Azure Kubernetes privato l'endpoint del server API non ha un indirizzo IP pubblico. Sono disponibili diverse opzioni per stabilire la connettività di rete al cluster privato:

  1. Creare una macchina virtuale nella stessa rete virtuale del cluster del servizio Azure Kubernetes usando il comando az vm create con il flag --vnet-name.
  2. Usare una macchina virtuale in una rete virtuale separata e configurare peering di reti virtuali con la rete virtuale del cluster del servizio Azure Kubernetes.
  3. Configurare un Azure ExpressRoute o vpn per connettersi alla rete virtuale del cluster.
  4. Creare una connessione endpoint privato di Azure all'interno di un'altra rete virtuale.
  5. Usare un'istanza di Cloud Shell distribuita in una subnet connessa al server API per il cluster.

Usando l'interfaccia della riga di comando di Azure, è possibile usare il comando az servizio Azure Kubernetes invoke per accedere ai cluster privati senza la necessità di configurare una VPN o ExpressRoute. Questo comando consente di richiamare in remoto comandi, ad esempio kubectl e helm, nel cluster privato tramite l'API di Azure, senza dover connettersi direttamente al cluster. Per usare command invoke, è necessario avere le autorizzazioni necessarie configurate per le azioni Microsoft.ContainerService/managedClusters/runcommand/action e Microsoft.ContainerService/managedclusters/commandResults/read.

Nel portale di Azure è possibile usare la funzionalità Run command per eseguire comandi nel cluster privato. Questa funzionalità usa effettivamente la funzionalità command invoke per eseguire comandi nel cluster. Il pod creato dalla funzionalità di Run command fornisce kubectl e strumenti di helm per la gestione del cluster. Supporta inoltre Bash con strumenti come jq, xargs, grepe awk disponibili.

È 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 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.

Integrazione rete virtuale del server API

Un cluster del servizio Azure Kubernetes configurato con integrazione rete virtuale del server API proietta l'endpoint del server API direttamente in una subnet delegata nella rete virtuale in cui viene distribuito il servizio Azure Kubernetes. L'integrazione rete virtuale del server API consente la comunicazione di rete tra il server API e i nodi del cluster senza richiedere un collegamento privato o un tunnel. Il server API è disponibile dietro un indirizzo VIP del servizio di bilanciamento del carico interno nella subnet delegata, che i nodi sono configurati per l'utilizzo. Usando l'integrazione rete virtuale del server API, è possibile garantire 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 di Azure gestita dal servizio Azure Kubernetes. Il cluster o il pool di nodi si trova nella sottoscrizione di Azure. Il server e le macchine virtuali che costituiscono i nodi del cluster possono comunicare tra loro tramite l'INDIRIZZO VIP del server API e gli INDIRIZZI IP pod proiettati nella subnet delegata.

L'integrazione rete virtuale del server API è supportata per i cluster pubblici o privati. È possibile aggiungere o rimuovere l'accesso pubblico dopo il provisioning del cluster. A differenza dei cluster integrati non di rete virtuale, i nodi agente comunicano sempre direttamente con l'indirizzo IP privato dell'IP interno del server API senza usare DNS. Tutto il traffico da nodo a server API viene mantenuto nella rete privata e non è necessario alcun tunnel per la connettività del server API al nodo. I client out-of-cluster che devono comunicare con il server API possono farlo normalmente se l'accesso alla rete pubblica è abilitato. Se l'accesso alla rete pubblica è disabilitato, è necessario seguire la stessa metodologia di configurazione DNS privata dei cluster privati standard . Per altre informazioni, vedere Creare un cluster del servizio Azure Kubernetes con Integrazione rete virtuale del server API.

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

Quando si considera la connettività del servizio Azure Kubernetes, è necessario tenere presenti alcune considerazioni importanti. Ecco alcuni punti chiave da tenere presenti:

  • Un cluster privato del servizio Azure Kubernetes offre sicurezza e isolamento avanzati rispetto agli indirizzi IP autorizzati. Non è tuttavia possibile convertire un cluster del servizio Azure Kubernetes pubblico esistente in un cluster privato. Gli indirizzi IP autorizzati possono invece essere abilitati per qualsiasi cluster del servizio Azure Kubernetes esistente.
  • Gli intervalli IP autorizzati non possono essere applicati a un endpoint del server API privato. Si applicano solo al server API pubblico.
  • I cluster privati non supportano gli agenti ospitati in Azure DevOps. È invece consigliabile usare agenti self-hosted.
  • Affinché Registro Azure Container funzioni con un cluster del servizio Azure Kubernetes privato, è necessario configurare un collegamento privato per il registro contenitori 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 servizio 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 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: