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 polecenia helm, musi pochodzić z VPC klastra lub połączonej sieci. 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.

Jeśli wyłączono publiczny dostęp dla punktu końcowego serwera interfejsu API Kubernetes klastra, możesz uzyskać dostęp do punktu końcowego serwera interfejsu API Kubernetes w jeden z następujących sposobów:

• połączonej sieci: połącz sieć z siecią VPC przy użyciu bramy tranzytowej platformy AWS lub innych opcji łączności , a następnie użyj komputera w połączonej sieci. Należy się upewnić, że grupa zabezpieczeń płaszczyzny sterowania Amazon EKS zawiera reguły zezwalające na ruch przychodzący na porcie 443 z połączonej sieci.
• hosta bastionu usługi Amazon EC2: możesz uruchomić wystąpienie usługi Amazon EC2 w podsieci publicznej w VPC klastra, a następnie zalogować się za pośrednictwem protokołu SSH do tego wystąpienia, aby uruchomić kubectl polecenia. Aby uzyskać więcej informacji, zobacz Hosty bastionu systemu Linux na platformie AWS. Upewnij się, że grupa zabezpieczeń płaszczyzny sterowania Amazon EKS zawiera reguły zezwalające na ruch przychodzący na porcie 443 z hosta bastionu. Aby uzyskać więcej informacji, zobacz View Amazon EKS security group requirements for clusters. Podczas konfigurowania kubectl dla hosta bastionu należy użyć poświadczeń platformy AWS, które są już mapowane na konfigurację RBAC klastra, lub dodać podmiot zabezpieczeń IAM, że bastion będzie używany do konfiguracji RBAC przed usunięciem dostępu publicznego punktu końcowego. Aby uzyskać więcej informacji, zobacz Grant IAM users and roles access to Kubernetes APIs and Unauthorized or access denied (kubectl).
• środowiska IDE platformy AWS Cloud9: AWS Cloud9 to zintegrowane środowisko projektowe (IDE) oparte na chmurze, które umożliwia pisanie, uruchamianie i debugowanie kodu przy użyciu tylko przeglądarki. Środowisko IDE platformy AWS Cloud9 można utworzyć w ramach VPC klastra i użyć środowiska IDE do komunikowania się z klastrem. Aby uzyskać więcej informacji, zobacz Tworzenie środowiska w usłudze AWS Cloud9. Upewnij się, że grupa zabezpieczeń płaszczyzny sterowania Amazon EKS zawiera reguły zezwalające na ruch przychodzący na porcie 443 z grupy zabezpieczeń IDE. Aby uzyskać więcej informacji, zobacz View Amazon EKS security group requirements for clusters. Podczas konfigurowania kubectl dla środowiska IDE platformy AWS Cloud9 należy użyć poświadczeń platformy AWS, które zostały już zamapowane na konfigurację kontroli dostępu opartej na rolach klastra, lub dodać podmiot zabezpieczeń tożsamości używany przez środowisko IDE do konfiguracji kontroli dostępu opartej na rolach przed usunięciem dostępu publicznego punktu końcowego. Aby uzyskać więcej informacji, zobacz Grant IAM users and roles access to Kubernetes APIs and Unauthorized or access denied (kubectl).

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

prywatny klaster usługi AKS zapewnia, że ruch sieciowy między serwerem interfejsu API a węzłami agenta pozostaje w sieci wirtualnej. W prywatnym klastrze usługi AKS płaszczyzna sterowania lub serwer interfejsu API ma wewnętrzne adresy IP zdefiniowane w dokumencie RFC1918 — alokacja adresów dla prywatnego internetu. Korzystając z klastra prywatnego, można zapewnić, że ruch sieciowy między serwerem interfejsu API i pulami węzłów pozostaje tylko w sieci prywatnej.

W prywatnym klastrze usługi AKS 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 tego 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.

Podczas aprowizowania prywatnego klastra usługi AKS usługa AKS domyślnie tworzy prywatną nazwę FQDN z prywatną strefą DNS i dodatkową publiczną nazwą FQDN z odpowiednim rekordem A w publicznym systemie DNS platformy Azure. Węzły agenta nadal używają rekordu A w prywatnej strefie DNS, aby rozpoznać prywatny adres IP prywatnego punktu końcowego na potrzeby komunikacji z serwerem interfejsu API.

Na poniższym diagramie przedstawiono konfigurację prywatnego klastra usługi AKS.

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

W prywatnym klastrze usługi AKS punkt końcowy serwera interfejsu API nie ma publicznego adresu IP. Istnieje kilka opcji nawiązywania łączności sieciowej z klastrem prywatnym:

1. Utwórz maszynę wirtualną w tej samej sieci wirtualnej co klaster usługi AKS przy użyciu polecenia az vm create z flagą --vnet-name.
2. Użyj maszyny wirtualnej w oddzielnej sieci wirtualnej i skonfiguruj komunikacji równorzędnej sieci wirtualnych z siecią wirtualną klastra usługi AKS.
3. Skonfiguruj usługę Azure ExpressRoute lub sieci VPN w celu nawiązania połączenia z siecią wirtualną klastra.
4. Utwórz połączenie prywatnego punktu końcowego platformy Azure wewnątrz innej sieci wirtualnej.
5. Użyj wystąpienia usługi Cloud Shell wdrożonego w podsieci połączonej z serwerem interfejsu API dla klastra.

