Zabezpieczanie ruchu między zasobnikami przy użyciu zasad sieciowych w usłudze Azure Kubernetes Service (AKS)

W przypadku uruchamiania nowoczesnych aplikacji opartych na mikrousługach na platformie Kubernetes często chcesz kontrolować, które składniki mogą komunikować się ze sobą. Zasada najmniejszych uprawnień powinna być stosowana do sposobu, w jaki ruch może przepływać między zasobnikami w klastrze Azure Kubernetes Service (AKS). Załóżmy, że prawdopodobnie chcesz zablokować ruch bezpośrednio do aplikacji zaplecza. Funkcja zasady sieci w usłudze Kubernetes umożliwia definiowanie reguł ruchu przychodzącego i wychodzącego między zasobnikami w klastrze.

W tym artykule pokazano, jak zainstalować aparat zasad sieciowych i utworzyć zasady sieciowe Kubernetes w celu kontrolowania przepływu ruchu między zasobnikami w usłudze AKS. Zasady sieciowe mogą być używane w przypadku węzłów i zasobników opartych na systemie Linux lub Windows w usłudze AKS.

Zanim rozpoczniesz

Potrzebujesz interfejsu wiersza polecenia platformy Azure w wersji 2.0.61 lub nowszej, zainstalowanej i skonfigurowanej. Uruchom polecenie az --version, aby dowiedzieć się, jaka wersja jest używana. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

Omówienie zasad sieciowych

Wszystkie zasobniki w klastrze usługi AKS mogą domyślnie wysyłać i odbierać ruch bez ograniczeń. Aby zwiększyć bezpieczeństwo, można zdefiniować reguły kontrolujące przepływ ruchu. Aplikacje zaplecza są często widoczne tylko dla wymaganych usług frontonu, na przykład. Lub składniki bazy danych są dostępne tylko dla warstw aplikacji, które się z nimi łączą.

Zasady sieciowe to specyfikacja platformy Kubernetes, która definiuje zasady dostępu do komunikacji między zasobnikami. Korzystając z zasad sieciowych, należy zdefiniować uporządkowany zestaw reguł do wysyłania i odbierania ruchu oraz stosować je do kolekcji zasobników pasujących do co najmniej jednego selektora etykiet.

Te reguły zasad sieciowych są definiowane jako manifesty YAML. Zasady sieci można uwzględnić w ramach szerszego manifestu, który tworzy również wdrożenie lub usługę.

Opcje zasad sieciowych w usłudze AKS

Platforma Azure oferuje dwa sposoby implementowania zasad sieciowych. Podczas tworzenia klastra usługi AKS należy wybrać opcję Zasady sieciowe. Po utworzeniu klastra opcji zasad nie można już zmienić:

  • Własna implementacja platformy Azure o nazwie Azure Network Policy Manager (NPM).
  • Calico Network Policies, sieć open source i rozwiązanie zabezpieczeń sieci założone przez Tigera.

Usługa Azure NPM dla systemu Linux używa tabel IPTable systemu Linux i usługi Azure NPM dla systemu Windows, używa zasad ACLPolicies usługi sieci hosta (HNS), aby wymusić określone zasady. Zasady są tłumaczone na zestawy dozwolonych i niedozwolonych par adresów IP. Pary te są następnie programowane jako reguły filtra IPTable/HNS ACLPolicy.

Różnice między usługami Azure NPM i Calico Network Policy i ich możliwościami

Możliwość Azure NPM Zasady sieci Calico
Obsługiwane platformy Linux, Windows Server 2022 Linux, Windows Server 2019 i 2022
Obsługiwane opcje sieci Azure CNI Azure CNI (Linux, Windows Server 2019 i 2022) i kubenet (Linux)
Zgodność ze specyfikacją platformy Kubernetes Obsługiwane wszystkie typy zasad Obsługiwane wszystkie typy zasad
Dodatkowe funkcje Brak Rozszerzony model zasad składający się z globalnych zasad sieciowych, globalnego zestawu sieci i punktu końcowego hosta. Aby uzyskać więcej informacji na temat zarządzania tymi rozszerzonymi funkcjami za pomocą interfejsu calicoctl wiersza polecenia, zobacz informacje o użytkownikach calicoctl.
Pomoc techniczna Obsługiwane przez zespół ds. pomoc techniczna platformy Azure i inżynierów Wsparcie społeczności Calico. Aby uzyskać więcej informacji na temat dodatkowej płatnej pomocy technicznej, zobacz Opcje pomocy technicznej programu Project Calico.
Rejestrowanie Dzienniki dostępne za pomocą polecenia kubectl log -n kube-system <network-policy-pod> Aby uzyskać więcej informacji, zobacz Dzienniki składników Calico

Ograniczenia:

