Najlepsze rozwiązania dotyczące łączności sieciowej i zabezpieczeń w Azure Kubernetes Service (AKS)

Podczas tworzenia klastrów i zarządzania nimi w Azure Kubernetes Service (AKS) zapewniasz łączność sieciową dla węzłów i aplikacji. Te zasoby sieciowe obejmują zakresy adresów IP, moduły równoważenia obciążenia i kontrolery ruchu przychodzącego.

Ten artykuł dotyczący najlepszych rozwiązań koncentruje się na łączności sieciowej i zabezpieczeniach dla operatorów klastra. W tym artykule omówiono sposób wykonywania następujących zadań:

Wybieranie odpowiedniego modelu sieciowego

Wskazówki dotyczące najlepszych rozwiązań

Użyj Azure CNI Overlay w większości przypadków. Jeśli obciążenia wymagają bezpośredniego dostępu do adresu IP poda z sieci połączonych, użyj sieci płaskiej z Azure CNI Pod Subnet.

Sieci wirtualne zapewniają podstawową łączność dla węzłów AKS oraz klientów, umożliwiając dostęp do aplikacji. Istnieją dwa różne sposoby wdrażania klastrów usługi AKS w sieciach wirtualnych:

• Sieć overlay: Azure CNI Overlay przypisuje adresy IP podów z oddzielnej puli CIDR dla podów. Ruch opuszczający klaster podlega translacji na adres IP węzła, a pody nie są bezpośrednio dostępne z połączonych sieci pod swoimi prywatnymi adresami IP.
• Sieć płaska: Azure CNI Pod Subnet lub starszy Azure CNI Node Subnet przypisują adresy IP podów z przestrzeni adresowej sieci wirtualnej. Do podów można uzyskać dostęp z połączonych sieci pod ich prywatnymi adresami IP.

Aby uzyskać więcej informacji na temat wyboru modelu sieciowego, zobacz Planowanie sieci zasobników w usłudze AKS.

Omówienie sieci Azure CNI

Azure CNI zapewnia zarządzanie adresami IP (IPAM) i łączność dla zasobników i węzłów. Opcja IPAM jest oddzielona od płaszczyzny danych sieciowych. Na przykład można użyć Azure CNI obsługiwanego przez Cilium z Azure CNI Overlay lub opcją sieci płaskiej.

Na poniższym diagramie przedstawiono dwa węzły usługi AKS, z których każdy jest połączony za pośrednictwem mostka sieciowego do udostępnionej sieci wirtualnej Azure.

Azure sieci CNI umożliwiają rozdzielenie kontroli zasobów i zarządzania nimi. Z perspektywy zabezpieczeń często chcesz, aby różne zespoły zarządzały tymi zasobami i zabezpieczały je. Cechy łączności zależą od modelu sieci. Pody sieci overlay inicjują połączenia z siecią wirtualną i zasobami lokalnymi za pośrednictwem adresu IP węzła. Pody w sieci płaskiej mogą komunikować się bezpośrednio z podłączonymi zasobami za pomocą ich prywatnych adresów IP.

W przypadku korzystania z sieci CNI Azure, zasób sieci wirtualnej znajduje się w oddzielnej grupie zasobów od klastra AKS. Przekaż uprawnienia tożsamości klastra AKS do uzyskiwania dostępu do tych zasobów i zarządzania nimi. Tożsamość klastra AKS musi mieć co najmniej uprawnienia współtwórcy sieci dla podsieci w sieci wirtualnej.

Jeśli chcesz zdefiniować rolę niestandardową zamiast korzystać z wbudowanej roli Współautora sieci, wymagane są następujące uprawnienia:

Domyślnie AKS używa zarządzanej tożsamości jako tożsamości klastra. Zamiast tego można użyć pryncypału usługi.

• Aby uzyskać więcej informacji na temat delegowania jednostki usługi AKS, zobacz Delegowanie dostępu do innych zasobów Azure.
• Aby uzyskać więcej informacji na temat tożsamości zarządzanych, zobacz Używanie tożsamości zarządzanych.

Planowanie zakresów adresów na podstawie modelu sieci. Należy pamiętać o następujących kryteriach:

