Edytuj

Udostępnij za pośrednictwem

Używanie usługi Azure Firewall do ochrony klastra usługi Azure Kubernetes Service (AKS)

Azure Firewall
Azure Kubernetes Service (AKS)
Azure Private Link
Azure Virtual Network
Azure DevOps

W tym przewodniku opisano sposób tworzenia prywatnego klastra usługi AKS w topologii sieci piasty i szprych przy użyciu programu Terraform i usługi Azure DevOps. Usługa Azure Firewall służy do inspekcji ruchu do i z klastra usługi Azure Kubernetes Service (AKS). Klaster jest hostowany przez co najmniej jedną sieć wirtualną będące szprychą równorzędną z siecią wirtualną piasty.

Architektura

Diagram przedstawiający architekturę, która ma prywatny klaster A K S w topologii sieci piasty i szprych.

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

Moduły programu Terraform służą do wdrażania nowej sieci wirtualnej, która ma cztery podsieci, które hostują:

  • Klaster AKS (AksSubnet).
  • Maszyna wirtualna typu jump-box i prywatne punkty końcowe (VmSubnet).
  • Zapora aplikacji Application Gateway WAF2 (AppGatewaySubnet).
  • Azure Bastion (AzureBastionSubnet).

Klaster usługi AKS używa tożsamości zarządzanej zdefiniowanej przez użytkownika do tworzenia dodatkowych zasobów, takich jak moduły równoważenia obciążenia i dyski zarządzane na platformie Azure. Moduły programu Terraform umożliwiają opcjonalne wdrożenie klastra usługi AKS z następującymi funkcjami:

Klaster usługi AKS składa się z następujących pul:

  • Pula węzłów systemu, która hostuje tylko krytyczne zasobniki systemowe i usługi
  • Pula węzłów użytkownika, która hostuje obciążenia użytkownika i artefakty

Maszyna wirtualna jest wdrażana w sieci wirtualnej, która hostuje klaster usługi AKS. Podczas wdrażania usługi AKS jako klastra prywatnego administratorzy systemu mogą używać tej maszyny wirtualnej do zarządzania klastrem za pośrednictwem narzędzia wiersza polecenia kubernetes. Dzienniki diagnostyki rozruchu maszyny wirtualnej są przechowywane na koncie usługi Azure Storage.

Host usługi Azure Bastion zapewnia lepszą łączność SSH z maszyną wirtualną przesiadkową za pośrednictwem protokołu SSL. Usługa Azure Container Registry służy do tworzenia, przechowywania obrazów i artefaktów kontenerów oraz zarządzania nimi (takich jak wykresy programu Helm).

Usługa AKS nie udostępnia wbudowanego rozwiązania do zabezpieczania ruchu przychodzącego i wychodzącego między klastrem a sieciami zewnętrznymi.

Z tego powodu architektura przedstawiona w tym artykule zawiera usługę Azure Firewall , która kontroluje ruch przychodzący i wychodzący przy użyciu reguł DNAT, reguł sieci i reguł aplikacji. Zapora chroni również obciążenia za pomocą filtrowania opartego na analizie zagrożeń. Usługi Azure Firewall i Bastion są wdrażane w sieci wirtualnej koncentratora, która jest równorzędna z siecią wirtualną hostowaną prywatnym klastrem usługi AKS. Tabela tras i trasy zdefiniowane przez użytkownika kierują ruch wychodzący z klastra usługi AKS do usługi Azure Firewall.

Uwaga

Zdecydowanie zalecamy użycie jednostki SKU Premium usługi Azure Firewall, ponieważ zapewnia zaawansowaną ochronę przed zagrożeniami.

Usługa Key Vault jest używana jako magazyn wpisów tajnych przez obciążenia uruchamiane w usłudze AKS do pobierania kluczy, certyfikatów i wpisów tajnych za pośrednictwem Tożsamość obciążeń Microsoft Entra, sterownika CSI magazynu wpisów tajnych lub języka Dapr. Usługa Azure Private Link umożliwia obciążeniom usługi AKS uzyskiwanie dostępu do usług PaaS platformy Azure, takich jak Azure Key Vault, za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej.

Topologia obejmuje prywatne punkty końcowe i prywatne strefy DNS dla tych usług:

Istnieje połączenie sieci wirtualnej między siecią wirtualną, która hostuje klaster usługi AKS i prywatne strefy DNS opisane wcześniej.

Obszar roboczy usługi Log Analytics służy do zbierania dzienników diagnostycznych i metryk z usług platformy Azure.

