Zabezpieczanie dostępu sieciowego do platformy Kubernetes

W tym artykule porównaliśmy tryby sieciowe dla usług Azure Kubernetes Service (AKS) i Amazon Elastic Kubernetes Service (Amazon EKS). W tym artykule opisano sposób poprawiania zabezpieczeń połączeń z zarządzanym serwerem interfejsu API klastra usługi AKS oraz różnymi opcjami ograniczania dostępu do sieci publicznej.

Tryby sieciowe Amazon EKS

Za pomocą usługi Amazon Virtual Private Cloud (Amazon VPC) można uruchamiać zasoby usług Amazon Web Services (AWS) w sieci wirtualnej składającej się z podsieci publicznych i prywatnych lub zakresów adresów IP w VPC. Podsieć publiczna hostuje zasoby, które muszą być połączone z Internetem, a podsieć prywatna hostuje zasoby, które nie są połączone z publicznym Internetem. Usługa Amazon EKS może aprowizować grupy węzłów zarządzanych zarówno w podsieciach publicznych, jak i prywatnych.

Kontrola dostępu do punktu końcowego umożliwia skonfigurowanie, czy punkt końcowy serwera interfejsu API jest osiągalny z publicznego Internetu, czy za pośrednictwem programu VPC. Eks zapewnia kilka sposobów kontrolowania dostępu do punktu końcowego klastra. Domyślny publiczny punkt końcowy, prywatny punkt końcowy lub oba punkty końcowe można włączyć jednocześnie. Po włączeniu publicznego punktu końcowego można dodać ograniczenia routingu międzydomenowego (CIDR, Classless Inter-Domain Routing), aby ograniczyć adresy IP klienta, które mogą łączyć się z publicznym punktem końcowym.

Sposób nawiązywania połączenia węzłów Usługi Amazon EKS z zarządzaną płaszczyzną sterowania platformy Kubernetes zależy od tego, które ustawienie punktu końcowego jest skonfigurowane dla klastra. Ustawienia punktu końcowego można zmienić w dowolnym momencie za pomocą konsoli Usługi Amazon EKS lub interfejsu API. Aby uzyskać więcej informacji, zobacz Kontrola dostępu do punktu końcowego klastra Amazon EKS.

Tylko publiczny punkt końcowy

Uwidacznianie płaszczyzny sterowania za pośrednictwem publicznego punktu końcowego jest trybem domyślnym dla nowych klastrów Amazon EKS. Gdy jest włączony tylko publiczny punkt końcowy klastra, interfejs API Kubernetes żądań, które pochodzą z sieci VPC firmy Amazon, takich jak węzeł roboczy do sterowania komunikacją płaszczyzny, pozostaw sieć VPC, ale nie opuszczaj sieci firmy Amazon. Aby węzły łączyły się z płaszczyzną sterowania, muszą używać publicznego adresu IP i trasy do bramy internetowej lub trasy do bramy translatora adresów sieciowych (NAT), w której mogą używać publicznego adresu IP bramy translatora adresów sieciowych.

Publiczne i prywatne punkty końcowe

Po włączeniu publicznych i prywatnych punktów końcowych żądania interfejsu API Kubernetes z poziomu VPC komunikują się z płaszczyzną sterowania za pośrednictwem zarządzanych przez usługę Amazon EKS elastycznych interfejsów sieciowych (ENI) w programie VPC. Serwer interfejsu API klastra jest dostępny z Internetu.

Tylko prywatny punkt końcowy

Po włączeniu tylko prywatnego punktu końcowego cały ruch do serwera interfejsu API klastra, taki jak kubectl lub helm polecenia, musi pochodzić z sieci VPC lub połączonej sieci klastra. Publiczny dostęp do serwera interfejsu API z Internetu jest wyłączony. Ten tryb dostępu można zaimplementować przy użyciu wirtualnej sieci prywatnej platformy AWS (AWS VPN) lub usługi AWS DirectConnect z siecią VPC. Aby ograniczyć dostęp do punktu końcowego bez sieci VPN platformy AWS lub directConnect, możesz dodać ograniczenia CIDR do publicznego punktu końcowego, aby ograniczyć połączenia bez konfigurowania większej liczby sieci.

