Condividi tramite

Proteggere il traffico tra pod usando i criteri di rete nel servizio Azure Kubernetes

  • Articolo

Quando si eseguono applicazioni moderne basate su microservizi in Kubernetes, è spesso consigliabile controllare i componenti che possono comunicare tra loro. Il principio dei privilegi minimi deve essere applicato al modo in cui il traffico può fluire tra i pod in un cluster del servizio Azure Kubernetes. Si supponga di voler bloccare il traffico direttamente alle applicazioni back-end. La funzionalità Criteri di rete in Kubernetes consente di definire regole per il traffico in ingresso e in uscita tra i pod di un cluster.

Questo articolo illustra come installare il motore dei criteri di rete e creare criteri di rete Kubernetes per controllare il flusso del traffico tra i pod nel servizio Azure Kubernetes. I criteri di rete possono essere usati per pod e nodi basati su Linux o Windows nel servizio Azure Kubernetes.

Panoramica dei criteri di rete

Per impostazione predefinita, tutti i pod in un cluster del servizio Azure Kubernetes possono inviare e ricevere traffico senza limitazioni. Per migliorare la sicurezza, è possibile definire regole per il controllo del flusso del traffico. Ad esempio, le applicazioni back-end vengono spesso esposte solo ai servizi front-end richiesti. In alternativa, i componenti del database sono accessibili solo ai livelli applicazione a cui si connettono.

Criteri di rete è una specifica Kubernetes che definisce i criteri di accesso per la comunicazione tra pod. Quando si usano i criteri di rete, si definisce un set ordinato di regole per inviare e ricevere traffico. Si applicano le regole a una raccolta di pod che corrispondono a uno o più selettori di etichetta.

Queste regole dei criteri di rete sono definite come manifesti YAML. I criteri di rete vengono definiti come manifesti YAML e possono essere inclusi come parte di un manifesto più ampio che crea anche una distribuzione o un servizio.

Opzioni dei criteri di rete nel servizio Azure Kubernetes

Azure offre tre motori di criteri di rete per l'applicazione dei criteri di rete:

  • Cilium per i cluster del servizio Azure Kubernetes che usano Azure CNI con tecnologia Cilium.
  • Gestione criteri di rete di Azure.
  • Calico, una soluzione di sicurezza di rete e di rete open source fondata da Tigera.

Cilium è il motore di criteri di rete consigliato. Cilium applica i criteri di rete al traffico usando BPF (Linux Berkeley Packet Filter), che in genere è più efficiente di "IPTables". Per altri dettagli, vedere la documentazione di Azure CNI basata su Cilium.
Per applicare i criteri specificati, Gestione criteri di rete di Azure per Linux usa le tabelle IPTable Linux. Gestione criteri di rete di Azure per Windows usa ACLPolicies del servizio di rete host (HNS). I criteri vengono convertiti in set di coppie IP consentite e non consentite. Queste coppie vengono quindi programmate come regole di filtro IPTable o HNS ACLPolicy.

Differenze tra i motori di Criteri di rete: Cilium, NPM di Azure e Calico

Funzionalità Gestione criteri di rete di Azure Calico Cilium
Piattaforme supportate Linux, Windows Server 2022 (anteprima). Linux, Windows Server 2019 e 2022. Linux.
Opzioni di rete supportate Interfaccia di rete di Azure Container (CNI). Azure CNI (Linux, Windows Server 2019 e 2022) e kubenet (Linux). Azure CNI.
Conformità con le specifiche Kubernetes Tutti i tipi di criteri supportati Sono supportati tutti i tipi di criteri. Sono supportati tutti i tipi di criteri.
Altre funzionalità Nessuno. Modello di criteri esteso, composto da criteri di rete globali, da un set di servizi di rete globale e da un endpoint host. Per altre informazioni sull'uso dell'interfaccia della riga di comando di calicoctl per gestire queste funzionalità estese, vedere i riferimenti utente calicoctl. Nessuno.
Supporto tecnico Supporto fornito dal team di progettazione e supporto tecnico di Azure. Supporto fornito dal team di progettazione e supporto tecnico di Azure. Supporto fornito dal team di progettazione e supporto tecnico di Azure.

Limitazioni di Gestione criteri di rete di Azure

Nota

Con Monitoraggio prestazioni rete di Azure per Linux, il ridimensionamento non è consentito oltre 250 nodi e 20.000 pod. Se si tenta di aumentare il numero di istanze oltre questi limiti, è possibile che si verifichino errori di memoria insufficiente (OOM). Per migliorare la scalabilità e il supporto IPv6 e, se le limitazioni seguenti sono problematiche, è consigliabile usare o eseguire l'aggiornamento ad Azure CNI Powered by Cilium per usare Cilium come motore dei criteri di rete.