• W przypadku nakładki Azure CNI należy odpowiednio zwymiarować podsieć węzłów dla węzłów i użyć oddzielnego prywatnego zakresu CIDR dla zasobników. Każdy węzeł otrzymuje przestrzeń adresową /24 z zasobnika CIDR.
• W przypadku sieci płaskiej należy odpowiednio dobrać rozmiar podsieci w sieci wirtualnej zarówno dla węzłów, jak i podów. Azure CNI Pod Subnet używa oddzielnych podsieci dla węzłów i podów, natomiast starszy Azure CNI Node Subnet używa jednej podsieci dla obu.
• Unikaj używania zakresów adresów IP, które nakładają się na istniejące zasoby sieciowe.
  • Należy zezwolić na łączność z sieciami lokalnymi lub połączonymi sieciami partnerskimi w środowisku Azure.
• Aby obsłużyć zdarzenia zwiększenia skali lub uaktualnienia klastra, w przypisanej podsieci muszą być dostępne dodatkowe adresy IP.
  • Ta dodatkowa przestrzeń adresowa jest szczególnie ważna, jeśli używasz kontenerów Windows Server, ponieważ te pule węzłów wymagają uaktualnienia w celu zastosowania najnowszych poprawek zabezpieczeń. Aby uzyskać więcej informacji na temat węzłów Windows Server, zobacz Zaktualizuj pulę węzłów w usłudze AKS.

Aby obliczyć wymaganą przestrzeń adresów IP, zobacz Planowanie adresów IP dla klastrów usługi AKS.

Podczas tworzenia klastra z siecią Azure CNI należy określić inne zakresy adresów klastra, takie jak adres IP usługi DNS i zakres adresów usługi. Ogólnie rzecz biorąc, upewnij się, że te zakresy adresów nie nakładają się na siebie ani żadnych sieci skojarzonych z klastrem, w tym żadnych sieci wirtualnych, podsieci, sieci lokalnych i sieci równorzędnych.

Aby uzyskać szczegółowe informacje o modelach sieciowych, limitach i rozmiarach adresacji, zobacz Omówienie sieci Azure CNI.

Dystrybuowanie ruchu przychodzącego

Wskazówki dotyczące najlepszych rozwiązań

Aby dystrybuować ruch HTTP lub HTTPS do aplikacji, użyj zasobów wejściowych i kontrolerów. W porównaniu z równoważnikiem obciążenia Azure, kontrolery wejściowe zapewniają dodatkowe funkcje i mogą być zarządzane jako natywne zasoby Kubernetes.

Chociaż moduł równoważenia obciążenia Azure może dystrybuować ruch klientów do aplikacji w klastrze usługi AKS, ma ograniczone możliwości zrozumienia tego ruchu. Zasób modułu równoważenia obciążenia działa w warstwie 4 i dystrybuuje ruch na podstawie protokołu lub portów.

Większość aplikacji internetowych korzystających z protokołu HTTP lub HTTPS powinna używać zasobów przychodzących i kontrolerów platformy Kubernetes, które działają w warstwie 7. Ingress może dystrybuować ruch na podstawie adresu URL aplikacji i obsługiwać zakończenie połączeń TLS/SSL. System Ingress zmniejsza również liczbę ujawnianych i mapowanych adresów IP.

W przypadku równoważnika obciążenia każda aplikacja zazwyczaj potrzebuje publicznego adresu IP przypisanego i zamapowanego na usługę w klastrze AKS. Za pomocą zasobu ruchu przychodzącego pojedynczy adres IP może dystrybuować ruch do wielu aplikacji.

Diagram przedstawia pojedynczy publiczny adres IP odbierający ruch zewnętrzny oraz kontroler wejściowy, który rozprowadza ten ruch do wielu usług w klastrze AKS.

Ingress ma dwa składniki: zasób Ingress i kontroler Ingress.

Zasób wejściowy

Zasób ingress jest manifestem YAML kind: Ingress. Definiuje hosta, certyfikaty i reguły kierowania ruchu do usług działających w klastrze AKS.

Poniższy przykładowy manifest YAML używa zarządzanej klasy Ingress NGINX dodatku routingu aplikacji. Dystrybuuje ruch dla myapp.com do jednej z dwóch usług, blogservice lub storeservice, i kieruje klienta do jednej usługi lub drugiej na podstawie adresu URL, do którego uzyskuje dostęp.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