Aby uzyskać więcej informacji na temat opcji łączności, zobacz Uzyskiwanie dostępu do serwera interfejsu API Tylko prywatny.

Dostęp sieciowy usługi AKS do serwera interfejsu API

Istnieją dwie opcje zabezpieczania dostępu sieciowego do interfejsu API Kubernetes w usłudze AKS, prywatnego klastra usługi AKS lub autoryzowanych zakresów adresów IP.

Prywatny klaster usługi AKS

Klaster prywatny usługi AKS zapewnia, że ruch sieciowy między serwerem interfejsu API a pulami węzłów pozostaje w sieci wirtualnej. W prywatnym klastrze usługi AKS płaszczyzna sterowania lub serwer interfejsu API ma wewnętrzny adres IP dostępny tylko za pośrednictwem prywatnego punktu końcowego platformy Azure znajdującego się w tej samej sieci wirtualnej. Każda maszyna wirtualna w tej samej sieci wirtualnej może prywatnie komunikować się z płaszczyzną sterowania za pośrednictwem prywatnego punktu końcowego. Płaszczyzna sterowania lub serwer interfejsu API jest hostowany w subskrypcji zarządzanej przez platformę Azure, a klaster AKS i jego pule węzłów znajdują się w subskrypcji klienta.

Na poniższym diagramie przedstawiono konfigurację klastra prywatnego.

Pobierz plik programu Visio z tą architekturą.

Aby aprowizować prywatny klaster usługi AKS, dostawca zasobów usługi AKS tworzy prywatną w pełni kwalifikowaną nazwę domeny (FQDN) dla grupy zasobów węzła w prywatnej strefie DNS. Opcjonalnie usługa AKS może również utworzyć publiczną nazwę FQDN z odpowiednim rekordem adresu (A) w publicznej strefie DNS platformy Azure. Węzły agenta używają rekordu A w prywatnej strefie DNS, aby rozpoznać prywatny adres IP punktu końcowego na potrzeby komunikacji z serwerem interfejsu API.

Dostawca zasobów usługi AKS może utworzyć prywatną strefę DNS w grupie zasobów węzła lub utworzyć prywatną strefę DNS i przekazać jej identyfikator zasobu do systemu aprowizacji. Klaster prywatny można utworzyć podczas korzystania z programu Terraform z platformą Azure, aplikacją Bicep, szablonami usługi ARM, interfejsem wiersza polecenia platformy Azure, modułem Azure PowerShell lub interfejsem API REST platformy Azure w celu utworzenia klastra.

Publiczną nazwę FQDN serwera interfejsu API można włączyć podczas aprowizacji lub za pomocą polecenia az aks update z parametrem --enable-public-fqdn w istniejących klastrach. Jeśli włączysz publiczną nazwę FQDN, każda maszyna wirtualna, która uzyskuje dostęp do serwera, na przykład własnego agenta usługi Azure DevOps lub własnego modułu uruchamiającego akcje GitHub Actions, musi znajdować się w tej samej sieci wirtualnej, która hostuje klaster lub w sieci połączonej za pośrednictwem komunikacji równorzędnej sieci wirtualnej lub sieci VPN typu lokacja-lokacja.

W przypadku prywatnego klastra usługi AKS należy wyłączyć publiczną nazwę FQDN serwera interfejsu API. Aby komunikować się z prywatną płaszczyzną sterowania, maszyna wirtualna musi znajdować się w tej samej sieci wirtualnej lub w równorzędnej sieci wirtualnej z połączeniem sieci wirtualnej z prywatną strefą DNS. Rekord A w prywatnej strefie DNS rozpoznaje nazwę FQDN serwera interfejsu API na prywatny adres IP punktu końcowego, który komunikuje się z bazową płaszczyzną sterowania. Aby uzyskać więcej informacji, zobacz Tworzenie prywatnego klastra usługi Azure Kubernetes Service.