Składniki

  • Usługa Azure Firewall to natywna dla chmury, inteligentna usługa zabezpieczeń zapory sieciowej, która zapewnia ochronę przed zagrożeniami dla obciążeń w chmurze uruchamianych na platformie Azure. Jest to w pełni stanowa zapora oferowana jako usługa, z wbudowaną wysoką dostępnością i możliwością nieograniczonego skalowania w chmurze. Zapewnia zarówno inspekcję ruchu na wschód-zachód, jak i północ-południe.

  • Container Registry to zarządzana prywatna usługa rejestru platformy Docker oparta na rejestrze platformy Docker typu open source 2.0. Rejestry kontenerów platformy Azure można używać z istniejącymi potokami tworzenia i wdrażania kontenerów lub tworzyć obrazy kontenerów na platformie Azure za pomocą zadań usługi Container Registry.

  • Usługa Azure Kubernetes Service upraszcza wdrażanie zarządzanych klastrów Kubernetes na platformie Azure, odciążając obciążenie operacyjne na platformę Azure. Jako hostowana usługa Kubernetes platforma Azure obsługuje krytyczne zadania, takie jak monitorowanie kondycji i konserwacja. Ponieważ wzorce kubernetes są zarządzane przez platformę Azure, można zarządzać węzłami agenta i obsługiwać je tylko.

  • Usługa Key Vault przechowuje i kontroluje dostęp do wpisów tajnych, takich jak klucze interfejsu API, hasła, certyfikaty i klucze kryptograficzne z ulepszonymi zabezpieczeniami. Usługa Key Vault pozwala również łatwo aprowizować i wdrażać publiczne i prywatne certyfikaty zabezpieczeń i protokołu Secure Sockets Layer (TLS/SSL) oraz zarządzać nimi w celu użycia z platformą Azure i wewnętrznymi połączonymi zasobami.

  • Azure Bastion to w pełni zarządzana platforma jako usługa (PaaS), którą aprowizujesz w sieci wirtualnej. Usługa Azure Bastion zapewnia ulepszoną łączność protokołu RDP (Remote Desktop Protocol) i protokołu Secure Shell (SSH) z maszynami wirtualnymi w sieci wirtualnej bezpośrednio z poziomu witryny Azure Portal za pośrednictwem protokołu TLS.

  • Usługa Azure Virtual Machines zapewnia skalowalne zasoby obliczeniowe na żądanie, które zapewniają elastyczność wirtualizacji.

  • Usługa Azure Virtual Network to podstawowy blok konstrukcyjny dla sieci prywatnych platformy Azure. Sieć wirtualna umożliwia zasobom platformy Azure (na przykład maszynom wirtualnym) komunikowanie się ze sobą, Internetem i sieciami lokalnymi z ulepszonymi zabezpieczeniami. Sieć wirtualna platformy Azure przypomina tradycyjną sieć lokalną, ale obejmuje korzyści z infrastruktury platformy Azure, takie jak skalowalność, dostępność i izolacja.

  • Wirtualne interfejsy sieciowe umożliwiają maszynom wirtualnym platformy Azure komunikowanie się z Internetem, platformą Azure i zasobami lokalnymi. Możesz dodać kilka kart interfejsu sieciowego do jednej maszyny wirtualnej platformy Azure, aby podrzędne maszyny wirtualne mogły mieć własne dedykowane urządzenia i adresy IP interfejsu sieciowego.

  • Dyski zarządzane platformy Azure zapewniają woluminy magazynu na poziomie bloku zarządzane przez platformę Azure na maszynach wirtualnych platformy Azure. Dostępne są dyski SSD w warstwie Ultra, dyski SSD w warstwie Premium, dyski SSD w warstwie Standardowa i dyski twarde w warstwie Standardowa.

  • Blob Storage to rozwiązanie magazynu obiektów dla chmury. Usługa Blob Storage jest zoptymalizowana pod kątem przechowywania ogromnych ilości danych bez struktury.

  • Usługa Private Link umożliwia dostęp do usług PaaS platformy Azure (na przykład usługi Blob Storage i Key Vault) za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej. Można go również użyć do uzyskiwania dostępu do usług hostowanych na platformie Azure, które są posiadane lub udostępniane przez partnera firmy Microsoft.

Alternatywy

Możesz użyć zapory innej firmy z witryny Azure Marketplace zamiast usługi Azure Firewall. Jeśli to zrobisz, należy prawidłowo skonfigurować zaporę w celu sprawdzenia i zezwolenia na ruch przychodzący i wychodzący z klastra usługi AKS lub go zablokować.

Szczegóły scenariusza

Klastry usługi AKS są wdrażane w sieci wirtualnej, która może być zarządzana lub niestandardowa. Niezależnie od tego klaster ma zależności wychodzące od usług spoza sieci wirtualnej. Do celów zarządzania i działania węzły klastra usługi AKS muszą uzyskiwać dostęp do określonych portów i w pełni kwalifikowanych nazw domen (FQDN) skojarzonych z tymi zależnościami wychodzącymi. Obejmuje to uzyskiwanie dostępu do serwera interfejsu API Kubernetes własnego klastra, pobieranie i instalowanie składników klastra oraz ściąganie obrazów kontenerów z usługi Microsoft Container Registry. Te zależności wychodzące są definiowane za pomocą nazw FQDN i brak adresów statycznych, co uniemożliwia blokowanie ruchu wychodzącego przy użyciu sieciowych grup zabezpieczeń. W związku z tym klastry usługi AKS domyślnie mają nieograniczony dostęp do Internetu (wychodzący), aby umożliwić węzłom i usługom dostęp do zasobów zewnętrznych zgodnie z potrzebami.

Jednak w środowisku produkcyjnym zwykle pożądane jest zabezpieczenie klastra Kubernetes przed eksfiltracją danych i innym niepożądanym ruchem sieciowym. Cały ruch sieciowy, zarówno przychodzący, jak i wychodzący, powinien być kontrolowany na podstawie reguł zabezpieczeń. Aby to osiągnąć, ruch wychodzący musi być ograniczony, jednocześnie zezwalając na dostęp do niezbędnych portów i adresów dla rutynowych zadań konserwacji klastra, zależności wychodzących i wymagań dotyczących obciążenia.

Prostym rozwiązaniem jest użycie urządzenia zapory, które może kontrolować ruch wychodzący na podstawie nazw domen. Zapora tworzy barierę między zaufaną siecią a Internetem. Użyj usługi Azure Firewall , aby ograniczyć ruch wychodzący na podstawie nazwy FQDN, protokołu i portu docelowego, zapewniając precyzyjną kontrolę ruchu wychodzącego. Umożliwia również wyświetlanie listy dozwolonych nazw FQDN skojarzonych z zależnościami wychodzącymi klastra usługi AKS, co nie jest możliwe w przypadku sieciowych grup zabezpieczeń. Ponadto filtrowanie oparte na analizie zagrożeń w usłudze Azure Firewall wdrożone w udostępnionej sieci obwodowej może kontrolować ruch przychodzący i zwiększać bezpieczeństwo. Takie filtrowanie może generować alerty i blokować ruch do i ze znanych złośliwych adresów IP i domen.