Pole ingressClassName wybiera klasę ruchu przychodzącego i musi być zgodna z klasą skonfigurowaną na kontrolerze ruchu przychodzącego w klastrze. Wartość webapprouting.kubernetes.azure.com wybiera zarządzany kontroler wejściowy NGINX udostępniany przez dodatek routingu aplikacji. Zastąp ją nazwą klasy dla kontrolera ruchu przychodzącego, jeśli używasz innej implementacji.

Kontroler wejściowy

Hostowany w klastrze kontroler wejściowy działa jako obciążenie robocze na węźle AKS i monitoruje przychodzące żądania. Ruch przychodzący jest następnie dystrybuowany na podstawie reguł zdefiniowanych w zasobie ruchu przychodzącego skojarzonego z tym kontrolerem. Chociaż najczęstszy kontroler wejściowy jest oparty na NGINX, usługa AKS nie ogranicza cię do określonego kontrolera. Możesz użyć Application Gateway for Containers, Contour, HAProxy, Traefik i innych.

Należy uruchomić kontrolery Ingress hostowane w klastrze na węźle z systemem Linux. Wskaż, że zasób powinien być uruchamiany na węźle z systemem Linux za pomocą selektora węzłów w manifeście YAML lub charcie Helm. Aby uzyskać więcej informacji, zobacz Używanie selektorów węzłów do kontrolowania, gdzie zasobniki są umieszczane w usłudze AKS.

Ingress z dodatkiem do routingu aplikacji

Dodatek do routingu aplikacji zapewnia zarządzane implementacje mechanizmu Ingress w usłudze AKS. W przypadku nowych wdrożeń długoterminowych należy użyć implementacji Gateway API do routingu aplikacji, jeśli spełnia ona wymagania. Gateway API to długoterminowy standard dla Kubernetes, dotyczący ruchu przychodzącego i zarządzania ruchem w warstwie 7.

Zarządzana implementacja serwera NGINX oferuje następujące funkcje:

• Łatwa konfiguracja zarządzanych kontrolerów Ingress NGINX opartych na Kubernetesowym kontrolerze Ingress NGINX.
• Integracja z Azure DNS do zarządzania strefami publicznymi i prywatnymi.
• Zakończenie sesji SSL z certyfikatami przechowywanymi w Azure Key Vault.

Aby uzyskać więcej informacji, zobacz Konfigurowanie ruchu przychodzącego przy użyciu interfejsu API routingu aplikacji i zarządzanego ruchu przychodzącego NGINX za pomocą dodatku routingu aplikacji.

Zabezpieczanie ruchu za pomocą zapory aplikacji internetowej (WAF)

Wskazówki dotyczące najlepszych rozwiązań

Aby skanować ruch przychodzący pod kątem potencjalnych ataków, użyj zapory aplikacji internetowej (WAF), takiej jak zapora aplikacji internetowej Barracuda na potrzeby Azure lub Azure Web Application Firewall w usłudze Application Gateway for Containers. Usługa Application Gateway for Containers kieruje ruchem HTTP, HTTPS, gRPC, WebSocket oraz ruchem związanym z inferencją AI i obsługuje terminację TLS.

Hostowany w klastrze kontroler ruchu przychodzącego działa jako obciążenie robocze platformy Kubernetes w klastrze AKS i kieruje ruch do usług i aplikacji. Zużywa niektóre zasoby węzła, takie jak procesor CPU, pamięć i przepustowość sieci. W większych środowiskach warto rozważyć następujące kwestie:

• Odciążaj trasowanie tego ruchu lub zakończenie sesji TLS do zasobu sieciowego spoza klastra AKS.
• Skanuj ruch przychodzący pod kątem potencjalnych ataków.

Na diagramie przedstawiono ruch zewnętrzny przechodzący przez Azure Application Gateway dla kontenerów. Po skonfigurowaniu ochrony WAF reguły WAF filtrują żądania, zanim usługa Application Gateway for Containers przekaże dozwolony ruch do usług w klastrze AKS.

Aby zapewnić dodatkową warstwę bezpieczeństwa, zapora aplikacji internetowych (WAF) filtruje ruch przychodzący. Zarządzane i niestandardowe reguły chronią przed atakami, takimi jak wykonywanie skryptów między witrynami i wstrzyknięcie kodu SQL. Application Gateway for Containers to usługa równoważenia obciążenia na warstwie 7 i zarządzania ruchem, która obsługuje usługę Azure WAF.

