Udostępnij za pośrednictwem

Zabezpieczanie ruchu między zasobnikami przy użyciu zasad sieciowych w usłudze AKS

  • Artykuł

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 chcesz zablokować ruch bezpośrednio do aplikacji zaplecza. Funkcja zasad sieciowych na platformie Kubernetes umożliwia definiowanie reguł dla ruchu przychodzącego i wychodzącego między zasobnikami w klastrze.

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

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. W przypadku korzystania z zasad sieciowych należy zdefiniować uporządkowany zestaw reguł do wysyłania i odbierania ruchu. Reguły są stosowane do kolekcji zasobników pasujących do co najmniej jednego selektora etykiet.

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 udostępnia trzy aparaty zasad sieciowych do wymuszania zasad sieciowych:

Cilium to nasz zalecany aparat zasad sieciowych. Cilium wymusza zasady sieciowe ruchu przy użyciu filtru pakietów w Berkeley (BPF), który jest ogólnie bardziej wydajny niż "IPTables". Zobacz więcej szczegółów w dokumentacji usługi Azure CNI obsługiwanej przez cilium.
Aby wymusić określone zasady, program Azure Network Policy Manager dla systemu Linux używa tabel IPTable systemu Linux. Menedżer zasad sieciowych platformy Azure dla systemu Windows używa zasad ACL usługi sieci hosta (HNS). Zasady są tłumaczone na zestawy dozwolonych i niedozwolonych par adresów IP. Te pary są następnie programowane jako IPTable HNS ACLPolicy lub reguły filtrowania.

Różnice między aparatami zasad sieciowych: Cilium, Azure NPM i Calico

Możliwość Menedżer zasad sieciowych platformy Azure Perkal Cilium
Obsługiwane platformy Linux, Windows Server 2022 (wersja zapoznawcza). Linux, Windows Server 2019 i 2022. Linux.
Obsługiwane opcje sieciowe Azure Container Networking Interface (CNI). Azure CNI (Linux, Windows Server 2019 i 2022) i kubenet (Linux). Azure CNI.
Zgodność ze specyfikacją platformy Kubernetes Obsługiwane wszystkie typy zasad Obsługiwane są wszystkie typy zasad. Obsługiwane są wszystkie typy zasad.
Inne 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. Brak.
Pomoc techniczna Obsługiwane przez zespół pomocy technicznej i inżynierów platformy Azure. Obsługiwane przez zespół pomocy technicznej i inżynierów platformy Azure. Obsługiwane przez zespół pomocy technicznej i inżynierów platformy Azure.

Ograniczenia usługi Azure Network Policy Manager

Uwaga

W przypadku usługi Azure NPM dla systemu Linux nie zezwalamy na skalowanie ponad 250 węzłów i 20 000 zasobników. Jeśli próbujesz skalować poza te limity, mogą wystąpić błędy Braku pamięci (OOM ). Aby uzyskać lepszą skalowalność i obsługę protokołu IPv6, a jeśli istnieją następujące ograniczenia, zalecamy użycie lub uaktualnienie do usługi Azure CNI obsługiwanej przez cilium w celu używania modelu Cilium jako aparatu zasad sieciowych.

Usługa Azure NPM nie obsługuje protokołu IPv6. W przeciwnym razie w pełni obsługuje specyfikacje zasad sieciowych w systemie Linux.

W systemie Windows usługa Azure NPM nie obsługuje następujących funkcji specyfikacji zasad sieciowych:

  • Nazwane porty.
  • Stream Control Transmission Protocol (SCTP).
  • Negatywna etykieta dopasowania lub selektory przestrzeni nazw. Na przykład wszystkie etykiety z wyjątkiem debug=true.
  • except bloki routingu międzydomenowego (CIDR, classless interdomain routing) (CIDR z wyjątkami).

Uwaga

W przypadku utworzenia nieobsługiwanych zasad sieciowych zasobnik usługi Azure Network Policy Manager rejestruje błąd.

Edytowanie/usuwanie zasad sieciowych

