Sichern Sie den Datenverkehr zwischen Pods mit Hilfe von Netzwerkrichtlinien in AKS

Wenn Sie moderne, auf Microservices basierende Anwendungen in Kubernetes ausführen, können Sie steuern, welche Komponenten miteinander kommunizieren können. Auf den Flow des Datenverkehrs zwischen Pods in einem Azure Kubernetes Service -Cluster (AKS) sollte das Prinzip der geringsten Rechte angewendet werden. Nehmen wir an, Sie möchten den Datenverkehr direkt zu Back-End-Anwendungen blockieren. Mit dem Feature Netzwerkrichtlinie in Kubernetes können Sie Regeln für ein- und ausgehenden Datenverkehr zwischen Pods in einem Cluster definieren.

In diesem Artikel wird veranschaulicht, wie Sie das Modul für Netzwerkrichtlinien installieren und Kubernetes-Netzwerkrichtlinien erstellen, um den Datenverkehrsfluss zwischen Pods in AKS zu steuern. Netzwerkrichtlinien können für Linux-basierte oder Windows-basierte Knoten und Pods in AKS verwendet werden.

Übersicht über die Netzwerkrichtlinie

Standardmäßig können alle Pods in einem AKS-Cluster Datenverkehr ohne Einschränkungen senden und empfangen. Zur Verbesserung der Sicherheit können Sie Regeln definieren, die den Datenverkehrsfluss steuern. Back-End-Anwendungen werden häufig nur für erforderliche Front-End-Dienste verfügbar gemacht. Oder Datenbankkomponenten sind nur für die Anwendungsebenen zugänglich, die eine Verbindung damit herstellen.

Netzwerkrichtlinie ist eine Kubernetes-Spezifikation, die Zugriffsrichtlinien für die Kommunikation zwischen Pods definiert. Wenn Sie Netzwerkrichtlinien verwenden, definieren Sie einen geordneten Satz von Regeln zum Senden und Empfangen von Datenverkehr. Sie wenden die Regeln auf eine Sammlung von Pods an, die einer oder mehreren Bezeichnungsauswahlen entsprechen.

Die Regeln der Netzwerkrichtlinien werden als YAML-Manifeste definiert. Netzwerkrichtlinien können Teil eines umfassenderen Manifests sein, mit dem auch eine Bereitstellung oder ein Dienst erstellt wird.

Optionen für Netzwerkrichtlinien in AKS

Azure bietet drei Netzwerkrichtlinienmodule zum Erzwingen von Netzwerkrichtlinien:

• Cilium für AKS-Cluster, die Azure CNI Powered by Cilium verwenden.
• Azure-Netzwerkrichtlinien-Manager.
• Calico: Eine Open-Source-Netzwerk- und Netzwerksicherheitslösung, die von Tigera gegründet wurde.

Cilium ist unser empfohlenes Netzwerkrichtlinienmodul. Cilium erzwingt Netzwerkrichtlinien für den Datenverkehr mit Linux Berkeley Packet Filter (BPF), was im Allgemeinen effizienter als "IPTables" ist. Weitere Details finden Sie in der Dokumentation zu Azure CNI Powered by Cilium.
Um die angegebenen Richtlinien zu erzwingen, verwendet Azure Network Policy Manager für Linux Linux IPTables. Azure Network Policy Manager für Windows verwendet Host Network Service (HNS) ACLPolicies. Aus den Richtlinien werden zulässige und unzulässige IP-Adresspaare gebildet. Diese Paare werden dann als IPTable- oder HNS ACLPolicy-Filterregeln programmiert.

Unterschiede zwischen Netzwerkrichtlinienmodulen: Cilium, Azure NPM und Calico

Einschränkungen des Azure-Netzwerkrichtlinien-Managers

Azure NPM unterstützt IPv6 nicht. Ansonsten unterstützt es die Netzwerkrichtlinienspezifikationen in Linux vollständig.