Ochrona WAF nie jest włączana samo przez wdrożenie usługi Application Gateway for Containers. Przed rozpoczęciem inspekcji ruchu przez zaporę aplikacji sieci Web należy utworzyć politykę WAF i wykonać obie poniższe konfiguracje:

• Utwórz zasób podrzędny platformy Azure SecurityPolicy, który odwołuje się do zasad WAF.
• Zastosuj niestandardowy zasób Kubernetes WebApplicationFirewallPolicy, który odwołuje się do tej samej polityki WAF i jest kierowany do zasobu Gateway lub HTTPRoute, który ma być chroniony.

Po zakończeniu obu konfiguracji sprawdź stan zasobu niestandardowego i dzienniki WAF, zanim zaczniesz polegać na tej polityce w zakresie ochrony. Aby uzyskać więcej informacji, zobacz Azure Web Application Firewall w usłudze Application Gateway for Containers.

Ponieważ inne rozwiązania innych firm również wykonują te funkcje, możesz nadal korzystać z istniejących inwestycji lub wiedzy w preferowanym produkcie.

Moduł równoważenia obciążenia lub zasoby wejściowe są stale uruchamiane w klastrze usługi AKS i poprawiają dystrybucję ruchu. Azure Application Gateway dla kontenerów można zarządzać centralnie jako kontroler ruchu przychodzącego z definicją zasobu. Aby rozpocząć, utwórz bramę Application Gateway for Containers, a następnie skonfiguruj ochronę WAF osobno.

Sterowanie przepływem ruchu przy użyciu zasad sieciowych

Wskazówki dotyczące najlepszych rozwiązań

Użyj zasad sieciowych, aby zezwolić na ruch do podów lub go zablokować. Domyślnie cały ruch jest dozwolony między podami w klastrze. Aby zwiększyć bezpieczeństwo, zdefiniuj reguły ograniczające komunikację podu.

Polityki sieciowe to funkcja platformy Kubernetes dostępna w usłudze AKS, która umożliwia zarządzanie przepływem ruchu między podami. Zezwalasz na ruch do poda lub go blokujesz na podstawie ustawień, takich jak przypisane etykiety, przestrzeń nazw lub port. Zasady sieci to natywny dla chmury sposób kontrolowania przepływu ruchu dla podów. Ponieważ zasobniki są tworzone dynamicznie w klastrze usługi AKS, wymagane zasady sieciowe można zastosować automatycznie.

Aby korzystać z zasad sieciowych w usłudze AKS, wybierz mechanizm zasad sieciowych, który obsługuje systemy operacyjne węzłów i płaszczyznę danych sieci. Mechanizm zasad można włączyć podczas tworzenia klastra lub w istniejącym, obsługiwanym klastrze.

W przypadku pul węzłów systemu Linux użyj Azure CNI opartego na technologii Cilium oraz jego wbudowanych mechanizmów wymuszania zasad sieciowych Cilium. Cilium nie jest obsługiwane w przypadku pul węzłów Windows. W przypadku obciążeń Windows użyj calico.

Tworzysz zasady sieciowe jako zasób Kubernetes przy użyciu manifestu YAML. Zasady są stosowane do zdefiniowanych kapsuł, a reguły dotyczące ruchu przychodzącego lub wychodzącego definiują przepływ ruchu.

W poniższym przykładzie zastosowano zasady sieciowe do zasobników z etykietą app: backend. Reguła wejścia zezwala tylko na ruch z podów z etykietą app: frontend.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Aby rozpocząć korzystanie z zasad, przeczytaj Zabezpieczanie ruchu między zasobnikami za pomocą zasad sieciowych w Azure Kubernetes Service (AKS).

Optymalizowanie rozwiązania DNS za pomocą LocalDNS

Wskazówki dotyczące najlepszych rozwiązań

Aby zwiększyć wydajność i niezawodność DNS oraz zmniejszyć obciążenie scentralizowanych podów CoreDNS, użyj LocalDNS. Usługa LocalDNS jest wstępnie skonfigurowana w usłudze AKS Automatic. W usłudze AKS Standard włącz i skonfiguruj usługę LocalDNS dla każdej puli węzłów.

