Najlepsze rozwiązania dotyczące łączności sieciowej i zabezpieczeń w usłudze Azure Kubernetes Service

Podczas tworzenia klastrów i zarządzania nimi w usłudze 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ń:

• Porównaj tryby sieciowe kubenet i Azure Container Networking Interface (CNI) w usłudze AKS.
• Zaplanuj wymagane adresowanie IP i łączność.
• Dystrybuuj ruch przy użyciu modułów równoważenia obciążenia, kontrolerów ruchu przychodzącego lub zapory aplikacji internetowej (WAF).
• Bezpieczne łączenie z węzłami klastra.

Wybieranie odpowiedniego modelu sieciowego

Wskazówki dotyczące najlepszych rozwiązań

Użyj sieci usługi Azure CNI w usłudze AKS w celu integracji z istniejącymi sieciami wirtualnymi lub sieciami lokalnymi. Ten model sieci umożliwia większe rozdzielenie zasobów i kontrolek w środowisku przedsiębiorstwa.

Sieci wirtualne zapewniają podstawową łączność dla węzłów usługi AKS i klientów w celu uzyskania dostępu do aplikacji. Istnieją dwa różne sposoby wdrażania klastrów usługi AKS w sieciach wirtualnych:

• Sieć CNI platformy Azure: wdraża w sieci wirtualnej i używa wtyczki Azure CNI Kubernetes. Zasobniki otrzymują poszczególne adresy IP, które mogą kierować do innych usług sieciowych lub zasobów lokalnych.
• Sieć Kubenet: platforma Azure zarządza zasobami sieci wirtualnej podczas wdrażania klastra i używa wtyczki kubenet Kubernetes.

Usługi Azure CNI i kubenet są prawidłowymi opcjami wdrożeń produkcyjnych.

Sieć CNI

Azure CNI to protokół neutralny dla dostawcy, który umożliwia środowisku uruchomieniowemu kontenera wykonywanie żądań do dostawcy sieci. Przypisuje ona adresy IP do zasobników i węzłów oraz udostępnia funkcje zarządzania adresami IP (IPAM) podczas nawiązywania połączenia z istniejącymi sieciami wirtualnymi platformy Azure. Każdy zasób węzła i zasobnika otrzymuje adres IP w sieci wirtualnej platformy Azure. Nie ma potrzeby dodatkowego routingu do komunikowania się z innymi zasobami lub usługami.

W szczególności sieć CNI platformy Azure dla środowiska produkcyjnego umożliwia rozdzielenie kontroli i zarządzania zasobami. Z perspektywy zabezpieczeń często chcesz, aby różne zespoły zarządzały tymi zasobami i zabezpieczały je. Za pomocą sieci usługi Azure CNI można łączyć się z istniejącymi zasobami platformy Azure, zasobami lokalnymi lub innymi usługami bezpośrednio za pośrednictwem adresów IP przypisanych do każdego zasobnika.

W przypadku korzystania z sieci usługi Azure CNI zasób sieci wirtualnej należy do oddzielnej grupy zasobów do klastra usługi AKS. Delegowanie uprawnień dla tożsamości klastra usługi AKS w celu uzyskania dostępu do tych zasobów i zarządzania nimi. Tożsamość klastra używana przez klaster usługi AKS musi mieć co najmniej uprawnienia Współautor sieci w podsieci w sieci wirtualnej.

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

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

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

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

Gdy każdy węzeł i zasobnik odbiera własny adres IP, zaplanuj zakresy adresów dla podsieci usługi AKS. Należy pamiętać o następujących kryteriach:

• Podsieć musi być wystarczająco duża, aby zapewnić adresy IP dla każdego wdrożonego węzła, zasobnika i zasobu sieciowego.
  • W przypadku sieci kubenet i Azure CNI każdy uruchomiony węzeł ma domyślne limity liczby zasobników.
• 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 równorzędnym na platformie Azure.
• Aby obsłużyć zdarzenia skalowania w poziomie lub uaktualnienia klastra, potrzebne są dodatkowe adresy IP dostępne w przypisanej podsieci.
  • Ta dodatkowa przestrzeń adresowa jest szczególnie ważna, jeśli używasz kontenerów systemu 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 systemu Windows Server, zobacz Uaktualnianie puli węzłów w usłudze AKS.

Aby obliczyć wymagany adres IP, zobacz Konfigurowanie sieci usługi Azure CNI w usłudze AKS.

Podczas tworzenia klastra z siecią usługi Azure CNI należy określić inne zakresy adresów klastra, takie jak adres mostka platformy Docker, 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, lokalnych i równorzędnych sieci.

Aby uzyskać szczegółowe informacje dotyczące limitów i określania rozmiaru dla tych zakresów adresów, zobacz Konfigurowanie sieci azure CNI w usłudze AKS.

Sieć Kubenet