Za pomocą interfejsu wiersza polecenia platformy Azure możesz użyć polecenia az aks invoke, aby uzyskać dostęp do klastrów prywatnych bez konieczności konfigurowania sieci VPN lub usługi Express Route. To polecenie umożliwia zdalne wywoływanie poleceń, takich jak kubectl i helm, w klastrze prywatnym za pośrednictwem interfejsu API platformy Azure bez konieczności bezpośredniego łączenia się z klastrem. Aby użyć command invoke, musisz mieć niezbędne uprawnienia skonfigurowane dla akcji Microsoft.ContainerService/managedClusters/runcommand/action i Microsoft.ContainerService/managedclusters/commandResults/read.

W witrynie Azure Portal możesz użyć funkcji Run command do uruchamiania poleceń w klastrze prywatnym. Ta funkcja używa funkcji command invoke do wykonywania poleceń w klastrze. Zasobnik utworzony przez funkcję Run command udostępnia narzędzia kubectl i helm do zarządzania klastrem. Ponadto obsługuje powłokę Bash z narzędziami takimi jak jq, xargs, grepi awk.

Aby nawiązać połączenie z maszyną wirtualną zarządzania serwerem przesiadkowym, możesz użyć Azure Bastion w tej samej sieci wirtualnej lub równorzędnej sieci wirtualnej. 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.

Integracja z siecią wirtualną serwera API

Klaster usługi Azure Kubernetes Service (AKS) skonfigurowany przy użyciu integracji sieci wirtualnej serwera interfejsu API projektuje punkt końcowy serwera interfejsu API bezpośrednio do delegowanej podsieci w sieci wirtualnej, w której wdrożono usługę AKS. Integracja z siecią wirtualną serwera API umożliwia komunikację sieciową między serwerem interfejsu API a węzłami klastra bez konieczności łączenia prywatnego lub tunelu. Serwer interfejsu API jest dostępny za wewnętrznym adresem VIP modułu równoważenia obciążenia w delegowanej podsieci, z której węzły są skonfigurowane do użycia. Korzystając z integracji z siecią wirtualną usługi API Server, można zapewnić, że ruch sieciowy między serwerem interfejsu API i pulami węzłów pozostaje tylko w sieci prywatnej.

Płaszczyzna sterowania lub serwer interfejsu API znajduje się w subskrypcji platformy Azure zarządzanej przez usługę AKS. Klaster lub pula węzłów znajduje się w subskrypcji platformy Azure. Serwer i maszyny wirtualne tworzące węzły klastra mogą komunikować się ze sobą za pośrednictwem adresów IP serwera interfejsu API i adresów IP zasobników, które są przewidywane w delegowanej podsieci.

Integracja z siecią wirtualną serwera API jest obsługiwana w przypadku klastrów publicznych lub prywatnych. Dostęp publiczny można dodać lub usunąć po aprowizacji klastra. W przeciwieństwie do klastrów zintegrowanych z siecią wirtualną węzły agenta zawsze komunikują się bezpośrednio z prywatnym adresem IP wewnętrznego modułu równoważenia obciążenia (ILB) serwera interfejsu API bez używania systemu DNS. Cały węzeł do ruchu serwera interfejsu API jest przechowywany w sieci prywatnej i nie jest wymagany tunel do połączenia serwera interfejsu API z węzłem. Klienci poza klastrem, którzy muszą komunikować się z serwerem interfejsu API, mogą to zrobić normalnie, jeśli jest włączony dostęp do sieci publicznej. Jeśli dostęp do sieci publicznej jest wyłączony, należy postępować zgodnie z tą samą metodologią konfiguracji prywatnej DNS co standardowe klastry prywatne . Aby uzyskać więcej informacji, zobacz Create an Azure Kubernetes Service cluster with API Server VNet Integration(Tworzenie klastra usługi Azure Kubernetes Service za pomocą integracji z siecią wirtualną serwera interfejsu API).

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

Podczas rozważania łączności z usługą AKS należy pamiętać o kilku ważnych kwestiach. Oto kilka kluczowych kwestii, o których należy pamiętać:

• Klaster prywatny usługi AKS oferuje zwiększone zabezpieczenia i izolację w porównaniu z autoryzowanymi adresami IP. Nie można jednak przekonwertować istniejącego publicznego klastra usługi AKS na klaster prywatny. Zamiast tego autoryzowane adresy IP można włączyć dla dowolnego istniejącego klastra usługi AKS.
• Autoryzowanych zakresów adresów IP nie można zastosować do prywatnego punktu końcowego serwera interfejsu API. Mają zastosowanie tylko do publicznego serwera interfejsu API.
• Klastry prywatne nie obsługują agentów hostowanych w usłudze Azure DevOps. Zaleca się zamiast tego używanie własnych agentów.
• Aby usługa Azure Container Registry działała z prywatnym klastrem usługi AKS, należy skonfigurować łącze prywatne dla rejestru kontenerów w sieci wirtualnej klastra. Alternatywnie komunikację równorzędną można ustanowić 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 prywatny punkt końcowy w podsieci klienta klastra prywatnego zostanie usunięty lub zmodyfikowany, 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 architekt rozwiązań w chmurze

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