Monitoraggio prestazioni rete di Azure non supporta IPv6. In caso contrario, supporta completamente le specifiche dei criteri di rete in Linux.

In Windows Monitoraggio prestazioni rete di Azure non supporta le funzionalità seguenti delle specifiche dei criteri di rete:

  • Porte denominate.
  • Stream Control Transmission Protocol (SCTP).
  • Selettori di etichette o spazi dei nomi negativi. Ad esempio, tutte le etichette tranne debug=true.
  • except blocchi CIDR (Classless Interdomain Routing) (CIDR con eccezioni).

Nota

I log dei pod di Gestione criteri di rete di Azure registrano un errore se vengono creati criteri di rete non supportati.

Modifica/eliminazione di criteri di rete

In alcuni rari casi, è possibile che si verifichi una race condition che potrebbe causare una connettività temporanea e imprevista per le nuove connessioni da e verso i pod su qualsiasi nodo interessato durante la modifica o l'eliminazione di un criterio di rete "sufficientemente grande". Il raggiungimento di questa race condition non influisce mai sulle connessioni attive.

Se questa race condition si verifica per un nodo, il pod NPM di Azure in tale nodo entra in uno stato in cui non può aggiornare le regole di sicurezza, causando una connettività imprevista per le nuove connessioni da e verso i pod nel nodo interessato. Per attenuare il problema, il pod NPM di Azure riavvia automaticamente circa 15 secondi dopo aver immesso questo stato. Mentre Monitoraggio prestazioni rete di Azure viene riavviato nel nodo interessato, elimina tutte le regole di sicurezza, quindi riapplica le regole di sicurezza per tutti i criteri di rete. Anche se tutte le regole di sicurezza vengono riapplicate, esiste una possibilità di connettività temporanea e imprevista per le nuove connessioni da e verso i pod nel nodo interessato.

Per limitare la probabilità di raggiungere questa race condition, è possibile ridurre le dimensioni dei criteri di rete. Questo problema è molto probabile che si verifichi per un criterio di rete con diverse ipBlock sezioni. Un criterio di rete con quattro o meno ipBlock sezioni è meno probabile che si verifichi il problema.

Operazioni preliminari

È necessario che sia installata e configurata l'interfaccia della riga di comando di Azure 2.0.61 o versioni successive. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

Creare un cluster del servizio Azure Kubernetes e abilitare i criteri di rete

Per visualizzare i criteri di rete in azione, si creerà un cluster del servizio Azure Kubernetes che supporta i criteri di rete e quindi si lavorerà sull'aggiunta di criteri.

Per usare Azure Network Policy Manager, è necessario usare il plug-in di Azure CNI. Calico può essere usato con il plug-in Azure CNI o con il plug-in CNI Kubenet.

Lo script di esempio seguente crea un cluster del servizio Azure Kubernetes con identità assegnata dal sistema e abilita i criteri di rete usando Gestione criteri di rete di Azure.

Nota

Calico può essere usato con i parametri --network-plugin azure o --network-plugin kubenet.

Invece di utilizzare un'identità assegnata dal sistema, è possibile utilizzare un'identità assegnata dall'utente. Per altre informazioni, vedere Usare le identità gestite.

Creare un cluster del servizio Azure Kubernetes con Gestione criteri di rete di Azure abilitato - solo Linux

In questa sezione viene creato un cluster con pool di nodi Linux e Azure Network Policy Manager abilitato.

Per iniziare, sostituire i valori per le variabili $RESOURCE_GROUP_NAME e $CLUSTER_NAME.

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$LOCATION=canadaeast

Creare il cluster del servizio Azure Kubernetes e specificare azure per il network-plugin e network-policy.

Per creare un cluster, usare il comando seguente:

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

Creare un cluster del servizio Azure Kubernetes con Gestione criteri di rete di Azure abilitato - Windows Server 2022 (anteprima)

In questa sezione viene creato un cluster con pool di nodi Windows e Gestione criteri di rete di Azure abilitato.

Nota

Gestione criteri di rete di Azure con nodi Windows è disponibile solo in Windows Server 2022.

Installare l'estensione dell'interfaccia della riga di comando di Azure aks-preview

Importante

Le funzionalità di anteprima del servizio Azure Kubernetes sono disponibili in modalità self-service e opzionale. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

Per installare l'estensione aks-preview, eseguire il comando seguente:

az extension add --name aks-preview