Mimo że platforma kubenet nie wymaga skonfigurowania sieci wirtualnych przed wdrożeniem klastra, istnieją wady oczekiwania, takie jak:

• Ponieważ węzły i zasobniki są umieszczane w różnych podsieciach IP, routing zdefiniowany przez użytkownika (UDR) i przekierowywanie ip kieruje ruch między zasobnikami i węzłami. Ten dodatkowy routing może zmniejszyć wydajność sieci.
• Połączenia z istniejącymi sieciami lokalnymi lub komunikacją równorzędną z innymi sieciami wirtualnymi platformy Azure mogą być złożone.

Ponieważ sieć wirtualna i podsieci nie są tworzone oddzielnie od klastra usługi AKS, platforma Kubenet jest idealna w następujących scenariuszach:

• Małe obciążenia programistyczne lub testowe.
• Proste witryny internetowe z niskim ruchem.
• Podnoszenie i przenoszenie obciążeń do kontenerów.

W przypadku wdrożeń produkcyjnych zarówno kubenet, jak i Azure CNI są prawidłowymi opcjami. Środowiska, które wymagają oddzielenia kontroli i zarządzania, usługa Azure CNI może być preferowaną opcją. Ponadto platforma kubenet jest odpowiednia dla środowisk z systemem Linux, w których ochrona zakresu adresów IP jest priorytetem.

Możesz również skonfigurować własne zakresy adresów IP i sieci wirtualne przy użyciu usługi kubenet. Podobnie jak sieć CNI platformy Azure, te zakresy adresów nie powinny nakładać się na siebie ani żadnych sieci skojarzonych z klastrem (sieci wirtualne, podsieci, sieci lokalne i równorzędne).

Aby uzyskać szczegółowe informacje dotyczące limitów i rozmiaru tych zakresów adresów, zobacz Używanie sieci kubenet z własnymi zakresami adresów IP w usłudze AKS.

Dystrybuowanie ruchu przychodzącego

Wskazówki dotyczące najlepszych rozwiązań

Aby dystrybuować ruch HTTP lub HTTPS do aplikacji, użyj zasobów i kontrolerów ruchu przychodzącego. W porównaniu z modułem równoważenia obciążenia platformy Azure kontrolery ruchu przychodzącego zapewniają dodatkowe funkcje i mogą być zarządzane jako natywne zasoby kubernetes.

Moduł równoważenia obciążenia platformy Azure może dystrybuować ruch klientów do aplikacji w klastrze usługi AKS, ale jest ograniczony do 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. Ruch przychodzący może dystrybuować ruch na podstawie adresu URL aplikacji i obsługiwać kończenie żądań PROTOKOŁU TLS/SSL. Ruch przychodzący zmniejsza również liczbę uwidacznianych i mapowych adresów IP.

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

Istnieją dwa składniki ruchu przychodzącego:

1. Zasób ruchu przychodzącego
2. Kontroler ruchu przychodzącego

Zasób ruchu przychodzącego

Zasób ruchu przychodzącego jest manifestem YAML .kind: Ingress Definiuje hosta, certyfikaty i reguły kierowania ruchu do usług uruchomionych w klastrze usługi AKS.

Poniższy przykładowy manifest YAML dystrybuuje ruch dla myapp.com do jednej z dwóch usług, blogservice lub storeservice oraz 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: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

Kontroler ruchu przychodzącego

Kontroler ruchu przychodzącego to demon, który działa w węźle usługi AKS i obserwuje żądania przychodzące. Ruch jest następnie dystrybuowany na podstawie reguł zdefiniowanych w zasobie ruchu przychodzącego. Chociaż najbardziej typowy kontroler ruchu przychodzącego jest oparty na NGINX, usługa AKS nie ogranicza cię do określonego kontrolera. Można użyć konturu, HAProxy, Traefik itp.

Kontrolery ruchu przychodzącego muszą być zaplanowane w węźle systemu Linux. Wskaż, że zasób powinien być uruchamiany w węźle opartym na systemie Linux przy użyciu selektora węzłów w manifeście YAML lub wdrożeniu wykresu helm. Aby uzyskać więcej informacji, zobacz Używanie selektorów węzłów do kontrolowania, gdzie zasobniki są zaplanowane w usłudze AKS.

Ruch przychodzący z dodatkiem routingu aplikacji

Dodatek routingu aplikacji jest zalecanym sposobem konfigurowania kontrolera ruchu przychodzącego w usłudze AKS. Dodatek routingu aplikacji jest w pełni zarządzanym kontrolerem ruchu przychodzącego dla usługi Azure Kubernetes Service (AKS), który zapewnia następujące funkcje:

• Łatwa konfiguracja zarządzanych kontrolerów ruchu przychodzącego NGINX na podstawie kontrolera ruchu przychodzącego NGINX Platformy Kubernetes.

