Share via

Verkeer tussen pods beveiligen met behulp van netwerkbeleid in AKS

  • Artikel

Wanneer u moderne, op microservices gebaseerde toepassingen uitvoert in Kubernetes, wilt u vaak bepalen welke onderdelen met elkaar kunnen communiceren. Het principe van minimale bevoegdheden moet worden toegepast op de wijze waarop verkeer tussen pods in een AKS-cluster (Azure Kubernetes Service) kan stromen. Stel dat u verkeer rechtstreeks naar back-endtoepassingen wilt blokkeren. Met de functie netwerkbeleid in Kubernetes kunt u regels definiëren voor inkomend en uitgaand verkeer tussen pods in een cluster.

In dit artikel leest u hoe u de netwerkbeleidsengine installeert en Kubernetes-netwerkbeleid maakt om de verkeersstroom tussen pods in AKS te beheren. Netwerkbeleid kan worden gebruikt voor linux- of Windows-knooppunten en -pods in AKS.

Overzicht van netwerkbeleid

Alle pods in een AKS-cluster kunnen standaard verkeer verzenden en ontvangen zonder beperkingen. Om de beveiliging te verbeteren, kunt u regels definiëren waarmee de verkeersstroom wordt bepaald. Back-endtoepassingen worden vaak alleen blootgesteld aan vereiste front-endservices, bijvoorbeeld. Of databaseonderdelen zijn alleen toegankelijk voor de toepassingslagen die er verbinding mee maken.

Netwerkbeleid is een Kubernetes-specificatie die toegangsbeleid definieert voor communicatie tussen pods. Wanneer u netwerkbeleid gebruikt, definieert u een geordende set regels voor het verzenden en ontvangen van verkeer. U past de regels toe op een verzameling pods die overeenkomen met een of meer labelkiezers.

De netwerkbeleidsregels worden gedefinieerd als YAML-manifesten. Netwerkbeleid kan worden opgenomen als onderdeel van een breder manifest dat ook een implementatie of service maakt.

Netwerkbeleidsopties in AKS

Azure biedt drie netwerkbeleidsengines voor het afdwingen van netwerkbeleid:

  • Cilium voor AKS-clusters die gebruikmaken van Azure CNI Powered by Cilium.
  • Azure Network Policy Manager.
  • Calico, een opensource-netwerk- en netwerkbeveiligingsoplossing die is opgericht door Tigera.

Cilium is onze aanbevolen netwerkbeleidsengine. Cilium dwingt netwerkbeleid af op het verkeer met behulp van Linux Berkeley Packet Filter (BPF), wat over het algemeen efficiënter is dan 'IPTables'. Zie de documentatie over Azure CNI Powered by Cilium voor meer informatie.
Voor het afdwingen van het opgegeven beleid gebruikt Azure Network Policy Manager voor Linux IPTables. Azure Network Policy Manager voor Windows maakt gebruik van HNS-ACLPolicies (Host Network Service). Beleidsregels worden omgezet in sets met toegestane en niet-toegestane IP-paren. Deze paren worden vervolgens geprogrammeerd als IPTable of HNS ACLPolicy filterregels.

Verschillen tussen netwerkbeleidsengines: Cilium, Azure NPM en Calico

Mogelijkheid Azure Network Policy Manager Calico Cilium
Ondersteunde platforms Linux, Windows Server 2022 (preview). Linux, Windows Server 2019 en 2022. Linux.
Ondersteunde netwerkopties Azure Container Networking Interface (CNI). Azure CNI (Linux, Windows Server 2019 en 2022) en kubenet (Linux). Azure CNI.
Naleving van Kubernetes-specificatie Alle beleidstypen die worden ondersteund Alle beleidstypen worden ondersteund. Alle beleidstypen worden ondersteund.
Andere functies Geen. Uitgebreid beleidsmodel dat bestaat uit Global Network Policy, Global Network Set en Host Endpoint. Zie calicoctl-gebruikersreferenties voor meer informatie over het gebruik van de calicoctl CLI om deze uitgebreide functies te beheren. Geen.
Ondersteuning Ondersteund door het ondersteunings- en engineeringteam van Azure. Ondersteund door het ondersteunings- en engineeringteam van Azure. Ondersteund door het ondersteunings- en engineeringteam van Azure.

Beperkingen van Azure Network Policy Manager

Notitie

Met Azure NPM voor Linux kunnen we niet meer schalen dan 250 knooppunten en 20.000 pods. Als u probeert te schalen buiten deze limieten, kunnen er OOM-fouten (Onvoldoende geheugen) optreden. Voor betere schaalbaarheid en IPv6-ondersteuning en als de volgende beperkingen van belang zijn, raden we u aan om azure CNI Powered by Cilium te gebruiken als netwerkbeleidsengine.