Prywatny klaster usługi AKS można utworzyć w topologii sieci piasty i szprych przy użyciu programu Terraform i usługi Azure DevOps. Usługa Azure Firewall służy do inspekcji ruchu do i z klastra usługi Azure Kubernetes Service (AKS). Klaster jest hostowany przez co najmniej jedną sieć wirtualną będące szprychą równorzędną z siecią wirtualną piasty.

Usługa Azure Firewall obsługuje trzy różne jednostki SKU, aby zaspokoić szeroką gamę przypadków użycia i preferencji klientów:

  • Usługa Azure Firewall Premium jest zalecana do zabezpieczania wysoce poufnych aplikacji, takich jak przetwarzanie płatności. Obsługuje zaawansowane funkcje ochrony przed zagrożeniami, takie jak złośliwe oprogramowanie i inspekcja protokołu TLS.
  • Usługa Azure Firewall w warstwie Standardowa jest zalecana dla klientów poszukujących zapory warstwy 3–Warstwy 7 i którzy potrzebują automatycznego skalowania w celu obsługi szczytowych okresów ruchu do 30 Gb/s. Obsługuje ona funkcje przedsiębiorstwa, takie jak analiza zagrożeń, serwer proxy DNS, niestandardowe kategorie DNS i sieci Web.
  • Usługa Azure Firewall w warstwie Podstawowa jest zalecana dla klientów, którzy potrzebują przepływności mniejszej niż 250 Mb/s.

W poniższej tabeli przedstawiono funkcje trzech jednostek SKU usługi Azure Firewall. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Firewall.

Zrzut ekranu przedstawiający funkcje trzech jednostek SKU usługi Azure Firewall

Domyślnie klastry usługi AKS mają nieograniczony wychodzący dostęp do Internetu. Ten poziom dostępu do sieci umożliwia węzłom i usługom uruchomionym w klastrze usługi AKS dostęp do zasobów zewnętrznych zgodnie z potrzebami. Jeśli chcesz ograniczyć ruch wychodzący, ograniczona liczba portów i adresów musi pozostać dostępna w celu utrzymania zadań konserwacji klastra w dobrej kondycji. Najprostszym sposobem zapewnienia zabezpieczeń ruchu wychodzącego z klastra Kubernetes, takiego jak AKS, jest użycie zapory oprogramowania, która może kontrolować ruch wychodzący na podstawie nazw domen. Usługa Azure Firewall może ograniczyć wychodzący ruch HTTP i HTTPS na podstawie w pełni kwalifikowanej nazwy domeny (FQDN) miejsca docelowego. Możesz również skonfigurować reguły zapory i zabezpieczeń, aby zezwolić na te wymagane porty i adresy. Aby uzyskać więcej informacji, zobacz Kontrolowanie ruchu wychodzącego dla węzłów klastra w usłudze AKS.

Podobnie możesz kontrolować ruch przychodzący i zwiększyć bezpieczeństwo, włączając filtrowanie oparte na analizie zagrożeń w usłudze Azure Firewall wdrożonej w udostępnionej sieci obwodowej. Takie filtrowanie może zapewniać alerty i blokować ruch do i ze znanych złośliwych adresów IP i domen.

Potencjalne przypadki użycia

Ten scenariusz eliminuje konieczność zwiększenia bezpieczeństwa ruchu przychodzącego i wychodzącego do i z klastra Kubernetes.

Unikanie routingu asymetrycznego

W tym rozwiązaniu usługa Azure Firewall jest wdrażana w sieci wirtualnej koncentratora, a prywatny klaster AKS jest wdrażany w sieci wirtualnej będącej szprychą. Usługa Azure Firewall używa kolekcji reguł sieci i aplikacji do kontrolowania ruchu wychodzącego. W takiej sytuacji należy skonfigurować ruch przychodzący do dowolnego publicznego punktu końcowego uwidocznionego przez dowolną usługę działającą w usłudze AKS, aby wprowadzić system za pośrednictwem jednego z publicznych adresów IP używanych przez usługę Azure Firewall.

Pakiety docierają do publicznego adresu IP zapory, ale wracają do zapory za pośrednictwem prywatnego adresu IP (przy użyciu trasy domyślnej). Jest to problem. Aby tego uniknąć, utwórz inną trasę zdefiniowaną przez użytkownika dla publicznego adresu IP zapory, jak pokazano na poniższym diagramie. Pakiety przechodzące do publicznego adresu IP zapory są kierowane przez Internet. Ta konfiguracja pozwala uniknąć domyślnej trasy do prywatnego adresu IP zapory.

Aby skierować ruch obciążeń usługi AKS do usługi Azure Firewall w sieci wirtualnej koncentratora, musisz:

  • Utwórz i skojarz tabelę tras z każdą podsiecią, która hostuje węzły robocze klastra.
  • Utwórz trasę zdefiniowaną przez użytkownika, aby przekazać ruch do trasy CIDR 0.0.0.0.0/0 do prywatnego adresu IP usługi Azure Firewall. Określ urządzenie wirtualne dla typu Następnego przeskoku.

Aby uzyskać więcej informacji, zobacz Samouczek: wdrażanie i konfigurowanie usługi Azure Firewall przy użyciu witryny Azure Portal.

Diagram przedstawiający sposób unikania routingu asymetrycznego podczas korzystania z usługi Azure Firewall przed obciążeniami.

Aby uzyskać więcej informacji, zobacz:

Wdrażanie obciążeń w prywatnym klastrze usługi AKS podczas korzystania z usługi Azure DevOps