Opcje wdrażania klastra prywatnego

Dostawca zasobów usługi AKS uwidacznia następujące parametry w celu dostosowania wdrożenia prywatnego klastra usługi AKS:

• authorizedIpRanges (ciąg) określa dozwolone zakresy adresów IP w formacie CIDR.
• disableRunCommand (Wartość logiczna) określa, czy wyłączyć run polecenie dla klastra.
• enablePrivateCluster (Wartość logiczna) określa, czy klaster ma zostać utworzony jako prywatny.
• enablePrivateClusterPublicFQDN (Wartość logiczna) określa, czy utworzyć inną publiczną nazwę FQDN dla klastra prywatnego.
• privateDnsZone (ciąg) określa prywatną strefę DNS w grupie zasobów węzła. Jeśli nie określisz wartości, dostawca zasobów utworzy strefę. Możesz określić następujące wartości:
  • System jest wartością domyślną.
  • None domyślnie używa publicznego systemu DNS, więc usługa AKS nie tworzy prywatnej strefy DNS.
  • <Your own private DNS zone resource ID> używa prywatnej strefy DNS utworzonej w formacie privatelink.<region>.azmk8s.io lub <subzone>.privatelink.<region>.azmk8s.io.

W poniższej tabeli przedstawiono opcje konfiguracji DNS dotyczące wdrażania prywatnego klastra usługi AKS:

Łączność i zarządzanie klastrem prywatnym

Istnieje kilka opcji nawiązywania łączności sieciowej z klastrem prywatnym.

• Utwórz maszyny wirtualne w tej samej sieci wirtualnej co klaster usługi AKS.

• Użyj maszyn wirtualnych w oddzielnej sieci wirtualnej i skonfiguruj komunikację równorzędną sieci wirtualnych z siecią wirtualną klastra usługi AKS.

• Użyj połączenia usługi Azure ExpressRoute lub sieci VPN.

• Użyj polecenia interfejsu wiersza polecenia platformy Azure az aks command invoke , aby uruchomić kubectl polecenia i helm w klastrze prywatnym bez bezpośredniego nawiązywania połączenia z klastrem.

• Użyj połączenia prywatnego punktu końcowego platformy Azure.

Można zarządzać prywatnym klastrem usługi AKS przy użyciu narzędzia wiersza polecenia kubectl z maszyny wirtualnej zarządzania w tej samej sieci wirtualnej lub równorzędnej sieci wirtualnej.

Usługi Azure Bastion można używać w tej samej sieci wirtualnej lub równorzędnej sieci wirtualnej, aby nawiązać połączenie z maszyną wirtualną zarządzania serwerem przesiadkowym. Azure Bastion to w pełni zarządzana platforma jako usługa (PaaS), która umożliwia łączenie się z maszyną wirtualną przy użyciu przeglądarki i witryny Azure Portal. Usługa Azure Bastion zapewnia bezpieczną i bezproblemową łączność z maszyną wirtualną protokołu Remote Desktop Protocol (RDP) lub Secure Shell (SSH) za pośrednictwem protokołu Transport Layer Security (TLS) bezpośrednio z witryny Azure Portal. Gdy maszyny wirtualne łączą się za pośrednictwem usługi Azure Bastion, nie potrzebują publicznego adresu IP, agenta ani specjalnego oprogramowania klienckiego.

Możesz również użyć polecenia az aks invoke do uruchomienia kubectl lub helm poleceń w prywatnym klastrze usługi AKS bez konieczności nawiązywania połączenia z maszyną wirtualną przesiadkową.

Autoryzowane zakresy adresów IP