Azure NPM biedt geen ondersteuning voor IPv6. Anders worden de netwerkbeleidsspecificaties in Linux volledig ondersteund.

In Windows biedt Azure NPM geen ondersteuning voor de volgende functies van de netwerkbeleidsspecificaties:

  • Benoemde poorten.
  • Stream Control Transmission Protocol (SCTP).
  • Negatieve overeenkomst label of naamruimteselectors. Bijvoorbeeld alle labels behalve debug=true.
  • except ciDR-blokken (classless interdomain routing) (CIDR met uitzonderingen).

Notitie

Azure Network Policy Manager-podlogboeken registreren een fout als er een niet-ondersteund netwerkbeleid wordt gemaakt.

Netwerkbeleid bewerken/verwijderen

In sommige zeldzame gevallen is er een kans op een racevoorwaarde die kan leiden tot tijdelijke, onverwachte connectiviteit voor nieuwe verbindingen met/van pods op getroffen knooppunten bij het bewerken of verwijderen van een 'groot genoeg' netwerkbeleid. Het bereiken van deze racevoorwaarde heeft nooit invloed op actieve verbindingen.

Als deze racevoorwaarde optreedt voor een knooppunt, voert de Azure NPM-pod op dat knooppunt een status in waarin de beveiligingsregels niet kunnen worden bijgewerkt, wat kan leiden tot onverwachte connectiviteit voor nieuwe verbindingen met/van pods op het betrokken knooppunt. Om het probleem te verhelpen, wordt de Azure NPM-pod automatisch ~15 seconden na het invoeren van deze status opnieuw opgestart. Terwijl Azure NPM opnieuw wordt opgestart op het betrokken knooppunt, worden alle beveiligingsregels verwijderd en worden vervolgens beveiligingsregels voor alle netwerkbeleidsregels opnieuw toegepast. Hoewel alle beveiligingsregels opnieuw worden toegepast, is er een kans op tijdelijke, onverwachte connectiviteit voor nieuwe verbindingen met/van pods op het betrokken knooppunt.

Als u de kans wilt beperken dat deze racevoorwaarde wordt bereikt, kunt u de grootte van het netwerkbeleid verkleinen. Dit probleem treedt waarschijnlijk op voor een netwerkbeleid met verschillende ipBlock secties. Een netwerkbeleid met vier of minder ipBlock secties heeft minder kans op het probleem.

Voordat u begint

U moet Azure CLI versie 2.0.61 of hoger hebben geïnstalleerd en geconfigureerd. Voer az --version uit om de versie te bekijken. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.

Een AKS-cluster maken en netwerkbeleid inschakelen

Als u netwerkbeleid in actie wilt zien, maakt u een AKS-cluster dat netwerkbeleid ondersteunt en werkt u vervolgens aan het toevoegen van beleid.

Als u Azure Network Policy Manager wilt gebruiken, moet u de Azure CNI-invoegtoepassing gebruiken. Calico kan worden gebruikt met de Azure CNI-invoegtoepassing of met de Kubenet CNI-invoegtoepassing.

Met het volgende voorbeeldscript maakt u een AKS-cluster met door het systeem toegewezen identiteit en schakelt u netwerkbeleid in met behulp van Azure Network Policy Manager.

Notitie

Calico kan worden gebruikt met de --network-plugin azure of --network-plugin kubenet parameters.

In plaats van een door het systeem toegewezen identiteit te gebruiken, kunt u ook een door de gebruiker toegewezen identiteit gebruiken. Zie Beheerde identiteiten gebruiken voor meer informatie.

Een AKS-cluster maken waarvoor Azure Network Policy Manager is ingeschakeld - alleen Linux

In deze sectie maakt u een cluster waarvoor Linux-knooppuntgroepen zijn ingeschakeld en Azure Network Policy Manager is ingeschakeld.

Om te beginnen vervangt u de waarden voor de $RESOURCE_GROUP_NAME en $CLUSTER_NAME variabelen.

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

Maak het AKS-cluster en geef azure het op voor de network-plugin en network-policy.

Gebruik de volgende opdracht om een cluster te maken:

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

Een AKS-cluster maken waarvoor Azure Network Policy Manager is ingeschakeld - Windows Server 2022 (preview)

In deze sectie maakt u een cluster waarvoor Windows-knooppuntgroepen zijn ingeschakeld en Azure Network Policy Manager is ingeschakeld.

Notitie

Azure Network Policy Manager met Windows-knooppunten is alleen beschikbaar op Windows Server 2022.

De Azure CLI-extensie aks-preview installeren

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals is' en 'als beschikbaar' en ze worden uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning op basis van best effort. Daarom zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

Voer de volgende opdracht uit om de aks-preview extensie te installeren:

az extension add --name aks-preview