Usługa Azure Network Policy Manager (NPM) nie obsługuje protokołu IPv6. W przeciwnym razie usługa Azure NPM w pełni obsługuje specyfikację zasad sieciowych w systemie Linux.

  • W systemie Windows usługa Azure NPM nie obsługuje następujących elementów:
    • nazwane porty
    • Protokół SCTP
    • negatywna etykieta dopasowania lub selektory przestrzeni nazw (np. wszystkie etykiety z wyjątkiem "debug=true")
    • Bloki CIDR "z wyjątkiem" (CIDR z wyjątkami)

Uwaga

  • Dzienniki zasobników usługi Azure NPM będą rejestrować błąd w przypadku utworzenia nieobsługiwanych zasad.

Skali:

Po ustawieniu bieżących limitów w usłudze Azure NPM dla systemu Linux można skalować do 500 węzłów i 40 000 zasobników. Być może zobaczysz, że OOM zabija poza tę skalę. Skontaktuj się z nami w witrynie aks-can-github , jeśli chcesz zwiększyć limit pamięci.

Tworzenie klastra usługi AKS i włączanie zasad sieciowych

Aby wyświetlić zasady sieciowe w działaniu, utwórzmy klaster usługi AKS, który obsługuje zasady sieciowe, a następnie pracujmy nad dodawaniem zasad.

Ważne

Funkcję zasad sieciowych można włączyć tylko po utworzeniu klastra. Nie można włączyć zasad sieciowych w istniejącym klastrze usługi AKS.

Aby użyć usługi Azure NPM, należy użyć wtyczki azure CNI. Zasady sieci Calico mogą być używane z tą samą wtyczką usługi Azure CNI lub wtyczką Kubenet CNI.

Poniższy przykładowy skrypt:

  • Tworzy klaster usługi AKS z tożsamością przypisaną przez system i włącza zasady sieciowe.
    • Jest używana opcja Azure NPM . Aby zamiast tego użyć narzędzia Calico jako opcji Zasady sieciowe, użyj parametru --network-policy calico . Uwaga: Calico może być używany z elementem --network-plugin azure lub --network-plugin kubenet.

Zamiast używać tożsamości przypisanej przez system, można również użyć tożsamości przypisanej przez użytkownika. Aby uzyskać więcej informacji, zobacz Używanie tożsamości zarządzanych.

Tworzenie klastra usługi AKS z włączoną usługą Azure NPM — tylko system Linux

W tej sekcji będziemy pracować nad tworzeniem klastra z pulami węzłów systemu Linux i włączoną usługą Azure NPM.

Aby rozpocząć, należy zastąpić wartości zmiennych $RESOURCE_GROUP_NAME i $CLUSTER_NAME .

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

Utwórz klaster usługi AKS i określ platformę Azure dla elementu network-plugin i network-policy.

Użyj następującego polecenia, aby utworzyć klaster:

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

Tworzenie klastra usługi AKS z włączoną usługą Azure NPM — Windows Server 2022 (wersja zapoznawcza)

W tej sekcji będziemy pracować nad tworzeniem klastra z pulami węzłów systemu Windows i włączoną usługą Azure NPM.

Przed utworzeniem klastra wykonaj następujące polecenia:

 az extension add --name aks-preview
 az extension update --name aks-preview
 az feature register --namespace Microsoft.ContainerService --name WindowsNetworkPolicyPreview
 az provider register -n Microsoft.ContainerService

Uwaga

Obecnie usługa Azure NPM z węzłami systemu Windows jest dostępna tylko w systemie Windows Server 2022

Teraz należy zastąpić wartości zmiennych $RESOURCE_GROUP_NAME, $CLUSTER_NAME i $WINDOWS_USERNAME .

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

Utwórz nazwę użytkownika do użycia jako poświadczenia administratora dla kontenerów systemu Windows Server w klastrze. Następujące polecenie wyświetla monit o nazwę użytkownika. Ustaw ją na $WINDOWS_USERNAME(pamiętaj, że polecenia w tym artykule są wprowadzane w powłoce powłoki BASH).

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

Użyj następującego polecenia, aby utworzyć klaster:

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

Utworzenie klastra trwa kilka minut. Domyślnie klaster jest tworzony tylko z pulą węzłów systemu Linux. Jeśli chcesz użyć pul węzłów systemu Windows, możesz je dodać. Przykład:

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

Ważne

Funkcje usługi AKS w wersji zapoznawczej są dostępne na zasadzie samoobsługi. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi AKS są częściowo objęte pomocą techniczną w oparciu o najlepsze wysiłki. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego. Aby uzyskać więcej informacji, zobacz następujące artykuły pomocy technicznej:

Tworzenie klastra usługi AKS dla zasad sieci Calico