W niektórych rzadkich przypadkach istnieje szansa na trafienie stanu wyścigu, co może spowodować tymczasowe, nieoczekiwane połączenie dla nowych połączeń z zasobnikami na dowolnych węzłach, których dotyczy problem podczas edytowania lub usuwania zasad sieciowych "wystarczająco duży". Uderzenie w ten stan wyścigu nigdy nie ma wpływu na aktywne połączenia.

Jeśli ten stan wyścigu wystąpi w węźle, zasobnik azure NPM w tym węźle wchodzi w stan, w którym nie może zaktualizować reguł zabezpieczeń, co może prowadzić do nieoczekiwanej łączności dla nowych połączeń z zasobnikami/z zasobników na węźle, którego dotyczy problem. Aby rozwiązać ten problem, zasobnik usługi Azure NPM automatycznie uruchamia się ponownie ok. 15 sekund po wprowadzeniu tego stanu. Podczas ponownego uruchamiania usługi Azure NPM w węźle, na który ma to wpływ, usuwa wszystkie reguły zabezpieczeń, a następnie ponownie tworzy reguły zabezpieczeń dla wszystkich zasad sieciowych. Podczas ponownego stosowania wszystkich reguł zabezpieczeń istnieje prawdopodobieństwo tymczasowej, nieoczekiwanej łączności dla nowych połączeń do/z zasobników w węźle, na który ma to wpływ.

Aby ograniczyć prawdopodobieństwo osiągnięcia tego stanu wyścigu, można zmniejszyć rozmiar zasad sieciowych. Ten problem najprawdopodobniej występuje w przypadku zasad sieciowych z kilkoma ipBlock sekcjami. Zasady sieciowe z czterema lub mniejszymi ipBlock sekcjami są mniej prawdopodobne, aby napotkać problem.

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.

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

Aby wyświetlić zasady sieciowe w działaniu, należy utworzyć klaster usługi AKS, który obsługuje zasady sieciowe, a następnie pracować nad dodawaniem zasad.

Aby użyć usługi Azure Network Policy Manager, należy użyć wtyczki azure CNI. Calico może być używany z wtyczką azure CNI lub wtyczką CNI Kubenet.

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.

Uwaga

Calico można używać z parametrami --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 utworzysz klaster z pulami węzłów systemu Linux i włączonym menedżerem usługi Azure Network Policy Manager.

Aby rozpocząć, zastąp 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.

Aby utworzyć klaster, użyj następującego polecenia:

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

Tworzenie klastra usługi AKS z włączonym menedżerem usługi Azure Network Policy — Windows Server 2022 (wersja zapoznawcza)

W tej sekcji utworzysz klaster 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ć aks-preview rozszerzenie, uruchom następujące polecenie:

az extension add --name aks-preview

Aby zaktualizować do najnowszej wersji wydanego rozszerzenia, uruchom następujące polecenie:

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ę Microsoft.ContainerService dostawcy zasobów przy użyciu polecenia az provider register :

az provider register --namespace Microsoft.ContainerService

Tworzenie klastra AKS

Teraz zastąp wartości zmiennych $RESOURCE_GROUP_NAME, $CLUSTER_NAMEi $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 go na $WINDOWS_USERNAMEwartość . 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

Aby utworzyć klaster, użyj następującego polecenia:

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

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ć. Oto 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 z włączoną obsługą calico

Utwórz klaster usługi AKS i określ --network-plugin azurewartości , i --network-policy calico. Określanie --network-policy calico włącza calico zarówno w pulach węzłów systemu Linux, jak 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 korzystania z sieci azure CNI. Węzły systemu Windows w klastrach usługi AKS z włączonym calico mają również domyślnie włączony pływający adres IP.

W przypadku klastrów z tylko pulami węzłów systemu Linux z uruchomionym rozwiązaniem Kubernetes 1.20 z wcześniejszymi wersjami calico automatycznie uaktualnia się 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 go na $WINDOWS_USERNAMEwartość . 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

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

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

Instalowanie programu Azure Network Policy Manager lub Calico w istniejącym klastrze

Instalowanie programu Azure Network Policy Manager lub Calico w istniejących klastrach usługi AKS jest również obsługiwane.

Ostrzeżenie