Voer de volgende opdracht uit om bij te werken naar de nieuwste versie van de extensie die is uitgebracht:

az extension update --name aks-preview

De functievlag WindowsNetworkPolicyPreview registreren

Registreer de WindowsNetworkPolicyPreview functievlag met behulp van de opdracht az feature register , zoals wordt weergegeven in het volgende voorbeeld:

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

Het duurt enkele minuten voordat de status Geregistreerd wordt weergegeven. Controleer de registratiestatus met behulp van de opdracht az feature show :

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

Wanneer de status Geregistreerd is, vernieuwt u de registratie van de Microsoft.ContainerService resourceprovider met behulp van de opdracht az provider register:

az provider register --namespace Microsoft.ContainerService

Het AKS-cluster maken

Nu vervangt u de waarden voor de $RESOURCE_GROUP_NAME, $CLUSTER_NAMEen $WINDOWS_USERNAME variabelen.

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

Maak een gebruikersnaam voor gebruik als beheerdersreferenties voor uw Windows Server-containers in uw cluster. Met de volgende opdracht wordt u om een gebruikersnaam gevraagd. Stel deze in op $WINDOWS_USERNAME. Houd er rekening mee dat de opdrachten in dit artikel worden ingevoerd in een Bash-shell.

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

Gebruik de volgende opdracht om een cluster te maken:

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

Het duurt een paar minuten om het cluster te maken. Uw cluster wordt standaard gemaakt met alleen een Linux-knooppuntgroep. Als u Windows-knooppuntgroepen wilt gebruiken, kunt u er een toevoegen. Hier volgt een voorbeeld:

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

Een AKS-cluster maken waarvoor Calico is ingeschakeld

Maak het AKS-cluster en geef --network-plugin azure, en --network-policy calico. --network-policy calico Door op te geven kunt u Calico inschakelen voor zowel Linux- als Windows-knooppuntgroepen.

Als u van plan bent Windows-knooppuntgroepen toe te voegen aan uw cluster, neemt u de windows-admin-username en windows-admin-password parameters op die voldoen aan de wachtwoordvereisten voor Windows Server.

Belangrijk

Op dit moment is het gebruik van Calico-netwerkbeleid met Windows-knooppunten beschikbaar op nieuwe clusters met behulp van Kubernetes versie 1.20 of hoger met Calico 3.17.2 en moet u Azure CNI-netwerken gebruiken. Windows-knooppunten op AKS-clusters waarvoor Calico is ingeschakeld, hebben ook standaard Zwevend IP-adres ingeschakeld.

Voor clusters met alleen Linux-knooppuntgroepen met Kubernetes 1.20 met eerdere versies van Calico wordt de Calico-versie automatisch bijgewerkt naar 3.17.2.

Maak een gebruikersnaam voor gebruik als beheerdersreferenties voor uw Windows Server-containers in uw cluster. Met de volgende opdracht wordt u om een gebruikersnaam gevraagd. Stel deze in op $WINDOWS_USERNAME. Houd er rekening mee dat de opdrachten in dit artikel worden ingevoerd in een Bash-shell.

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

Het duurt een paar minuten om het cluster te maken. Uw cluster wordt standaard gemaakt met alleen een Linux-knooppuntgroep. Als u Windows-knooppuntgroepen wilt gebruiken, kunt u er een toevoegen. Voorbeeld:

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

Azure Network Policy Manager of Calico installeren in een bestaand cluster

Het installeren van Azure Network Policy Manager of Calico op bestaande AKS-clusters wordt ook ondersteund.

Waarschuwing

Tijdens het upgradeproces wordt elke knooppuntgroep geactiveerd om tegelijkertijd opnieuw te worden geinstallatiekopieën. Het afzonderlijk bijwerken van elke knooppuntgroep wordt niet ondersteund. Eventuele onderbrekingen in clusternetwerken zijn vergelijkbaar met een upgrade van de installatiekopie van een knooppunt of een upgrade van de Kubernetes-versie waarbij elk knooppunt in een knooppuntgroep opnieuw wordt geinstallatiekopie gemaakt.

Voorbeeldopdracht voor het installeren van Azure Network Policy Manager:

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

Voorbeeldopdracht voor het installeren van Calico:

Waarschuwing

Deze waarschuwing geldt voor het upgraden van Kubenet-clusters waarvoor Calico is ingeschakeld voor Azure CNI-overlay met Calico ingeschakeld.

  • In Kubenet-clusters waarvoor Calico is ingeschakeld, wordt Calico gebruikt als een CNI- en netwerkbeleidsengine.
  • In Azure CNI-clusters wordt Calico alleen gebruikt voor het afdwingen van netwerkbeleid, niet als een CNI. Dit kan een korte vertraging veroorzaken tussen wanneer de pod wordt gestart en wanneer Calico uitgaand verkeer van de pod toestaat.