• Integracja z usługą Azure DNS na potrzeby zarządzania strefami publicznymi i prywatnymi.

• Kończenie żądań SSL z certyfikatami przechowywanymi w usłudze Azure Key Vault.

Aby uzyskać więcej informacji na temat dodatku routingu aplikacji, zobacz Managed NGINX ingress with the application routing add-on (Zarządzana ruch przychodzący NGINX z dodatkiem 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 dla platformy Azure lub bramy aplikacja systemu Azure. Te bardziej zaawansowane zasoby sieciowe mogą również kierować ruch poza tylko połączenia HTTP i HTTPS lub podstawowe zakończenie protokołu TLS.

Zazwyczaj kontroler ruchu przychodzącego jest zasobem Kubernetes w klastrze usługi AKS, który dystrybuuje ruch do usług i aplikacji. Kontroler działa jako demon w węźle usługi AKS i korzysta z niektórych zasobów węzła, takich jak procesor CPU, pamięć i przepustowość sieci. W większych środowiskach warto rozważyć następujące kwestie:

• Odciążaj część tego routingu ruchu lub kończenie żądań PROTOKOŁU TLS do zasobu sieciowego spoza klastra usługi AKS.
• Skanuj ruch przychodzący pod kątem potencjalnych ataków.

W przypadku tej dodatkowej warstwy zabezpieczeń zapora aplikacji internetowej filtruje ruch przychodzący. Za pomocą zestawu reguł program Open Web Application Security Project (OWASP) obserwuje ataki, takie jak zatrucie skryptów między witrynami lub zatrucie plików cookie. aplikacja systemu Azure Gateway (obecnie w wersji zapoznawczej w usłudze AKS) to zapora aplikacji internetowej zintegrowana z klastrami usługi AKS, która blokuje te funkcje zabezpieczeń przed dotarciem ruchu do klastra i aplikacji usługi AKS.

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 ruchu przychodzącego są stale uruchamiane w klastrze usługi AKS i uściślić dystrybucję ruchu. Usługa App Gateway może być centralnie zarządzana jako kontroler ruchu przychodzącego z definicją zasobu. Aby rozpocząć, utwórz kontroler ruchu przychodzącego usługi Application Gateway.

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 zasobników lub go zablokować. Domyślnie cały ruch jest dozwolony między zasobnikami w klastrze. Aby zwiększyć bezpieczeństwo, zdefiniuj reguły ograniczające komunikację zasobnika.

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

Aby użyć zasad sieciowych, włącz tę funkcję podczas tworzenia nowego klastra usługi AKS. Nie można włączyć zasad sieciowych w istniejącym klastrze usługi AKS. Zaplanuj z wyprzedzeniem włączenie zasad sieciowych w niezbędnych klastrach.

Uwaga

Zasady sieciowe powinny być używane tylko dla węzłów i zasobników opartych na systemie Linux w usłudze AKS.

Zasady sieciowe są tworzone jako zasób Kubernetes przy użyciu manifestu YAML. Zasady są stosowane do zdefiniowanych zasobników z regułami ruchu przychodzącego lub wychodzącego definiujących przepływ ruchu.

W poniższym przykładzie zastosowano zasady sieciowe do zasobników z aplikacją : etykieta zaplecza zastosowana do nich. Reguła ruchu przychodzącego zezwala tylko na ruch z zasobników z etykietą frontonu aplikacji.

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

Aby rozpocząć pracę z zasadami, zobacz Zabezpieczanie ruchu między zasobnikami przy użyciu zasad sieciowych w usłudze Azure Kubernetes Service (AKS).

Bezpieczne nawiązywanie połączenia z węzłami za pośrednictwem hosta bastionu

Wskazówki dotyczące najlepszych rozwiązań

Nie ujawniaj łączności zdalnej z węzłami usługi AKS. Utwórz hosta bastionu lub serwer przesiadkowy w sieci wirtualnej zarządzania. Użyj hosta bastionu, aby bezpiecznie kierować ruch do klastra usługi AKS do zadań zdalnego zarządzania.

Większość operacji w usłudze AKS można wykonać przy użyciu narzędzi do zarządzania platformy Azure lub za pośrednictwem 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. Aby nawiązać połączenie z węzłami i zapewnić obsługę, skierować połączenia za pośrednictwem hosta bastionu lub serwera przesiadkowego. Sprawdź, czy ten host znajduje się w oddzielnej, bezpiecznej równorzędnej sieci wirtualnej zarządzania do sieci wirtualnej klastra usługi AKS.

Należy również zabezpieczyć sieć zarządzania dla hosta bastionu. Użyj usługi Azure ExpressRoute lub bramy sieci VPN, aby nawiązać połączenie z siecią lokalną i kontrolować dostęp przy użyciu 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 w usłudze Kubernetes, zobacz Pojęcia dotyczące sieci dla aplikacji w usłudze Azure Kubernetes Service (AKS)