In Windows unterstützt Azure NPM die folgenden Features der Netzwerkrichtlinienspezifikationen nicht:

• Benannte Ports.
• Stream Control Transmission Protocol (SCTP).
• Negative Übereinstimmungsbezeichnung oder Namespaceselektoren. Beispielsweise werden alle Bezeichnungen mit Ausnahme von debug=true unterstützt.
• Klassenlose domänenübergreifende except-Routingblöcke (CIDR mit Ausnahmen).

Bearbeiten/Löschen von Netzwerkrichtlinien

In seltenen Fällen besteht beim Bearbeiten oder Löschen einer „ausreichend großen“ Netzwerkrichtlinie die Möglichkeit, eine Racebedingung zu erreichen, die zu temporären, unerwarteten Verbindungen für neue Verbindungen zu/von Pods auf betroffenen Knoten führen kann. Das Erreichen dieser Racebedingung wirkt sich niemals auf aktive Verbindungen aus.

Wenn diese Racebedingung für einen Knoten auftritt, wechselt der Azure NPM-Pod auf diesem Knoten in einen Zustand, in dem er keine Sicherheitsregeln aktualisieren kann, was für den betroffenen Knoten zu unerwarteten Verbindungen für neue Verbindungen zu/von Pods führen kann. Um das Problem zu beheben, startet der Azure NPM-Pod nach dem Eintreten in diesen Zustand automatisch nach ca. 15 Sekunden neu. Während Azure NPM auf dem betroffenen Knoten neu gestartet wird, löscht es alle Sicherheitsregeln und wendet dann erneut Sicherheitsregeln für alle Netzwerkrichtlinien an. Während alle Sicherheitsregeln erneut angewendet werden, besteht die Möglichkeit einer temporären, unerwarteten Verbindung für neue Verbindungen zu/von Pods auf dem betroffenen Knoten.

Um die Wahrscheinlichkeit zu begrenzen, dass diese Racebedingung erreicht wird, können Sie die Größe der Netzwerkrichtlinie verringern. Dieses Problem tritt höchstwahrscheinlich für eine Netzwerkrichtlinie mit mehreren ipBlock-Abschnitten auf. Bei einer Netzwerkrichtlinie mit vier oder weniger ipBlock-Abschnitten ist es weniger wahrscheinlich, dass das Problem auftritt.

Voraussetzungen

Azure CLI-Version 2.0.61 oder höher muss installiert und konfiguriert sein. Führen Sie az --version aus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

Erstellen eines AKS-Clusters und Aktivieren der Netzwerkrichtlinie

Um die Netzwerkrichtlinien in Aktion zu sehen, erstellen Sie einen AKS-Cluster, der die Netzwerkrichtlinien unterstützt, und arbeiten dann daran, Richtlinien hinzuzufügen.

Um den Azure-Netzwerkrichtlinien-Manager zu nutzen, müssen Sie das Azure CNI-Plug-In verwenden. Calico kann entweder mit dem Azure CNI-Plug-In oder mit dem Kubenet CNI-Plug-In verwendet werden.

Das folgende Beispielskript erstellt einen AKS-Cluster mit einer dem System zugewiesenen Identität und aktiviert die Netzwerkrichtlinie mithilfe des Azure Network Policy Manager.

Statt einer systemseitig zugewiesenen Identität können Sie auch eine benutzerseitig zugewiesene Identität verwenden. Weitere Informationen finden Sie unter Verwenden verwalteter Identitäten.

Erstellen eines AKS-Clusters mit aktiviertem Azure-Netzwerkrichtlinien-Manager – nur Linux

In diesem Abschnitt erstellen Sie einen Cluster mit Linux-Knotenpools und aktiviertem Azure Network Policy Manager.

Zunächst ersetzen Sie die Werte für die $RESOURCE_GROUP_NAME und $CLUSTER_NAME-Variablen.

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

Erstellen Sie den AKS-Cluster, und geben Sie azure für das network-plugin und die network-policy an.