Jeśli używasz usługi Azure DevOps, pamiętaj, że nie można używać agentów hostowanych przez firmę Microsoft w usłudze Azure DevOps do wdrażania obciążeń w prywatnym klastrze usługi AKS. Nie mają dostępu do serwera interfejsu API. Aby wdrożyć obciążenia w prywatnym klastrze usługi AKS, należy aprowizować i używać własnego agenta usługi Azure DevOps w tej samej sieci wirtualnej co prywatny klaster usługi AKS lub w równorzędnej sieci wirtualnej. W tym drugim przypadku należy utworzyć połączenie sieci wirtualnej między prywatną strefą DNS klastra usługi AKS w grupie zasobów węzła i siecią wirtualną, która hostuje własnego agenta usługi Azure DevOps.

Na maszynie wirtualnej można wdrożyć jednego agenta usługi Azure DevOps z systemem Windows lub Linux albo użyć zestawu skalowania maszyn wirtualnych. Aby uzyskać więcej informacji, zobacz Agenci zestawu skalowania maszyn wirtualnych platformy Azure. Alternatywnie można skonfigurować własnego agenta w usłudze Azure Pipelines do uruchamiania wewnątrz kontenera Windows Server Core (dla hostów systemu Windows) lub kontenera Ubuntu (dla hostów systemu Linux) za pomocą platformy Docker. Wdróż go jako zasobnik z jedną lub wieloma replikami w prywatnym klastrze usługi AKS. Aby uzyskać więcej informacji, zobacz:

Jeśli podsieci hostujące pule węzłów prywatnego klastra usługi AKS są skonfigurowane do kierowania ruchu wychodzącego do usługi Azure Firewall za pośrednictwem tabeli tras i trasy zdefiniowanej przez użytkownika, pamiętaj o utworzeniu odpowiednich reguł aplikacji i sieci. Te reguły muszą zezwalać agentowi na dostęp do witryn zewnętrznych w celu pobierania i instalowania narzędzi, takich jak Docker, Kubectl, interfejs wiersza polecenia platformy Azure i program Helm na maszynie wirtualnej agenta. Aby uzyskać więcej informacji, zobacz Uruchamianie własnego agenta na platformie Docker.

Diagram przedstawiający wdrażanie obciążeń w prywatnym klastrze usługi AKS do użycia z usługą Azure DevOps.

Alternatywnie można skonfigurować zarządzaną pulę DevOps (MDP) w sieci wirtualnej hostująca klaster usługi AKS lub w równorzędnej sieci wirtualnej. Zarządzane pule DevOps umożliwiają zespołom deweloperów tworzenie pul agentów usługi Azure DevOps dostosowanych do określonych potrzeb. Implementuje najlepsze rozwiązania w zakresie zabezpieczeń, zapewnia opcje równoważenia kosztów i wydajności, oferuje ścieżki dla typowych scenariuszy i znacznie skraca czas spędzony na tworzeniu i utrzymywaniu pul niestandardowych. Aby uzyskać więcej informacji, zobacz Omówienie architektury pul DevOps zarządzanych przez firmę Microsoft.

Możesz dodać agentów z zarządzanej puli DevOps w sieci wirtualnej, umożliwiając potokom ciągłej integracji/ciągłego wdrażania interakcję z serwerem interfejsu API Kubernetes prywatnego klastra usługi AKS i uzyskiwać dostęp do zasobów platformy Azure, takich jak usługa Azure Container Registry, które mają wyłączony dostęp do sieci publicznej i można uzyskać dostęp tylko za pośrednictwem prywatnego punktu końcowego zdefiniowanego w tej samej sieci wirtualnej lub równorzędnej sieci. Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci zarządzanych pul DevOps.

Użyj usługi Azure Firewall przed publicznym usługa Load Balancer w warstwie Standardowa

Definicje zasobów w modułach programu Terraform używają meta-argumentu cyklu życia do dostosowywania akcji, gdy zasoby platformy Azure są zmieniane poza kontrolą narzędzia Terraform. Argument ignore_changes służy do poinstruowania narzędzia Terraform o ignorowaniu aktualizacji dla danych właściwości zasobów, takich jak tagi. Definicja zasobu usługi Azure Firewall Policy zawiera blok cyklu życia, aby uniemożliwić programowi Terraform aktualizowanie zasobu podczas tworzenia, aktualizowania lub usuwania kolekcji reguł lub pojedynczej reguły. Podobnie tabela tras platformy Azure zawiera blok cyklu życia, aby uniemożliwić programowi Terraform aktualizowanie zasobu podczas tworzenia, usuwania lub aktualizowania trasy zdefiniowanej przez użytkownika. Dzięki temu można zarządzać regułami DNAT, aplikacji i sieci zasad usługi Azure Firewall oraz tras zdefiniowanych przez użytkownika tabeli tras platformy Azure poza kontrolą narzędzia Terraform.

Przykład skojarzony z tym artykułem zawiera potok ciągłego wdrażania usługi Azure DevOps, który pokazuje, jak wdrożyć obciążenie w prywatnym klastrze usługi AKS przy użyciu potoku usługi Azure DevOps uruchamianego na własnym agencie. Przykład wdraża aplikację internetową do zarządzania projektami redmine bitnami przy użyciu publicznego wykresu Helm. Na tym diagramie przedstawiono topologię sieci przykładu:

Diagram przedstawiający usługę Azure Firewall przed publicznym usługa Load Balancer w warstwie Standardowa.