Per eseguire l'aggiornamento alla versione più recente dell'estensione rilasciata eseguire il comando seguente:

az extension update --name aks-preview

Registrare il flag di funzionalità WindowsNetworkPolicyPreview

Registrare il flag di funzionalità WindowsNetworkPolicyPreview usando il comando az feature register, come mostrato nell'esempio seguente:

az feature register --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

Sono necessari alcuni minuti per visualizzare lo stato Registered. Verificare lo stato della registrazione usando il comando az feature show:

az feature show --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

Quando lo stato riflette Registrato, aggiornare la registrazione del provider di risorse Microsoft.ContainerService usando il comando az provider register:

az provider register --namespace Microsoft.ContainerService

Creare il cluster del servizio Azure Kubernetes

Sostituire ora i valori per le variabili $RESOURCE_GROUP_NAME, $CLUSTER_NAME e $WINDOWS_USERNAME.

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$WINDOWS_USERNAME=myWindowsUserName
$LOCATION=canadaeast

Creare un nome utente da usare come credenziali di amministratore per i contenitori di Windows Server nel cluster. Il comando seguente richiede un nome utente. Impostarlo su $WINDOWS_USERNAME. Tenere presente che i comandi in questo articolo vengono immessi in una shell Bash.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

Per creare un cluster, usare il comando seguente:

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

La creazione del cluster richiede alcuni minuti. Per impostazione predefinita, il cluster viene creato con solo un pool di nodi Linux. Se si vogliono usare pool di nodi Windows, è possibile aggiungerne uno. Ecco un esempio:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Creare un cluster del servizio Azure Kubernetes con Calico abilitato

Creare il cluster del servizio Azure Kubernetes e specificare --network-plugin azure e --network-policy calico. Specificando --network-policy calico si abilita Calico sia nei pool di nodi Linux che In Windows.

Se si prevede di aggiungere pool di nodi Windows al cluster, includere i parametri windows-admin-username e windows-admin-password che soddisfano i requisiti delle password di Windows Server.

Importante

A questo punto, l'uso dei criteri di rete Calico con nodi Windows è disponibile nei nuovi cluster usando la versione 1.20 di Kubernetes o successiva con Calico 3.17.2 e richiede l'uso della rete di Azure CNI. Anche i nodi Windows nei cluster del servizio Azure Kubernetes con Calico abilitati hanno l'indirizzo IP mobile abilitato per impostazione predefinita.

Per i cluster con solo pool di nodi Linux che eseguono Kubernetes 1.20 con versioni precedenti di Calico, la versione di Calico viene aggiornata automaticamente alla versione 3.17.2.

Creare un nome utente da usare come credenziali di amministratore per i contenitori di Windows Server nel cluster. Il comando seguente richiede un nome utente. Impostarlo su $WINDOWS_USERNAME. Tenere presente che i comandi in questo articolo vengono immessi in una shell Bash.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy calico \
    --generate-ssh-keys

La creazione del cluster richiede alcuni minuti. Per impostazione predefinita, il cluster viene creato con solo un pool di nodi Linux. Se si vogliono usare pool di nodi Windows, è possibile aggiungerne uno. Ad esempio:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

Installare Azure Network Policy Manager o Calico in un cluster esistente

È supportata anche l'installazione di Azure Network Policy Manager o Calico nei cluster del servizio Azure Kubernetes esistenti.

Avviso

Il processo di aggiornamento attiva la ricreazione simultanea di ogni pool di nodi. L'aggiornamento di ogni pool di nodi separatamente non è supportato. Eventuali interruzioni della rete del cluster sono simili a un aggiornamento dell'immagine del nodo o all'aggiornamento della versione di Kubernetes in cui pere ogni nodo in un pool di nodi viene ricreata l'immagine.

Comando di esempio per installare Gestione criteri di rete di Azure:

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy azure

Comando di esempio per installare Calico:

Avviso

Questo avviso si applica all'aggiornamento dei cluster Kubenet con Calico abilitato alla sovrimpressione CNI di Azure con Calico abilitato.

  • Nei cluster Kubenet con Calico abilitato, Calico viene usato sia come CNI che come motore di criteri di rete.
  • Nei cluster CNI di Azure Calico viene usato solo per l'imposizione dei criteri di rete, non come CNI. Ciò può causare un breve ritardo tra l'avvio del pod e il momento in cui Calico consente il traffico in uscita dal pod.

È consigliabile usare Cilium invece di Calico per evitare questo problema. Per altre informazioni su Cilium, vedere Azure CNI con tecnologia Cilium

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy calico

Aggiornare un cluster esistente con NPM di Azure o Calico installato in Azure CNI con tecnologia Cilium

