Zabezpiecz ruch między podami, używając polityk sieciowych w usłudze 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 chcesz zablokować ruch bezpośrednio do aplikacji back-endowych. 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ć mechanizm polityki sieciowej i utworzyć zasady sieci Kubernetes, aby kontrolować przepływ ruchu między podami 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 back-endowe są często widoczne tylko dla wymaganych usług front-endowych, 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. Polityki sieciowe można uwzględnić jako część 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 dla klastrów usługi AKS korzystających z usługi Azure CNI obsługiwanej przez Cilium.
• Menedżer polityki sieciowej Azure
• Calico, sieć typu open source i rozwiązanie zabezpieczeń sieci założone przez Tigera.

Cilium jest naszym zalecanym silnikiem zasad sieciowych. Cilium wymusza zasady sieciowe na ruchu, używając Berkeley Packet Filter (BPF) w systemie Linux, który jest 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 IPTables. 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 reguły filtrowania IPTable lub HNS ACLPolicy.

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

Ograniczenia usługi Azure Network Policy Manager

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:

• Porty o nazwach
• Protokół sterowania transmisją strumieniową (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).

Edytowanie/usuwanie zasad sieciowych

W niektórych rzadkich przypadkach istnieje szansa na wystąpienie warunków wyścigu, co może spowodować tymczasową, niespodziewaną łączność dla nowych połączeń z/do zasobników na dowolnych dotkniętych węzłach podczas edytowania lub usuwania wystarczająco dużej zasady sieciowej. 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 na 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ń do/z zasobników na dotkniętym węźle. Aby rozwiązać ten problem, pod Azure NPM automatycznie uruchamia się ponownie ok. 15 sekund po wejściu w ten stan. 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 wystąpienia warunku wyścigu, można zmniejszyć rozmiar polityki sieciowej. Ten problem najprawdopodobniej występuje w przypadku zasad sieciowych z kilkoma ipBlock sekcjami. Zasady sieciowe z czterema lub mniejszymiipBlock sekcjami są mniej prawdopodobne, aby napotkać problem.

Filtrowanie ruchu usługi lub modułu równoważenia obciążenia

Routing usługi Kubernetes zarówno dla usług przychodzących, jak i wychodzących często polega na ponownym zapisaniu źródłowych i docelowych adresów IP w przetwarzanym ruchu, w tym ruchu przychodzącym do klastra z usługi LoadBalancer. To zachowanie ponownego zapisywania oznacza, że ruch odbierany z usługi zewnętrznej lub wysyłany do usługi zewnętrznej może nie być prawidłowo przetwarzany przez zasady sieciowe (zobacz dokumentację Zasad sieci kubernetes , aby uzyskać więcej informacji).

Aby ograniczyć źródła, które mogą wysyłać ruch do usługi modułu równoważenia obciążenia, użyj polecenia spec.loadBalancerSourceRanges , aby skonfigurować blokowanie ruchu, które jest stosowane przed wystąpieniem ponownego zapisywania. Więcej informacji można znaleźć w dokumentacji standardowego równoważenia obciążenia usługi AKS .

Zanim rozpoczniesz

Potrzebny jest interfejs wiersza polecenia platformy Azure w wersji 2.0.61 lub nowszej, zainstalowany i skonfigurowany. Aby dowiedzieć się, jaka wersja jest używana, uruchom polecenie az --version. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

Utwórz klaster AKS i włącz zasady sieciowe

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.

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.

Utwórz klaster AKS z włączonym menedżerem zasad sieciowych Azure — tylko dla systemu 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 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.

Zainstaluj rozszerzenie aks-preview dla Azure CLI

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

Zarejestruj flagę funkcji WindowsNetworkPolicyPreview

Zarejestruj flagę funkcji WindowsNetworkPolicyPreview 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

Utwórz klaster 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świetli prośbę o podanie nazwy użytkownika. Ustaw go na wartość $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

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

Utwórz klaster AKS z włączoną obsługą Calico

Utwórz klaster usługi AKS i określ --network-plugin azure oraz --network-policy calico. Określenie --network-policy calico włącza Calico zarówno w pulach węzłów Linux, jak i Windows.

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

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świetli prośbę o podanie nazwy użytkownika. Ustaw go na wartość $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 \
    --generate-ssh-keys

Utworzenie klastra trwa kilka minut. Domyślnie klaster tworzony jest 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

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

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

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:

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, który ma zainstalowany silnik zasad sieciowych do Azure CNI obsługiwanego 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 Kubernetes do ich użycia.

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.

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

Utwórz zasobnik server . Ten pod 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 client . Następujące polecenie uruchamia 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 przy użyciu adresu IP znalezionego w wyjściu z uruchomienia poprzedniego polecenia. Jeśli połączenie zakończy się pomyślnie, nie ma żadnego wyniku.

/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 jako app=server, ale klient nie ma etykiety. 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 niczego zwracać.

kubectl label pod client -n demo app=client

Przejście na samodzielnie zarządzane Calico

Jak pokazano w innych funkcjach tabeli, usługa AKS obsługuje tylko Calico dla standardowych polityk sieci Kubernetes i nie testuje innych funkcji. Jeśli chcesz przejść do samodzielnego zarządzania Calico, postępuj zgodnie z instrukcjami Tigera w dokumencie Migrate from Azure-managed Calico to self-managed Calico. W dokumentacji Tiegra wspomniano, że w przypadku samodzielnie zarządzanego Calico należy ustawić --network-policy none tak jak w sekcji dezinstalacji.

Odinstalowywanie programu Azure Network Policy Manager lub Calico

Requirements:

• Azure CLI w wersji 2.63 lub nowszej

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

Uprzątnij zasoby

W tym artykule utworzono przestrzeń nazw, dwa zasobniki i zastosowano politykę sieciową. Aby wyczyścić te zasoby, użyj polecenia kubectl delete i określ nazwę zasobu:

kubectl delete namespace demo

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