Proces uaktualniania wyzwala ponowne obrazy każdej puli węzłów jednocześnie. Uaktualnienie każdej puli węzłów oddzielnie nie jest obsługiwane. Wszelkie zakłócenia w sieci klastra są podobne do uaktualnienia obrazu węzła lub uaktualnienia wersji platformy Kubernetes, w których każdy węzeł w puli węzłów jest ponownie obrazowany.

Przykładowe polecenie umożliwiające zainstalowanie menedżera usługi Azure Network Policy Manager:

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

Przykładowe polecenie instalacji Calico:

Ostrzeżenie

To ostrzeżenie dotyczy uaktualniania klastrów Kubenet z włączoną funkcją Calico do nakładki CNI platformy Azure z włączoną funkcją Calico.

  • W klastrach Kubenet z włączonym calico calico jest używany zarówno jako aparat zasad CNI, jak i sieci.
  • W klastrach CNI platformy Azure calico jest używane tylko w przypadku wymuszania zasad sieciowych, a nie jako CNI. Może to spowodować krótkie opóźnienie między uruchomieniem zasobnika a tym, kiedy calico zezwala na ruch wychodzący z zasobnika.

Zaleca się stosowanie cilium zamiast Calico, aby uniknąć tego problemu. Dowiedz się więcej o cilium w witrynie Azure CNI Powered by Cilium

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

Uaktualnianie istniejącego klastra z zainstalowanym rozwiązaniem Azure NPM lub Calico do usługi Azure CNI obsługiwanej przez cilium

Aby uaktualnić istniejący klaster z zainstalowanym aparatem zasad sieciowych na platformie Azure CNI obsługiwanym przez cilium, zobacz Uaktualnianie istniejącego klastra do usługi Azure CNI obsługiwanej przez cilium

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, należy utworzyć przykładową aplikację i ustawić reguły ruchu.

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

kubectl create namespace demo

Teraz utwórz dwa zasobniki w klastrze o nazwie client i server.

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 server . Ten zasobnik 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 client . Następujące polecenie uruchamia powłokę Bash na zasobniku client :

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 uruchom następujące polecenie, aby zweryfikować łączność z serwerem. Zastąp server-ip element przy użyciu adresu IP znalezionego w danych wyjściowych z uruchomienia poprzedniego polecenia. Jeśli połączenie zakończy się pomyślnie, nie ma żadnych danych wyjściowych.

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

Testowanie łączności z zasadami sieciowymi

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

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, uruchamiając następujące /agnhost polecenie:

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

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

TIMEOUT

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

kubectl label pod client -n demo app=client

Odinstalowywanie programu Azure Network Policy Manager lub Calico

Wymagania:

  • Interfejs wiersza polecenia platformy Azure w wersji 2.63 lub nowszej

Uwaga

  • Proces odinstalowywania nie powoduje usunięcia niestandardowych definicji zasobów (CRD) i zasobów niestandardowych (CRS) używanych przez Calico. Wszystkie te identyfikatory CRD i CRs mają nazwy kończące się ciągiem "projectcalico.org" lub "tigera.io". Te identyfikatory CRD i skojarzone odwołania CRS można usunąć ręcznie po pomyślnym odinstalowaniu Calico (usunięcie identyfikatorów CRD przed usunięciem calico przerywa działanie klastra).
  • Uaktualnienie nie spowoduje usunięcia żadnych zasobów NetworkPolicy w klastrze, ale po odinstalowaniu tych zasad nie będą już wymuszane.

Ostrzeżenie

Proces uaktualniania wyzwala ponowne obrazy każdej puli węzłów jednocześnie. Uaktualnienie każdej puli węzłów oddzielnie nie jest obsługiwane. Wszelkie zakłócenia w sieci klastra są podobne do uaktualnienia obrazu węzła lub uaktualnienia wersji platformy Kubernetes, w których każdy węzeł w puli węzłów jest ponownie obrazowany.

Aby usunąć menedżera usługi Azure Network Policy Manager lub Calico z klastra, uruchom następujące polecenie:

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

Czyszczenie zasobów

W tym artykule utworzono 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 platformy Kubernetes.