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 najniższych uprawnień powinna być stosowana do sposobu przepływu ruchu między zasobnikami w klastrze usługi Azure Kubernetes Service (AKS). Załóżmy, że prawdopodobnie chcesz zablokować ruch bezpośrednio do aplikacji zaplecza. Funkcja zasady sieci w rozwiązaniu Kubernetes umożliwia definiowanie reguł dla ruchu przychodzącego i wychodzącego między zasobnikami w klastrze.

W tym artykule przedstawiono sposób instalowania aparatu zasad sieciowych i tworzenia zasad sieci kubernetes w celu kontrolowania przepływu ruchu między zasobnikami w usłudze AKS. Zasady sieciowe mogą być używane dla węzłów i zasobników opartych na systemie Linux lub Windows w usłudze AKS.

Zanim rozpoczniesz

Potrzebny jest interfejs wiersza polecenia platformy Azure w wersji 2.0.61 lub nowszej, zainstalowany i skonfigurowany. 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.
  • Calico Network Policies, sieć typu open source i rozwiązanie zabezpieczeń sieci założone przez Tigera.

Menedżer zasad sieciowych platformy Azure dla systemu Linux używa tabel IPTable systemu Linux i Menedżera zasad sieciowych platformy Azure dla systemu Windows, używa zasad ACL Usługi sieciowej hosta (HNS) w celu wymuszenia określonych zasad. 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ługą Azure Network Policy Manager i zasadami sieci calico oraz ich możliwościami

Możliwość Menedżer zasad sieciowych platformy Azure Zasady sieci Calico
Obsługiwane platformy Linux, Windows Server 2022 Linux, Windows Server 2019 i 2022
Obsługiwane opcje sieciowe 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 funkcjami rozszerzonymi przy użyciu 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 Pomoc techniczna 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 nie obsługuje protokołu IPv6. W przeciwnym razie usługa Azure Network Policy Manager w pełni obsługuje specyfikację zasad sieciowych w systemie Linux.

  • W systemie Windows program Azure Network Policy Manager 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 zasobnika usługi Azure Network Policy Manager rejestrują błąd w przypadku utworzenia nieobsługiwanych zasad.

Skaluj

W usłudze Azure Network Policy Manager dla systemu Linux nie zalecamy skalowania poza 250 węzłami i 20 000 zasobników. Jeśli próbujesz skalować poza te limity, może wystąpić błąd Braku pamięci (OOM). Aby zwiększyć limit pamięci, utwórz bilet pomocy technicznej.

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 Network Policy Manager, należy użyć wtyczki azure CNI. Zasady sieci Calico mogą być używane z tą samą wtyczką 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 przy użyciu menedżera usługi Azure Network Policy Manager. Aby zamiast tego użyć 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łączonym menedżerem usługi Azure Network Policy Manager — tylko system Linux

W tej sekcji będziemy pracować nad utworzeniem klastra z pulami węzłów systemu Linux i włączonym menedżerem usługi Azure Network Policy Manager.

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 azure dla parametrów 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łączonym menedżerem usługi Azure Network Policy — Windows Server 2022 (wersja zapoznawcza)

W tej sekcji będziemy pracować nad utworzeniem klastra z pulami węzłów systemu Windows i włączonym menedżerem usługi Azure Network Policy Manager.

Uwaga

Menedżer zasad sieci platformy Azure z węzłami systemu Windows jest dostępny tylko w systemie Windows Server 2022.

Instalowanie rozszerzenia interfejsu wiersza polecenia platformy Azure w wersji zapoznawczej usługi aks

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ą dla klientów. 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:

Aby zainstalować rozszerzenie aks-preview, uruchom następujące polecenie:

az extension add --name aks-preview

Uruchom następujące polecenie, aby zaktualizować do najnowszej wersji wydanego rozszerzenia:

az extension update --name aks-preview

Rejestrowanie flagi funkcji "WindowsNetworkPolicyPreview"

Zarejestruj flagę WindowsNetworkPolicyPreview funkcji przy użyciu polecenia az feature register , jak pokazano w poniższym przykładzie:

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

Wyświetlenie stanu Zarejestrowane trwa kilka minut. Sprawdź stan rejestracji przy użyciu polecenia az feature show :

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

Gdy stan będzie odzwierciedlał wartość Zarejestrowano, odśwież rejestrację dostawcy zasobów Microsoft.ContainerService , używając polecenia az provider register :

az provider register --namespace Microsoft.ContainerService

Tworzenie klastra AKS

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 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

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ć. Na przykład:

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

Tworzenie klastra usługi AKS dla zasad sieci Calico

Utwórz klaster usługi AKS i określ azure wtyczkę sieciową oraz calico zasady sieciowe. Użycie calico jako zasady sieciowe 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 usługi AKS z włączonym calico mają również domyślnie włączoną funkcję Direct Server Return (DSR).

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

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 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ć. Na 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 połączenie kubectl 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 działać na porcie 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 -n demo

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 Połączenie ivity 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 z 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 Połączenie ivity 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

Połączenie ivity z ruchem zostanie zablokowany, 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 sieci platformy Kubernetes.