Per aggiornare un cluster esistente in cui è installato il motore di Criteri di rete in Azure CNI con tecnologia Cilium, vedere Aggiornare un cluster esistente ad Azure CNI basato su Cilium

Verificare la configurazione dei criteri di rete

Al termine, configurare kubectl per la connessione al cluster Kubernetes usando il comando az aks get-credentials. Questo comando scarica le credenziali e configura l'interfaccia della riga di comando di Kubernetes per usarle:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

Per iniziare la verifica dei criteri di rete, si crea un'applicazione di esempio e si impostano le regole di traffico.

Creare prima di tutto uno spazio dei nomi denominato demo per eseguire i pod di esempio:

kubectl create namespace demo

Creare ora due pod nel cluster denominato client e server.

Nota

Se si vuole pianificare il client o il server in un nodo specifico, aggiungere il bit seguente prima dell'argomento --command nel comando di creazione del pod kubectl run:

--overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux|windows"}}}'

Creare un pod server. Questo pod viene usato sulla porta TCP 80:

kubectl run server -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --labels="app=server" --port=80 --command -- /agnhost serve-hostname --tcp --http=false --port "80"

Creare un pod client. Il comando seguente esegue Bash nel pod client:

kubectl run -it client -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --command -- bash

Ora, in una finestra separata, eseguire il comando seguente per ottenere l'indirizzo IP del server:

kubectl get pod --output=wide -n demo

L'output sarà simile al seguente:

NAME     READY   STATUS    RESTARTS   AGE   IP            NODE             NOMINATED NODE   READINESS GATES
server   1/1     Running   0          30s   10.224.0.72   akswin22000001   <none>           <none>

Testare la connettività senza criteri di rete

Nella shell del client eseguire il comando seguente per verificare la connettività con il server. Sostituire server-ip usando l'indirizzo IP trovato nell'output dall'esecuzione del comando precedente. Se la connessione ha esito positivo, non è presente alcun output.

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

Testare la connettività con criteri di rete

Per aggiungere criteri di rete, creare un file denominato demo-policy.yaml e incollare il manifesto YAML seguente:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: demo-policy
  namespace: demo
spec:
  podSelector:
    matchLabels:
      app: server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: client
    ports:
    - port: 80
      protocol: TCP

Specificare il nome del manifesto YAML e applicarlo usando applicare kubectl:

kubectl apply –f demo-policy.yaml

Ora, nella shell del client, verificare la connettività con il server eseguendo il comando /agnhost seguente:

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

La connettività con il traffico viene bloccata perché il server è etichettato con app=server, ma il client non è etichettato. Il comando connect precedente restituisce questo output:

TIMEOUT

Eseguire il comando seguente per etichettare client e verificare la connettività con il server. L'output non deve restituire nulla.

kubectl label pod client -n demo app=client

Disinstallare Azure Network Policy Manager o Calico

Requisiti:

  • Interfaccia della riga di comando di Azure versione 2.63 o successiva

Nota

  • Il processo di disinstallazione non rimuove le definizioni delle risorse personalizzate e le risorse personalizzate usate da Calico. Questi CDR e CR hanno nomi che terminano con "projectcalico.org" o "tigera.io". Questi CDR e CR associati possono essere eliminati manualmente dopo che Calico è stato disinstallato correttamente (eliminando i CDR prima di rimuovere Calico interrompe il cluster).
  • L'aggiornamento non rimuoverà alcuna risorsa NetworkPolicy nel cluster, ma dopo la disinstallazione questi criteri non vengono più applicati.

Avviso

Il processo di aggiornamento attiva la ricreazione simultanea di ogni pool di nodi. L'aggiornamento di ogni pool di nodi separatamente non è supportato. Eventuali interruzioni della rete del cluster sono simili a un aggiornamento dell'immagine del nodo o all'aggiornamento della versione di Kubernetes in cui pere ogni nodo in un pool di nodi viene ricreata l'immagine.

Per rimuovere Azure Network Policy Manager o Calico da un cluster, eseguire il comando seguente:

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy none

Pulire le risorse

In questo articolo sono stati creati uno spazio dei nomi e due pod, inoltre sono stati applicati criteri di rete. Per eseguire la pulizia di queste risorse, usare il comando eliminare kubectl e specificare il nome della risorsa:

kubectl delete namespace demo

Passaggi successivi

Per altre informazioni sulle risorse di rete, vedere Concetti relativi alla rete per le applicazioni nel servizio Azure Kubernetes.

Per altre informazioni sui criteri, fare riferimento ai Criteri di rete Kubernetes.