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

Artykuł
07/15/2023

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.
Calico Network Policies, sieć open source i rozwiązanie zabezpieczeń sieci założone przez Tigera.

Usługa Azure Network Policy Manager dla systemu Linux używa tabel IPTable systemu Linux i usługi Azure Network Policy Manager dla systemu Windows, używa zasad ACLPolicie 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ługą Azure Network Policy Manager i zasadami sieci Calico oraz ich możliwościami

Możliwość	Azure Network Policy Manager	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 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 usługa 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 zasobników usługi Azure Network Policy Manager rejestrują błąd w przypadku utworzenia nieobsługiwanych zasad.

Skalowanie

W usłudze Azure Network Policy Manager dla systemu Linux nie zalecamy skalowania poza 250 węzłami i 20 20 tys. zasobników. Jeśli próbujesz skalować poza te limity, może wystąpić awaria braku pamięci (OOM). Aby zwiększyć limit pamięci, skontaktuj się z nami w witrynie aks-can-github.

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 usługi 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 przy użyciu usługi Azure Network Policy Manager. 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łączonym programem Azure Network Policy Manager — 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 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 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 Network Policy Manager — 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 Network Policy Manager.

Uwaga

Usługa Azure Network Policy Manager z węzłami systemu Windows jest dostępna 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 w oparciu o samoobsługę. Wersje zapoznawcze są udostępniane "jak jest" 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ą klienta w oparciu o najlepsze rozwiązania. 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"

Po odzwierciedleniu stanu Zarejestrowane odśwież rejestrację dostawcy zasobów Microsoft.ContainerService przy użyciu 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 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ć. 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 dla wtyczki sieciowej oraz calico dla zasad sieciowych. Użycie calico jako zasady sieci włącza sieć Calico zarówno w pulach węzłów systemu Linux, jak i Windows.

Jeśli planujesz dodawanie pul węzłów systemu Windows do klastra, dołącz 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 korzystania z sieci usługi Azure CNI. Węzły systemu Windows w klastrach usługi AKS z włączoną funkcją Calico mają również domyślnie włączoną funkcję Zwrot serwera bezpośredniego (DSR ).

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

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 kubectl 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 służył 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 łą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, wykonując poprzednie polecenie. 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 z zasadami sieciowymi

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 i zweryfikować łączność z serwerem (dane wyjściowe nie powinny zwracać nic).

kubectl label pod client -n demo app=client

Czyszczenie zasobów

W tym artykule utworzyliśmy przestrzeń nazw i dwa zasobniki i zastosowano 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 kubernetes.

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

Zanim rozpoczniesz

Omówienie zasad sieciowych

Opcje zasad sieciowych w usłudze AKS

Różnice między usługą Azure Network Policy Manager i zasadami sieci Calico oraz ich możliwościami

Ograniczenia

Skalowanie

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

Tworzenie klastra usługi AKS z włączonym programem Azure Network Policy Manager — tylko system Linux

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

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

Rejestrowanie flagi funkcji "WindowsNetworkPolicyPreview"

Tworzenie klastra AKS

Tworzenie klastra usługi AKS dla zasad sieci Calico

Weryfikowanie konfiguracji zasad sieciowych

Testowanie łączności bez zasad sieciowych

Testowanie łączności z zasadami sieciowymi

Czyszczenie zasobów

Następne kroki

Dodatkowe zasoby

Dodatkowe zasoby