Het wordt aanbevolen om Cilium te gebruiken in plaats van Calico om dit probleem te voorkomen. Meer informatie over Cilium op Azure CNI Powered by Cilium

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

Een bestaand cluster upgraden waarop Azure NPM of Calico is geïnstalleerd naar Azure CNI Powered by Cilium

Zie Een bestaand cluster upgraden naar Azure CNI Powered by Cilium als u een bestaand cluster wilt upgraden naar Azure CNI Powered by Cilium

Configuratie van netwerkbeleid controleren

Wanneer het cluster klaar is, configureert u kubectl om verbinding te maken met uw Kubernetes-cluster met behulp van de opdracht az aks get-credentials . Met deze opdracht downloadt u referenties en configureert u de Kubernetes CLI om deze te gebruiken:

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

Als u wilt beginnen met de verificatie van netwerkbeleid, maakt u een voorbeeldtoepassing en stelt u verkeersregels in.

Maak eerst een naamruimte die wordt aangeroepen demo om de voorbeeldpods uit te voeren:

kubectl create namespace demo

Maak nu twee pods in het cluster met de naam client en server.

Notitie

Als u de client of server op een bepaald knooppunt wilt plannen, voegt u de volgende bit toe vóór het --command argument in de kubectl-opdracht voor het maken van de pod:

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

Maak een server pod. Deze pod dient op TCP-poort 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"

Maak een client pod. Met de volgende opdracht wordt Bash uitgevoerd op de client pod:

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

Voer nu in een afzonderlijk venster de volgende opdracht uit om het IP-adres van de server op te halen:

kubectl get pod --output=wide -n demo

De uitvoer moet er als volgt uitzien:

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

Connectiviteit testen zonder netwerkbeleid

Voer in de shell van de client de volgende opdracht uit om de verbinding met de server te controleren. Vervang server-ip het IP-adres in de uitvoer van het uitvoeren van de vorige opdracht. Als de verbinding is geslaagd, is er geen uitvoer.

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

Connectiviteit testen met netwerkbeleid

Als u netwerkbeleidsregels wilt toevoegen, maakt u een bestand met de naam demo-policy.yaml en plakt u het volgende YAML-manifest:

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

Geef de naam van uw YAML-manifest op en pas dit toe met behulp van kubectl apply:

kubectl apply –f demo-policy.yaml

Controleer nu in de shell van de client de verbinding met de server door de volgende /agnhost opdracht uit te voeren:

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

Connectiviteit met verkeer wordt geblokkeerd omdat de server is gelabeld met app=server, maar de client niet is gelabeld. De voorgaande connect-opdracht levert deze uitvoer op:

TIMEOUT

Voer de volgende opdracht uit om de client verbinding met de server te labelen en te controleren. De uitvoer moet niets retourneren.

kubectl label pod client -n demo app=client

Azure Network Policy Manager of Calico verwijderen

Vereisten:

  • Azure CLI versie 2.63 of hoger

Notitie

  • Tijdens het verwijderingsproces worden geen aangepaste resourcedefinities (CRD's) en aangepaste resources (CR's) verwijderd die door Calico worden gebruikt. Deze CRD's en CA's hebben allemaal namen die eindigen op 'projectcalico.org' of 'tigera.io'. Deze CRD's en bijbehorende CR's kunnen handmatig worden verwijderd nadat Calico is verwijderd (verwijderen van de CRD's voordat calico het cluster verwijdert).
  • Met de upgrade worden geen NetworkPolicy-resources in het cluster verwijderd, maar na het verwijderen van dit beleid worden deze beleidsregels niet meer afgedwongen.

Waarschuwing

Tijdens het upgradeproces wordt elke knooppuntgroep geactiveerd om tegelijkertijd opnieuw te worden geinstallatiekopieën. Het afzonderlijk bijwerken van elke knooppuntgroep wordt niet ondersteund. Eventuele onderbrekingen in clusternetwerken zijn vergelijkbaar met een upgrade van de installatiekopie van een knooppunt of een upgrade van de Kubernetes-versie waarbij elk knooppunt in een knooppuntgroep opnieuw wordt geinstallatiekopie gemaakt.

Voer de volgende opdracht uit om Azure Network Policy Manager of Calico uit een cluster te verwijderen:

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

Resources opschonen

In dit artikel hebt u een naamruimte en twee pods gemaakt en een netwerkbeleid toegepast. Als u deze resources wilt opschonen, gebruikt u de opdracht kubectl delete en geeft u de resourcenaam op:

kubectl delete namespace demo

Volgende stappen

Zie Netwerkconcepten voor toepassingen in Azure Kubernetes Service (AKS) voor meer informatie over netwerkresources.

Zie Kubernetes-netwerkbeleid voor meer informatie over beleidsregels.