Um einen Cluster zu erstellen, verwenden Sie den folgenden Befehl:

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

Erstellen eines AKS-Clusters mit aktiviertem Azure-Netzwerkrichtlinien-Manager – Windows Server 2022 (Vorschau)

In diesem Abschnitt erstellen Sie einen Cluster mit Windows-Knotenpools und aktiviertem Azure Network Policy Manager.

Installieren der Azure CLI-Erweiterung „aks-preview“

Führen Sie zum Installieren der aks-preview-Erweiterung den folgenden Befehl aus:

az extension add --name aks-preview

Führen Sie den folgenden Befehl aus, um ein Update auf die neueste veröffentlichte Version der Erweiterung durchzuführen:

az extension update --name aks-preview

Registrieren des Funktionsflags „WindowsNetworkPolicyPreview“

Registrieren Sie das Featureflag WindowsNetworkPolicyPreview mithilfe des Befehls WindowsNetworkPolicyPreview, wie im folgenden Beispiel gezeigt:

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

Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird. Überprüfen Sie den Registrierungsstatus mithilfe des Befehls az feature show:

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

Wenn der Status Registriert lautet, aktualisieren Sie die Registrierung des Microsoft.ContainerService-Ressourcenanbieters, indem Sie den Befehl az provider register verwenden:

az provider register --namespace Microsoft.ContainerService

Erstellen des AKS-Clusters

Jetzt ersetzen Sie die Werte für die $RESOURCE_GROUP_NAME-, $CLUSTER_NAME- und $WINDOWS_USERNAME- Variablen.

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

Erstellen Sie einen Benutzernamen, der für die Administratoranmeldeinformationen für Ihre Windows Server-Container in Ihrem Cluster verwendet wird. Mit dem folgenden Befehl werden Sie zur Eingabe eines Benutzernamens aufgefordert. Legen Sie hierfür $WINDOWS_USERNAME fest. Denken Sie daran, dass die Befehle in diesem Artikel in einer Bash-Shell eingegeben werden.

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

Um einen Cluster zu erstellen, verwenden Sie den folgenden Befehl:

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

Die Erstellung des Clusters dauert einige Minuten. Ihr Cluster wird standardmäßig nur mit einem Linux-Knotenpool erstellt. Wenn Sie Windows-Knotenpools verwenden möchten, können Sie einen hinzufügen. Ein Beispiel:

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

Erstellen eines AKS-Clusters mit aktiviertem Calico

Erstellen Sie den AKS-Cluster und geben Sie --network-plugin azure, und --network-policy calico an. Die Angabe von --network-policy calico aktiviert Calico sowohl auf Linux- als auch auf Windows-Knotenpools.

Wenn Sie vorhaben, Ihrem Cluster Windows-Knotenpools hinzuzufügen, fügen Sie die windows-admin-username- und windows-admin-password-Parameter ein, die den Windows Server-Kennwortanforderungen entsprechen.

Erstellen Sie einen Benutzernamen, der für die Administratoranmeldeinformationen für Ihre Windows Server-Container in Ihrem Cluster verwendet wird. Mit dem folgenden Befehl werden Sie zur Eingabe eines Benutzernamens aufgefordert. Legen Sie hierfür $WINDOWS_USERNAME fest. Denken Sie daran, dass die Befehle in diesem Artikel in einer Bash-Shell eingegeben werden.

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

Die Erstellung des Clusters dauert einige Minuten. Ihr Cluster wird standardmäßig nur mit einem Linux-Knotenpool erstellt. Wenn Sie Windows-Knotenpools verwenden möchten, können Sie einen hinzufügen. Zum Beispiel:

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

Installieren von Azure Network Policy Manager oder Calico in einem vorhandenen Cluster

Das Installieren von Azure Network Policy Manager oder Calico auf vorhandenen AKS-Clustern wird ebenfalls unterstützt.

Beispielbefehl zum Installieren von Azure Network Policy Manager:

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

Beispielbefehl zum Installieren von Calico:

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

