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 nodi e pod 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.

I criteri di rete sono 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.

Le 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 rete e sicurezza 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 powered by Cilium (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 IPTable regole di filtro 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 Supportato dal team di supporto tecnico e tecnico di Azure. Supportato dal team di supporto tecnico e tecnico di Azure. Supportato dal team di supporto tecnico e tecnico di Azure.

Limiti

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

In Windows Gestione criteri di rete di Azure non supporta:

  • Porte denominate.
  • Stream Control Transmission Protocol (SCTP).
  • Etichette di corrispondenza negative o selettori dello spazio dei nomi (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 viene creato un criterio non supportato.

Ridimensiona

Con Gestione criteri di rete di Azure per Linux, non è possibile ridimensionare oltre 250 nodi e 20.000 pod. Se si tenta di aumentare il numero di istanze oltre questi limiti, potrebbero verificarsi errori "Memoria insufficiente" (OOM). Per aumentare il limite di memoria, creare un ticket di supporto.

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, creare un cluster del servizio Azure Kubernetes che supporta i criteri di rete e quindi lavorare sull'aggiunta di criteri.

Per usare Azure Network Policy Manager, è necessario usare il plug-in 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 --network-plugin azure parametri o --network-plugin kubenet .

Anziché usare un'identità assegnata dal sistema, è anche possibile usare 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 $RESOURCE_GROUP_NAME variabili e $CLUSTER_NAME .

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

Creare il cluster del servizio Azure Kubernetes e specificare azure per 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

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 di consenso esplicito. 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 Registered, aggiornare la registrazione del Microsoft.ContainerService provider di risorse 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 $RESOURCE_GROUP_NAMEvariabili , $CLUSTER_NAMEe $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

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 azuree --network-policy calico. Specificando --network-policy calico abilita Calico sia nei pool di nodi Linux che In Windows.

Se si prevede di aggiungere pool di nodi Windows al cluster, includere i windows-admin-username parametri 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 Kubernetes versione 1.20 o successiva con Calico 3.17.2 e richiede l'uso della rete CNI di Azure. 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 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

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. Altre informazioni su Cilium in Azure CNI Powered by 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, creare un'applicazione di esempio e impostare 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 nel comando kubectl run per la creazione del --command pod:

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

Creare un server pod. 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 client pod. Il comando seguente esegue Bash nel client pod:

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 i 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 kubectl apply:

kubectl apply –f demo-policy.yaml

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

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

Connessione ivity with traffic is blocked because the server is labeled with app=server, but the client is t labeled. Il comando connect precedente restituisce questo output:

TIMEOUT

Eseguire il comando seguente per etichettare e verificare la client 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 (anteprima)

Requisiti:

  • aks-preview estensione dell'interfaccia della riga di comando di Azure versione 0.5.166 o successiva. Vedere Installare l'estensione dell'interfaccia della riga di comando di Azure aks-preview.
  • Interfaccia della riga di comando di Azure versione 2.54 o successiva
  • API REST del servizio Azure Kubernetes versione 2023-08-02-preview 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 e sono stati applicati criteri di rete. Per pulire queste risorse, usare il comando kubectl delete 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.