Oto przepływ komunikatów:

  1. Żądanie aplikacji internetowej hostowanej przez usługę AKS jest wysyłane do publicznego adresu IP uwidocznionego przez usługę Azure Firewall za pośrednictwem konfiguracji publicznego adresu IP. Zarówno publiczny adres IP, jak i konfiguracja publicznego adresu IP są dedykowane dla tego obciążenia.
  2. Reguła DNAT usługi Azure Firewall tłumaczy publiczny adres IP i port usługi Azure Firewall na publiczny adres IP i port używany przez obciążenie w publicznej usługa Load Balancer w warstwie Standardowa klastra AKS w grupie zasobów węzła.
  3. Moduł równoważenia obciążenia wysyła żądanie do jednego z zasobników usługi Kubernetes uruchomionych w jednym z węzłów agenta klastra usługi AKS.
  4. Komunikat odpowiedzi jest wysyłany z powrotem do oryginalnego wywołującego za pośrednictwem trasy zdefiniowanej przez użytkownika. Publiczny adres IP usługi Azure Firewall jest prefiksem adresu, a Internet to typ następnego przeskoku.
  5. Każde wywołanie wychodzące inicjowane przez obciążenie jest kierowane do prywatnego adresu IP usługi Azure Firewall przez domyślną trasę zdefiniowaną przez użytkownika. 0.0.0.0/0 jest prefiksem adresu, a urządzenie wirtualne to typ następnego przeskoku.

Aby uzyskać więcej informacji, zobacz Używanie usługi Azure Firewall przed publicznym usługa Load Balancer w warstwie Standardowa klastra usługi AKS.

Używanie usługi Azure Firewall przed wewnętrznym usługa Load Balancer w warstwie Standardowa

W przykładzie skojarzonym z tym artykułem aplikacja ASP.NET Core jest hostowana jako usługa przez klaster usługi AKS i fronted przez kontroler ruchu przychodzącego NGINX. Kontroler ruchu przychodzącego NGINX jest uwidaczniony za pośrednictwem wewnętrznego modułu równoważenia obciążenia, który ma prywatny adres IP w sieci wirtualnej będącej szprychą, która hostuje klaster usługi AKS. Aby uzyskać więcej informacji, zobacz Tworzenie kontrolera ruchu przychodzącego do wewnętrznej sieci wirtualnej w usłudze AKS. Podczas wdrażania kontrolera ruchu przychodzącego NGINX lub ogólniej usługi LoadBalancer lub ClusterIP , z service.beta.kubernetes.io/azure-load-balancer-internal: "true" adnotacją w sekcji metadanych, wewnętrzny standardowy moduł równoważenia obciążenia o nazwie kubernetes-internal jest tworzony w grupie zasobów węzła. Aby uzyskać więcej informacji, zobacz Używanie wewnętrznego modułu równoważenia obciążenia z usługą AKS. Jak pokazano na poniższym diagramie, testowa aplikacja internetowa jest uwidaczniona przez usługę Azure Firewall za pośrednictwem dedykowanego publicznego adresu IP platformy Azure.

Diagram przedstawiający usługę Azure Firewall przed wewnętrznym usługa Load Balancer w warstwie Standardowa.

Oto przepływ komunikatów:

  1. Żądanie aplikacji internetowej hostowanej w usłudze AKS jest wysyłane do publicznego adresu IP uwidocznionego przez usługę Azure Firewall za pośrednictwem konfiguracji publicznego adresu IP. Zarówno publiczny adres IP, jak i konfiguracja publicznego adresu IP są dedykowane dla tego obciążenia.
  2. Reguła DNAT usługi Azure Firewall tłumaczy publiczny adres IP i port usługi Azure Firewall na prywatny adres IP i port używany przez kontroler ruchu przychodzącego NGINX w wewnętrznej usługa Load Balancer w warstwie Standardowa klastra usługi AKS w grupie zasobów węzła.
  3. Żądanie jest wysyłane przez wewnętrzny moduł równoważenia obciążenia do jednego z zasobników usługi Kubernetes uruchomionych w jednym z węzłów agenta klastra usługi AKS.
  4. Komunikat odpowiedzi jest wysyłany z powrotem do oryginalnego wywołującego za pośrednictwem trasy zdefiniowanej przez użytkownika. 0.0.0.0/0 jest prefiksem adresu, a urządzenie wirtualne to typ następnego przeskoku.
  5. Każde wywołanie wychodzące inicjowane przez obciążenie jest kierowane do prywatnego adresu IP trasy zdefiniowanej przez użytkownika.

Aby uzyskać więcej informacji, zobacz Używanie usługi Azure Firewall przed wewnętrznym usługa Load Balancer w warstwie Standardowa.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Niektóre z poniższych zagadnień to ogólne zalecenia, które nie są specyficzne dla używania usługi Azure Firewall w celu poprawy ochrony klastra usługi AKS. Uważamy, że są to podstawowe wymagania tego rozwiązania. Dotyczy to zagadnień związanych z zabezpieczeniami, wydajnością, dostępnością i niezawodnością, magazynem, siatką usług i monitorowaniem.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

Platforma Azure zapewnia lepszą ochronę przed różnymi zagrożeniami, takimi jak włamanie do sieci i rozproszone ataki typu "odmowa usługi" (DDoS). Zapora aplikacji internetowej (WAF) powinna zapewnić ochronę wszystkich aplikacji internetowych hostowanych przez usługę AKS, które uwidacznia publiczny punkt końcowy HTTPS. Należy zapewnić ochronę przed typowymi zagrożeniami, takimi jak wstrzyknięcie kodu SQL, wykonywanie skryptów między witrynami i inne luki w sieci Web. W tym celu użyj reguł Open Web Application Security Project (OWASP) i reguł niestandardowych. Usługa Azure Web Application Firewall zapewnia ulepszoną scentralizowaną ochronę aplikacji internetowych przed typowymi lukami w zabezpieczeniach i lukami w zabezpieczeniach. Zaporę aplikacji internetowej platformy Azure można wdrożyć za pomocą usługi aplikacja systemu Azure Gateway, Azure Front Door i Azure Content Delivery Network.