Upgrade eines vorhandenen Clusters mit Azure NPM oder Calico auf Azure CNI Powered by Cilium

Informationen zum Upgrade eines vorhandenen Clusters mit installiertem Netzwerkrichtlinienmodul auf Azure CNI Powered by Cilium finden Sie unter Upgrade eines vorhandenen Clusters auf Azure CNI Powered by Cilium

Überprüfen der Einrichtung von Netzwerkrichtlinien

Wenn der Cluster bereit ist, können Sie kubectl mit dem Befehl az aks get-credentials konfigurieren, um die Verbindung mit Ihrem Kubernetes-Cluster herzustellen. Mit diesem Befehl werden die Anmeldeinformationen heruntergeladen, und die Kubernetes-Befehlszeilenschnittstelle wird für deren Verwendung konfiguriert:

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

Um mit der Überprüfung der Netzwerkrichtlinien zu beginnen, erstellen Sie eine Beispielanwendung und legen Verkehrsregeln fest.

Erstellen Sie zunächst einen Namespace namens demo, um die Beispiel-Pods auszuführen:

kubectl create namespace demo

Erstellen Sie nun zwei Pods im Cluster namens client und server.

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

Erstellen eines server-Pods. Dieser Pod dient am TCP-Port 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"

Erstellen eines client-Pods. Der folgende Befehl führt Bash auf dem client-Pod aus:

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

Führen Sie jetzt in einem separaten Fenster den folgenden Befehl aus, um die Server-IP-Adresse abzurufen:

kubectl get pod --output=wide -n demo

Die Ausgabe sollte wie folgt aussehen:

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

Testen der Konnektivität ohne Netzwerkrichtlinie

Führen Sie in der Shell des Clients den folgenden Befehl aus, um die Verbindung mit dem Server zu überprüfen. Ersetzen Sie server-ip mithilfe der IP-Adresse, die in der Ausgabe enthalten ist, indem Sie den vorherigen Befehl ausführen. Wenn die Verbindung erfolgreich ist, gibt es keine Ausgabe.

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

Testen der Konnektivität mit Netzwerkrichtlinie

Zum Hinzufügen von Netzwerkrichtlinien erstellen Sie eine Datei namens demo-policy.yaml und fügen das folgende YAML-Manifest ein:

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

Geben Sie den Namen Ihres YAML-Manifests an und wenden Sie es mithilfe von kubectl apply an:

kubectl apply –f demo-policy.yaml

Überprüfen Sie nun in der Shell des Clients die Verbindung mit dem Server, indem Sie den folgenden /agnhost-Befehl ausführen:

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

Die Verbindung mit dem Datenverkehr wird blockiert, weil der Server mit app=server gekennzeichnet ist, der Client aber nicht. Der obige Verbindungsbefehl liefert diese Ausgabe:

TIMEOUT

Führen Sie den folgenden Befehl aus, um client zu bezeichnen und die Konnektivität mit dem Server zu überprüfen. Die Ausgabe sollte nichts zurückgeben.

kubectl label pod client -n demo app=client

Deinstallieren von Azure Network Policy Manager oder Calico (Vorschau)

Anforderungen:

• Azure CLI, Version 2.63 oder höher.

Um Azure Network Policy Manager oder Calico aus einem Cluster zu entfernen, führen Sie den folgenden Befehl aus:

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

Bereinigen von Ressourcen

In diesem Artikel haben Sie einen Namespace und zwei Pods erstellt und eine Netzwerkrichtlinie angewendet. Verwenden Sie zur Bereinigung dieser Ressourcen den Befehl kubectl delete, und geben Sie den Ressourcennamen an:

kubectl delete namespace demo

Nächste Schritte

Weitere Informationen zu Netzwerkressourcen in Kubernetes finden Sie unter Netzwerkkonzepte für Anwendungen in Azure Kubernetes Service (AKS).

Weitere Informationen zu Richtlinien finden Sie unter Network Policies (Netzwerkrichtlinien).