Utwórz klaster usługi AKS i określ platformę Azure dla wtyczki sieciowej oraz calico dla zasad sieciowych. Użycie calico jako zasad sieciowych umożliwia sieci Calico w pulach węzłów systemu Linux i Windows.

Jeśli planujesz dodanie pul węzłów systemu Windows do klastra, uwzględnij windows-admin-username parametry i windows-admin-password spełniające wymagania dotyczące hasła systemu Windows Server.

Ważne

Obecnie korzystanie z zasad sieci Calico z węzłami systemu Windows jest dostępne w nowych klastrach przy użyciu platformy Kubernetes w wersji 1.20 lub nowszej z systemem Calico 3.17.2 i wymaga użycia sieci azure CNI. Węzły systemu Windows w klastrach AKS z włączoną obsługą calico również mają domyślnie włączony bezpośredni zwrot serwera (DSR ).

W przypadku klastrów z tylko pulami węzłów systemu Linux z uruchomioną platformą Kubernetes 1.20 z wcześniejszymi wersjami Calico zostanie automatycznie uaktualniona do wersji 3.17.2.

Utwórz nazwę użytkownika, która będzie używana jako poświadczenia administratora dla kontenerów systemu Windows Server w klastrze. Następujące polecenie wyświetla monit o podanie nazwy użytkownika. Ustaw ją na $WINDOWS_USERNAME(pamiętaj, że polecenia w tym artykule są wprowadzane w powłoce 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

Utworzenie klastra trwa kilka minut. Domyślnie klaster jest tworzony tylko z pulą węzłów systemu Linux. Jeśli chcesz użyć pul węzłów systemu Windows, możesz je dodać. Przykład:

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

Weryfikowanie konfiguracji zasad sieciowych

Gdy klaster jest gotowy, skonfiguruj go kubectl , aby nawiązać połączenie z klastrem Kubernetes przy użyciu polecenia az aks get-credentials . To polecenie pobiera poświadczenia i konfiguruje interfejs wiersza polecenia platformy Kubernetes do ich używania:

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

Aby rozpocząć weryfikację zasad sieciowych, utworzymy przykładową aplikację i ustawimy reguły ruchu.

Najpierw utwórzmy przestrzeń nazw o nazwie demo , aby uruchomić przykładowe zasobniki:

kubectl create namespace demo

Teraz utworzymy dwa zasobniki w klastrze o nazwie klient i serwer.

Uwaga

Jeśli chcesz zaplanować klienta lub serwer w określonym węźle, dodaj następujący bit przed argumentem --command w poleceniu kubectl run tworzenia zasobnika:

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

Utwórz zasobnik serwera . Ten zasobnik będzie obsługiwał port 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"

Utwórz zasobnik klienta . Poniższe polecenie spowoduje uruchomienie powłoki bash na zasobniku klienta:

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

Teraz w osobnym oknie uruchom następujące polecenie, aby uzyskać adres IP serwera:

kubectl get pod --output=wide

Dane wyjściowe powinny wyglądać następująco:

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

Testowanie łączności bez zasad sieciowych

W powłoce klienta zweryfikuj łączność z serwerem, wykonując następujące polecenie. Zastąp ciąg server-ip przez adres IP znaleziony w danych wyjściowych wykonywania poprzedniego polecenia. Jeśli połączenie zakończy się pomyślnie, nie będzie żadnych danych wyjściowych:

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

Testowanie łączności za pomocą zasad sieciowych

Utwórz plik o nazwie demo-policy.yaml i wklej następujący manifest YAML, aby dodać zasady sieciowe:

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

Określ nazwę manifestu YAML i zastosuj go przy użyciu narzędzia kubectl apply:

kubectl apply –f demo-policy.yaml

Teraz w powłoce klienta sprawdź łączność z serwerem, wykonując następujące /agnhost polecenie:

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

Łączność z ruchem zostanie zablokowana, ponieważ serwer jest oznaczony etykietą app=server, ale klient nie jest oznaczony etykietą. Powyższe polecenie connect zwróci następujące dane wyjściowe:

TIMEOUT

Uruchom następujące polecenie, aby oznaczyć klienta etykietą i zweryfikować łączność z serwerem (dane wyjściowe nie powinny zwracać niczego).

kubectl label pod client -n demo app=client

Czyszczenie zasobów

W tym artykule utworzyliśmy przestrzeń nazw i dwa zasobniki i zastosowaliśmy zasady sieciowe. Aby wyczyścić te zasoby, użyj polecenia kubectl delete i określ nazwę zasobu:

kubectl delete namespace demo

Następne kroki

Aby uzyskać więcej informacji na temat zasobów sieciowych, zobacz Pojęcia dotyczące sieci dla aplikacji w usłudze Azure Kubernetes Service (AKS).

Aby dowiedzieć się więcej na temat zasad, zobacz Zasady sieciowe platformy Kubernetes.