Ataki DDoS należą do największych problemów z dostępnością i zabezpieczeniami, przed którymi stoją organizacje, które przenoszą aplikacje do chmury. Atak DDoS próbuje wyczerpać zasoby aplikacji, dzięki czemu aplikacja jest niedostępna dla uprawnionych użytkowników. Ataki DDoS mogą być kierowane do dowolnego punktu końcowego, który jest publicznie dostępny za pośrednictwem Internetu. Każda właściwość na platformie Azure obejmuje ochronę za pośrednictwem ochrony infrastruktury usługi Azure DDoS bez dodatkowych kosztów. Skala i pojemność globalnie wdrożonej sieci platformy Azure zapewnia lepszą ochronę przed typowymi atakami w warstwie sieciowej dzięki monitorowaniu ruchu zawsze włączonemu i ograniczaniu ryzyka w czasie rzeczywistym. Ochrona infrastruktury przed atakami DDoS nie wymaga żadnych zmian konfiguracji użytkownika ani aplikacji. Pomaga ona chronić wszystkie usługi platformy Azure, w tym usługi PaaS, takie jak Azure DNS.

Usługa Azure DDoS Network Protection w połączeniu z najlepszymi rozwiązaniami dotyczącymi projektowania aplikacji zapewnia ulepszone funkcje ograniczania ryzyka ataków DDoS w celu zapewnienia większej ochrony przed atakami DDoS. Należy włączyć usługę Azure DDOS Network Protection w dowolnej sieci obwodowej.

Poniżej przedstawiono kilka dodatkowych zagadnień dotyczących zabezpieczeń:

  • Utwórz prywatny punkt końcowy dla dowolnej usługi PaaS używanej przez obciążenia usługi AKS, takich jak Key Vault, Azure Service Bus i Azure SQL Database. Ruch między aplikacjami a tymi usługami nie jest narażony na publiczny Internet. Ruch między siecią wirtualną klastra AKS a wystąpieniem usługi PaaS za pośrednictwem prywatnego punktu końcowego podróżuje siecią szkieletową firmy Microsoft, ale komunikacja nie jest przekazywana przez usługę Azure Firewall. Ten mechanizm zapewnia lepsze zabezpieczenia i lepszą ochronę przed wyciekiem danych. Aby uzyskać więcej informacji, zobacz Co to jest usługa Azure Private Link?.
  • Jeśli używasz usługi Application Gateway przed klastrem usługi AKS, użyj zasad zapory aplikacji internetowej, aby ułatwić ochronę obciążeń publicznych uruchamianych w usłudze AKS przed atakami.
  • Zasady sieci umożliwiają segregowanie i zabezpieczanie komunikacji wewnątrzusługowej przez kontrolowanie, które składniki mogą komunikować się ze sobą. Domyślnie wszystkie zasobniki w klastrze Kubernetes mogą wysyłać i odbierać ruch bez ograniczeń. Aby zwiększyć bezpieczeństwo, możesz użyć zasad sieciowych platformy Azure lub zasad sieci Calico, aby zdefiniować reguły kontrolujące przepływ ruchu między różnymi mikrousługami. Aby uzyskać więcej informacji, zobacz zasady sieciowe.
  • 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 kierować ruch do klastra usługi AKS.
  • Rozważ użycie prywatnego klastra usługi AKS w środowisku produkcyjnym lub przynajmniej bezpiecznego dostępu do serwera interfejsu API przy użyciu autoryzowanych zakresów adresów IP w usłudze AKS. Jeśli używasz autoryzowanych zakresów adresów IP w klastrze publicznym, zezwól na wszystkie adresy IP ruchu wychodzącego w kolekcji reguł sieci usługi Azure Firewall. Operacje w klastrze używają serwera interfejsu API Kubernetes.
  • Jeśli włączysz serwer proxy DNS w usłudze Azure Firewall, usługa Azure Firewall może przetwarzać i przekazywać zapytania DNS z co najmniej jednej sieci wirtualnej do wybranego serwera DNS. Ta funkcja jest kluczowa i wymagana do niezawodnego filtrowania nazw FQDN w regułach sieci. Serwer proxy DNS można włączyć w ustawieniach usługi Azure Firewall i zasad zapory. Aby dowiedzieć się więcej na temat dzienników serwera proxy DNS, zobacz Dziennik i metryki usługi Azure Firewall.
  • W przypadku korzystania z usługi Azure Firewall przed usługą Application Gateway możesz skonfigurować zasób ruchu przychodzącego Kubernetes w celu uwidocznienia obciążeń za pośrednictwem protokołu HTTPS i użyć oddzielnej poddomeny i certyfikatu cyfrowego dla każdej dzierżawy. Kontroler ruchu przychodzącego usługi Application Gateway (AGIC) automatycznie konfiguruje odbiornik usługi Application Gateway na potrzeby kończenia żądań protokołu SSL (Secure Sockets Layer).
  • Usługę Azure Firewall można używać przed serwerem proxy usługi, na przykład kontrolerem ruchu przychodzącego NGINX. Ten kontroler zapewnia zwrotny serwer proxy, konfigurowalny routing ruchu i kończenie żądań TLS dla usług Kubernetes. Zasoby ruchu przychodzącego usług Kubernetes są używane do skonfigurowania zasad ruchu przychodzącego oraz tras dla poszczególnych usług Kubernetes. Za pomocą kontrolera ruchu przychodzącego i reguł ruchu przychodzącego można użyć jednego adresu IP do kierowania ruchu do wielu usług w klastrze Kubernetes. Certyfikaty TLS można wygenerować przy użyciu rozpoznanego urzędu certyfikacji. Alternatywnie możesz użyć funkcji Let's Encrypt, aby automatycznie wygenerować certyfikaty TLS z dynamicznym publicznym adresem IP lub statycznym publicznym adresem IP. Aby uzyskać więcej informacji, zobacz Tworzenie kontrolera ruchu przychodzącego HTTPS i używanie własnych certyfikatów TLS w usłudze AKS.
  • Ścisła koordynacja między operatorem usługi Azure Firewall i zespołami klastrów i obciążeń jest niezbędna zarówno do początkowego wdrożenia klastra, jak i w sposób ciągły w miarę rozwoju potrzeb związanych z obciążeniem i klastrem. Jest to szczególnie istotne w przypadku konfigurowania mechanizmów uwierzytelniania, takich jak OAuth 2.0 i OpenID Connect, które są używane przez obciążenia do uwierzytelniania klientów.
  • Skorzystaj z poniższych wskazówek, aby zabezpieczyć środowisko opisane w tym artykule:

Dostępność i niezawodność

Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.

Zagadnienia dotyczące dostępności i niezawodności nie są specyficzne dla wielodostępności w usłudze AKS. Uważamy, że są to podstawowe wymagania dotyczące tego rozwiązania. Rozważ następujące metody optymalizacji dostępności klastra i obciążeń usługi AKS.

Odporność wewnątrz regionu

  • Podczas wdrażania można skonfigurować usługę Azure Firewall tak, aby obejmowała wiele stref dostępności w celu zwiększenia dostępności. Aby uzyskać informacje o procentach czasu pracy, zobacz umowę SLA usługi Azure Firewall. Możesz również skojarzyć usługę Azure Firewall z określoną strefą ze względu na bliskość, chociaż ta konfiguracja ma wpływ na umowę SLA. Zapora wdrożona w strefie dostępności nie ma dodatkowych kosztów, w tym transferów danych między strefami dostępności.
  • Rozważ wdrożenie pul węzłów klastra usługi AKS we wszystkich strefach dostępności w regionie. Użyj usługi Azure usługa Load Balancer w warstwie Standardowa lub Application Gateway przed pulami węzłów. Ta topologia zapewnia lepszą odporność w przypadku awarii pojedynczego centrum danych. Węzły klastra są rozproszone w wielu centrach danych w trzech oddzielnych strefach dostępności w regionie.
  • Włącz nadmiarowość stref w usłudze Container Registry w celu zapewnienia odporności wewnątrz regionu i wysokiej dostępności.
  • Użyj ograniczeń rozprzestrzeniania się topologii zasobników, aby kontrolować, jak zasobniki są rozmieszczone w klastrze usługi AKS między domenami awarii, takimi jak regiony, strefy dostępności i węzły.
  • Rozważ użycie umowy SLA czasu pracy dla klastrów usługi AKS hostujących obciążenia o krytycznym znaczeniu. Umowa SLA dotycząca czasu pracy to opcjonalna funkcja, która umożliwia wsparcie finansowe, wyższe umowy SLA dla klastra. Umowa SLA dotycząca czasu działania gwarantuje wysoką dostępność punktu końcowego serwera interfejsu API Kubernetes dla klastrów korzystających ze stref dostępności. Można go również używać w przypadku klastrów, które nie korzystają ze stref dostępności, ale umowa SLA jest niższa. Aby uzyskać szczegółowe informacje o umowie SLA, zobacz Umowa SLA dotycząca czasu pracy. Usługa AKS używa replik węzłów głównych w wielu domenach błędów i aktualizacji, aby zapewnić spełnienie wymagań umowy SLA.

Ciągłość biznesowa i odzyskiwanie po awarii

  • Rozważ wdrożenie rozwiązania w co najmniej dwóch sparowanych regionach świadczenia usługi Azure w obszarze geograficznym. Użyj globalnego modułu równoważenia obciążenia, takiego jak azure Traffic Manager lub Azure Front Door, z aktywną/aktywną lub pasywną metodą routingu, aby zagwarantować ciągłość działania i odzyskiwanie po awarii (DR).
  • Azure Firewall to usługa regionalna. Jeśli wdrażasz rozwiązanie w co najmniej dwóch regionach, musisz utworzyć usługę Azure Firewall w każdym regionie. Globalne zasady usługi Azure Firewall można utworzyć w celu uwzględnienia reguł z uprawnieniami organizacji, które mają zastosowanie do wszystkich centrów regionalnych. Te zasady można użyć jako zasad nadrzędnych dla regionalnych zasad platformy Azure. Zasady utworzone przy użyciu niepustych zasad nadrzędnych dziedziczą wszystkie kolekcje reguł z zasad nadrzędnych. Kolekcje reguł sieci dziedziczone z zasad nadrzędnych są zawsze priorytetami powyżej kolekcji reguł sieci, które są zdefiniowane jako część nowych zasad. Ta sama logika ma zastosowanie do kolekcji reguł aplikacji. Jednak kolekcje reguł sieciowych są zawsze przetwarzane przed kolekcjami reguł aplikacji, niezależnie od dziedziczenia. Aby uzyskać więcej informacji na temat zasad w warstwie Standardowa i Premium, zobacz Omówienie zasad usługi Azure Firewall Manager.
  • Pamiętaj, aby skrypt, dokument i okresowo testować dowolny regionalny proces trybu failover w środowisku kontroli jakości. Dzięki temu można uniknąć nieprzewidywalnych problemów, jeśli awaria usługi podstawowej ma wpływ na awarię w regionie podstawowym. Te testy sprawdzają również, czy podejście odzyskiwania po awarii spełnia cele celu punktu odzyskiwania/celu punktu odzyskiwania w połączeniu z ewentualnymi procesami ręcznymi i interwencjami, które są potrzebne do przejścia w tryb failover.
  • Pamiętaj, aby przetestować procedury powrotu po awarii, aby sprawdzić, czy działają zgodnie z oczekiwaniami.
  • Przechowywanie obrazów kontenerów w usłudze Container Registry. Replikacja geograficzna rejestru do każdego regionu usługi AKS. Aby uzyskać więcej informacji, zobacz Replikacja geograficzna w usłudze Azure Container Registry.
  • Jeśli to możliwe, unikaj przechowywania stanu usługi w kontenerze. Zamiast tego należy użyć usługi Azure PaaS obsługującej replikację w wielu regionach.
  • Jeśli używasz usługi Azure Storage, przygotuj i przetestujesz proces migracji magazynu z regionu podstawowego do regionu tworzenia kopii zapasowych.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.