LocalDNS wdraża serwer proxy DNS jako usługę systemd w każdym węźle, aby obsługiwać zapytania DNS lokalnie. Domyślnie zasobniki wysyłają wszystkie zapytania DNS do scentralizowanych zasobników CoreDNS. Przy dużej skali centralizacja tych zapytań może tworzyć wąskie gardło, podczas gdy lokalne rozwiązywanie zmniejsza liczbę przeskoków sieciowych i opóźnienia.

LocalDNS również eliminuje conntrack wpisy tabeli dla ruchu DNS, uniemożliwiając conntrack wyczerpanie tabel i warunki wyścigu, które mogą powodować utracone połączenia. Połączenia z lokalnej pamięci podręcznej do CoreDNS są uaktualniane do protokołu TCP, co umożliwia równoważenie połączeń i szybsze czyszczenie wpisów śledzenia.

W przypadku obciążeń wymagających wysokiej dostępności DNS usługa LocalDNS obsługuje obsługę nieaktualnych odpowiedzi buforowanych przez konfigurowalny czas trwania, gdy nadrzędny system DNS jest niedostępny. Ta najlepsza funkcja może pomóc w utrzymaniu łączności zasobnika i niezawodności usługi podczas przejściowych awarii DNS, ale nie gwarantuje dostępności nieaktualnego rekordu.

W usłudze AKS Standard włączenie funkcji LocalDNS w istniejącej puli węzłów powoduje ponowne utworzenie obrazów jej węzłów. Zaplanuj wdrożenie, aby uwzględnić te zakłócenia.

Aby uzyskać więcej informacji na temat architektury i możliwości localDNS, zobacz Rozpoznawanie nazw DNS w usłudze AKS. Aby uzyskać instrukcje dotyczące konfiguracji, zobacz Konfigurowanie lokalnych sieciDNS.

Bezpiecznie łącz się z węzłami

Wskazówki dotyczące najlepszych rozwiązań

Nie udostępniaj łączności zdalnej z węzłami AKS. Do rutynowego rozwiązywania problemów z węzłami systemu Linux użyj kubectl debug za pomocą interfejsu API platformy Kubernetes. Jeśli potrzebujesz dostępu SSH, połącz się za pośrednictwem sieci prywatnej lub Azure Bastion.

Większość operacji w usłudze AKS można wykonać przy użyciu narzędzi do zarządzania Azure lub serwera interfejsu API Kubernetes. Węzły usługi AKS są dostępne tylko w sieci prywatnej i nie są połączone z publicznym Internetem. W przypadku węzłów systemu Linux użyj polecenia kubectl debug , aby uruchomić kontener debugowania uprzywilejowanego za pośrednictwem interfejsu API platformy Kubernetes. Takie podejście nie wymaga bezpośredniej łączności SSH z węzłem.

Jeśli dostęp do interfejsu API platformy Kubernetes nie jest odpowiedni lub potrzebujesz protokołu SSH, użyj prywatnego adresu IP węzła z połączonej sieci. Azure Bastion może zapewnić łączność prywatną bez uwidaczniania publicznego adresu IP w węźle. W przypadku węzłów Windows użyj kontenera procesów hosta lub połącz się za pośrednictwem węzła serwera proxy systemu Linux. Azure Bastion jest alternatywą, jeśli węzeł proxy jest niedostępny. Aby uzyskać więcej informacji, zobacz Connect to AKS cluster nodes for maintenance or troubleshooting (Nawiązywanie połączenia z węzłami klastra usługi AKS w celu konserwacji lub rozwiązywania problemów).

Na diagramie przedstawiono sieć wirtualną na potrzeby zarządzania zawierającą host bastionowy, który kieruje połączenia przez bezpiecznie zestawione połączenie równorzędne do sieci wirtualnej klastra AKS.

Jeśli używasz hosta bastionowego lub serwera pośredniczącego, umieść go w oddzielnej sieci wirtualnej do zarządzania, połączonej równorzędnie w sposób bezpieczny. Zabezpiecz sieć zarządzania przy użyciu Azure ExpressRoute lub bramy sieci VPN, aby nawiązać połączenie z siecią lokalną i kontrolować dostęp za pomocą sieciowych grup zabezpieczeń.

Następne kroki

Ten artykuł koncentruje się na łączności sieciowej i zabezpieczeniach. Aby uzyskać więcej informacji na temat podstaw sieci na platformie Kubernetes, zobacz Pojęcia dotyczące sieci dla aplikacji w usłudze Azure Kubernetes Service (AKS)