Drugą opcją poprawy zabezpieczeń klastra i zminimalizowania ataków na serwer interfejsu API jest użycie autoryzowanych zakresów adresów IP. Autoryzowane adresy IP ograniczają dostęp do płaszczyzny sterowania publicznego klastra usługi AKS do znanej listy adresów IP i ciDR. W przypadku korzystania z tej opcji serwer interfejsu API jest nadal uwidoczniony publicznie, ale dostęp jest ograniczony. Aby uzyskać więcej informacji, zobacz Bezpieczny dostęp do serwera interfejsu API przy użyciu autoryzowanych zakresów adresów IP w usłudze Azure Kubernetes Service (AKS).

Następujące az aks update polecenie interfejsu wiersza polecenia platformy Azure autoryzuje zakresy adresów IP:

 az aks update \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --api-server-authorized-ip-ranges  73.140.245.0/24

Zagadnienia dotyczące łączności z usługą AKS

• Klaster prywatny usługi AKS zapewnia wyższe zabezpieczenia i izolację niż autoryzowane adresy IP. Nie można jednak przekonwertować istniejącego publicznego klastra usługi AKS na klaster prywatny. Możesz włączyć autoryzowane adresy IP dla dowolnego istniejącego klastra usługi AKS.

• Nie można zastosować autoryzowanych zakresów adresów IP do prywatnego punktu końcowego serwera interfejsu API. Autoryzowane adresy IP dotyczą tylko publicznego serwera interfejsu API.

• Klastry prywatne nie obsługują agentów hostowanych w usłudze Azure DevOps. Rozważ użycie własnych agentów.

• Aby umożliwić usłudze Azure Container Registry pracę z prywatnym klastrem usługi AKS, skonfiguruj łącze prywatne dla rejestru kontenerów w sieci wirtualnej klastra. Możesz też skonfigurować komunikację równorzędną między siecią wirtualną usługi Container Registry i siecią wirtualną klastra prywatnego.

• Ograniczenia usługi Azure Private Link dotyczą klastrów prywatnych.

• Jeśli usuniesz lub zmodyfikujesz prywatny punkt końcowy w podsieci klienta klastra prywatnego, klaster przestanie działać.

Współautorzy

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

Autorzy zabezpieczeń:

• Paolo Salvatori | Główny inżynier usługi
• Martin Gjoszewski | Starszy inżynier ds. usług
• Laura Nicolas | Starszy inżynier oprogramowania

Inni współautorzy:

• Chad Kittel | Główny inżynier oprogramowania
• Cena Ed | Starszy menedżer programu zawartości
• Theano Petersen | Składnik zapisywania technicznego

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

Następne kroki

• Usługa AKS dla specjalistów amazon EKS
• Zarządzanie tożsamościami i dostępem na platformie Kubernetes
• Monitorowanie i rejestrowanie na platformie Kubernetes
• Opcje magazynu dla klastra Kubernetes
• Zarządzanie kosztami dla platformy Kubernetes
• Zarządzanie węzłami i pulami węzłów kubernetes
• Nadzór nad klastrem

Powiązane zasoby

Poniższe odwołania zawierają linki do dokumentacji i przykładów automatyzacji w celu wdrożenia klastrów usługi AKS przy użyciu zabezpieczonego interfejsu API:

• Tworzenie prywatnego klastra usługi AKS z publiczną strefą DNS
• Tworzenie prywatnego klastra usługi Azure Kubernetes Service przy użyciu narzędzia Terraform i usługi Azure DevOps
• Tworzenie publicznego lub prywatnego klastra usługi Azure Kubernetes Service za pomocą usługi Azure NAT Gateway i bramy aplikacja systemu Azure
• Używanie prywatnych punktów końcowych z prywatnym klastrem usługi AKS
• Wprowadzenie do usługi Azure Private Link
• Wprowadzenie do zabezpieczania infrastruktury sieciowej przy użyciu zabezpieczeń sieci platformy Azure