DevOps

  • Wdróż obciążenia w usłudze AKS przy użyciu pakietu Helm w potoku ciągłej integracji i ciągłego dostarczania (CI/CD). Użyj systemu DevOps, takiego jak GitHub Actions lub Azure DevOps. Aby uzyskać więcej informacji, zobacz Build and deploy to Azure Kubernetes Service (Kompilowanie i wdrażanie w usłudze Azure Kubernetes Service).
  • Aby prawidłowo przetestować aplikację przed udostępnieniem jej użytkownikom, użyj testów A/B i wdrożeń kanarowych w zarządzaniu cyklem życia aplikacji. Istnieje kilka technik, których można użyć do podzielenia ruchu między różne wersje tej samej usługi. Alternatywnie można użyć funkcji podziału ruchu udostępnianych przez implementację siatki usług. Aby uzyskać więcej informacji, zobacz Linkerd Traffic Split (Podział ruchu konsolidatora) i Istio Traffic Management (Zarządzanie ruchem istio).
  • Użyj usługi Azure Container Registry lub innego rejestru kontenerów (takiego jak Docker Hub), aby przechowywać prywatne obrazy platformy Docker wdrożone w klastrze. Usługa AKS może uwierzytelniać się w usłudze Azure Container Registry przy użyciu tożsamości firmy Microsoft Entra.
  • Przetestuj ruch przychodzący i wychodzący na obciążeniach w osobnym środowisku przedprodukcyjnym, które odzwierciedla topologię sieci i reguły zapory środowiska produkcyjnego. Strategia wdrażania etapowego pomoże wykryć wszelkie problemy z siecią lub zabezpieczeniami przed wydaniem nowej funkcji lub reguły sieciowej w środowisku produkcyjnym.

Monitorowanie

Usługa Azure Firewall jest w pełni zintegrowana z usługą Azure Monitor na potrzeby rejestrowania ruchu przychodzącego i wychodzącego przetwarzanego przez zaporę. Aby uzyskać więcej informacji, zobacz Filtrowanie oparte na analizie zagrożeń w usłudze Azure Firewall.

Poniższe zagadnienia dotyczące monitorowania nie są specyficzne dla wielodostępności w usłudze AKS, ale uważamy, że są to podstawowe wymagania dotyczące tego rozwiązania.

  • Użyj usługi Container Insights , aby monitorować stan kondycji klastra i obciążeń usługi AKS.
  • Skonfiguruj wszystkie usługi PaaS (takie jak Container Registry i Key Vault), aby zbierać dzienniki diagnostyczne i metryki.

Optymalizacja kosztów

Koszt wynikowej architektury zależy od następujących szczegółów konfiguracji:

  • Warstwy usług
  • Skalowalność (liczba wystąpień dynamicznie przydzielanych przez usługi do obsługi danego zapotrzebowania)
  • Skrypty automatyzacji
  • Poziom odzyskiwania po awarii

Po dokonaniu oceny tych szczegółów konfiguracji użyj kalkulatora cen platformy Azure, aby oszacować koszty. Aby uzyskać więcej opcji optymalizacji cen, zobacz zasady optymalizacji kosztów w witrynie Microsoft Azure Well-Architected Framework.

Wdrażanie tego scenariusza

Kod źródłowy tego scenariusza jest dostępny w usłudze GitHub. To rozwiązanie jest typu open source i dostarczane z licencją MIT.

Wymagania wstępne

W przypadku wdrożeń online potrzebne jest konto platformy Azure. Jeśli nie masz subskrypcji, przed rozpoczęciem utwórz bezpłatne konto platformy Azure. Przed wdrożeniem modułów Terraform przy użyciu usługi Azure DevOps należy spełnić te wymagania:

  • Zapisz plik stanu narzędzia Terraform na koncie usługi Azure Storage. Aby uzyskać więcej informacji na temat używania konta magazynu do przechowywania stanu zdalnego programu Terraform, blokowania stanu i szyfrowania magazynowanych, zobacz Przechowywanie stanu programu Terraform w usłudze Azure Storage.
  • Tworzenie projektu usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Tworzenie projektu w usłudze Azure DevOps.
  • Utwórz połączenie usługi Azure DevOps z subskrypcją platformy Azure. Podczas tworzenia połączenia z usługą można użyć uwierzytelniania jednostki usługi (SPA) lub tożsamości usługi zarządzanej platformy Azure. W obu przypadkach upewnij się, że jednostka usługi lub tożsamość zarządzana używana przez usługę Azure DevOps do łączenia się z subskrypcją platformy Azure ma przypisaną rolę właściciela w całej subskrypcji.

Wdrażanie na platformie Azure

  1. Podaj przydatne informacje o subskrypcji platformy Azure.

  2. Sklonuj repozytorium GitHub aplikacji Workbench:

    git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

  3. Postępuj zgodnie z instrukcjami podanymi w pliku README.md.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Zapoznaj się z zaleceniami i najlepszymi rozwiązaniami dotyczącymi usługi AKS w witrynie Microsoft Azure Well-Architected Framework:

Azure Firewall

Azure Kubernetes Service

Wskazówki dotyczące architektury

Architektury odwołań