Sicherer Netzwerkzugriff auf Kubernetes

In diesem Artikel werden Netzwerkmodi für Azure Kubernetes Service (AKS) und Amazon Elastic Kubernetes Service (Amazon EKS) verglichen. Im Artikel wird beschrieben, wie Sie die Verbindungssicherheit mit dem verwalteten API-Server eines AKS-Clusters verbessern können, sowie die verschiedenen Optionen zum Einschränken des öffentlichen Netzwerkzugriffs.

Amazon EKS-Netzwerkmodi

Mit Amazon Virtual Private Cloud (Amazon VPC) können Sie Amazon Web Services (AWS)-Ressourcen in einem virtuellen Netzwerk starten, das aus öffentlichen und privaten Subnetzen oder Bereichen von IP-Adressen in der VPC besteht. Ein öffentliches Subnetz hostet Ressourcen, die mit dem Internet verbunden sein müssen, und ein privates Subnetz hostet Ressourcen, die nicht mit dem öffentlichen Internet verbunden sind. Amazon EKS kann verwaltete Knotengruppen sowohl in öffentlichen als auch in privaten Subnetzen bereitstellen.

Mit der Zugriffssteuerung für Endpunkte können Sie konfigurieren, ob der API-Serverendpunkt über das öffentliche Internet oder über die VPC erreichbar ist. EKS bietet verschiedene Möglichkeiten zum Steuern des Zugriffs auf den Clusterendpunkt. Sie können den öffentlichen Standardendpunkt, einen privaten Endpunkt oder beide Endpunkte gleichzeitig aktivieren. Wenn Sie den öffentlichen Endpunkt aktivieren, können Sie CIDR-Einschränkungen (Classless Inter-Domain Routing, klassenloses domänenübergreifendes Routing) hinzufügen, um die Client-IP-Adressen einzuschränken, die eine Verbindung mit dem öffentlichen Endpunkt herstellen können.

Wie Amazon EKS-Knoten eine Verbindung mit der verwalteten Kubernetes-Steuerungsebene herstellen, wird davon bestimmt, welche Endpunkteinstellung für den Cluster konfiguriert ist. Sie können die Endpunkteinstellungen jederzeit über die Amazon EKS-Konsole oder die API ändern. Weitere Informationen finden Sie unter Zugriffssteuerung für Amazon EKS-Clusterendpunkte.

Nur öffentlicher Endpunkt

Das Verfügbarmachen der Steuerungsebene über einen öffentlichen Endpunkt ist der Standardmodus für neue Amazon EKS-Cluster. Wenn nur der öffentliche Endpunkt für den Cluster aktiviert ist, verlassen Kubernetes-API-Anforderungen, die aus der Amazon VPC stammen, z. B. Kommunikation von Workerknoten mit der Steuerungsebene, die VPC, verlassen aber nicht das Netzwerk von Amazon. Damit Knoten eine Verbindung mit der Steuerungsebene herstellen können, müssen sie eine öffentliche IP-Adresse und eine Route zu einem Internetgateway verwenden oder eine Route zu einem NAT-Gateway (Netzwerkadressenübersetzung), in dem sie die öffentliche IP-Adresse des NAT-Gateways verwenden können.

Öffentliche und private Endpunkte

Wenn sowohl die öffentlichen als auch die privaten Endpunkte aktiviert sind, kommunizieren Kubernetes-API-Anforderungen aus der VPC an die Steuerungsebene über die von Amazon EKS verwalteten elastischen Netzwerkschnittstellen (Elastic Network Interfaces, ENIs) in der VPC. Der Cluster-API-Server ist über das Internet zugänglich.

Nur privater Endpunkt

Wenn nur der private Endpunkt aktiviert ist, muss der gesamte Datenverkehr an den Cluster-API-Server, z. B. kubectl oder helm Befehle, innerhalb des CLUSTERS oder eines verbundenen Netzwerksstammen. Der öffentliche Zugriff auf den API-Server aus dem Internet ist deaktiviert. Sie können diesen Zugriffsmodus implementieren, indem Sie AWS Virtual Private Network (AWS VPN) oder AWS DirectConnect mit der VPC verwenden. Um den Zugriff auf den Endpunkt ohne AWS VPN oder DirectConnect einzuschränken, können Sie dem öffentlichen Endpunkt CIDR-Einschränkungen hinzufügen, um Verbindungen zu beschränken, ohne weitere Netztechnologien einrichten zu müssen.

Wenn Sie den öffentlichen Zugriff für den Kubernetes-API-Serverendpunkt Ihres Clusters deaktiviert haben, können Sie auf eine der folgenden Arten auf den Kubernetes-API-Serverendpunkt zugreifen:

• Verbundenes Netzwerk: Verbinden Sie Ihr Netzwerk mit einem AWS-Transitgateway oder anderen Konnektivitätsoptionen und verwenden Sie dann einen Computer im verbundenen Netzwerk. Sie müssen sicherstellen, dass Ihre Sicherheitsgruppe der Amazon EKS-Kontrollebene Regeln enthält, um den Datenverkehr an Port 443 aus Ihrem verbundenen Netzwerk zuzulassen.
• Amazon EC2 Bastion Host: Sie können eine Amazon EC2-Instanz in ein öffentliches Subnetz im RAHMEN Ihres Clusters starten und sich dann über SSH bei dieser Instanz anmelden, um kubectl Befehle auszuführen. Weitere Informationen finden Sie unter Linux Bastion Hosts auf AWS. Sie müssen sicherstellen, dass Ihre Amazon EKS-Kontrollebenen-Sicherheitsgruppe Regeln enthält, um den Datenverkehr an Port 443 von Ihrem Bastionhost aus zuzulassen. Weitere Informationen finden Sie unter Anzeigen der Sicherheitsgruppenanforderungen von Amazon EKS für Cluster. Wenn Sie kubectl für Ihren Bastionhost konfigurieren, verwenden Sie unbedingt AWS-Anmeldeinformationen, die bereits der RBAC-Konfiguration Ihres Clusters zugeordnet sind, oder fügen Sie den IAM-Prinzipal hinzu, den Ihre Bastion für die RBAC-Konfiguration verwendet, bevor Sie den öffentlichen Zugriff auf Endpunkte entfernen. Weitere Informationen finden Sie unter Gewähren des Zugriffs von IAM-Benutzern und -Rollen auf Kubernetes-APIs und "Nicht autorisiert" oder "Zugriff verweigert" (kubectl).
• AWS Cloud9 IDE: AWS Cloud9 ist eine cloudbasierte integrierte Entwicklungsumgebung (IDE), mit der Sie Ihren Code mit nur einem Browser schreiben, ausführen und debuggen können. Sie können eine AWS Cloud9-IDE im RAHMEN Ihres Clusters erstellen und die IDE verwenden, um mit Ihrem Cluster zu kommunizieren. Weitere Informationen finden Sie unter Erstellen einer Umgebung in AWS Cloud9. Sie müssen sicherstellen, dass Ihre Sicherheitsgruppe der Amazon EKS-Kontrollebene Regeln enthält, um den Datenverkehr an Port 443 aus Ihrer IDE-Sicherheitsgruppe zuzulassen. Weitere Informationen finden Sie unter Anzeigen der Sicherheitsgruppenanforderungen von Amazon EKS für Cluster. Wenn Sie kubectl für Ihre AWS Cloud9 IDE konfigurieren, achten Sie darauf, AWS-Anmeldeinformationen zu verwenden, die bereits der RBAC-Konfiguration Ihres Clusters zugeordnet sind, oder fügen Sie den IAM-Prinzipal hinzu, den Ihre IDE zur RBAC-Konfiguration verwendet, bevor Sie den öffentlichen Zugriff des Endpunkts entfernen. Weitere Informationen finden Sie unter Gewähren des Zugriffs von IAM-Benutzern und -Rollen auf Kubernetes-APIs und "Nicht autorisiert" oder "Zugriff verweigert" (kubectl).

Weitere Informationen zu Konnektivitätsoptionen finden Sie unter Zugreifen auf einen rein privaten API-Server.

AKS-Netzwerkzugriff auf den API-Server

Es gibt zwei Optionen zum Sichern des Netzwerkzugriffs auf die Kubernetes-API in AKS, einen privaten AKS-Cluster oder autorisierte IP-Adressbereiche.

Privater AKS-Cluster

Ein privaten AKS-Cluster stellt sicher, dass der Netzwerkverkehr zwischen dem API-Server und den Agentknoten innerhalb des virtuellen Netzwerks verbleibt. In einem privaten AKS-Cluster verfügt die Steuerungsebene oder der API-Server über interne IP-Adressen, die im RFC1918 - Adresszuweisung für privates Internet Dokument definiert sind. Mithilfe eines privaten Clusters können Sie sicherstellen, dass der Netzwerkdatenverkehr zwischen Ihrem API-Server und Ihren Knotenpools nur im privaten Netzwerk verbleibt.

In einem privaten AKS-Cluster verfügt der API-Server über eine interne IP-Adresse, auf die nur über einen privaten Azure -Endpunkt zugegriffen werden kann, sich im selben virtuellen Netzwerk befindet. Jeder virtuelle Computer (VM) im selben virtuellen Netzwerk kann über diesen privaten Endpunkt privat mit der Steuerebene kommunizieren. Der Steuerungsebenen- oder API-Server wird in dem von Azure verwalteten Abonnement gehostet, während sich der AKS-Cluster mit seinen Knotenpools im Abonnement des Kunden befindet.

Wenn Sie einen privaten AKS-Cluster bereitstellen, erstellt AKS standardmäßig einen privaten FQDN mit einer privaten DNS-Zone und einem zusätzlichen öffentlichen FQDN mit einem entsprechenden A Eintrag in Azure public DNS. Die Agentknoten verwenden weiterhin den A Eintrag in der privaten DNS-Zone, um die private IP-Adresse des privaten Endpunkts für die Kommunikation mit dem API-Server aufzulösen.

Das folgende Diagramm veranschaulicht eine private AKS-Clusterkonfiguration.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Um einen privaten AKS-Cluster bereitzustellen, erstellt der AKS-Ressourcenanbieter einen privaten vollqualifizierten Domänennamen (FQDN) für die Knotenressourcengruppe in einer privaten DNS-Zone. Optional kann AKS auch einen öffentlichen FQDN mit einem entsprechenden Adresseneintrag (A) in der öffentlichen Azure-DNS-Zone erstellen. Die Agent-Knoten verwenden den A-Eintrag in der privaten DNS-Zone, um die IP-Adresse des privaten Endpunkts für die Kommunikation mit dem API-Server aufzulösen.

Der AKS-Ressourcenanbieter kann die private DNS-Zone in der Knotenressourcengruppe erstellen, oder Sie können die private DNS-Zone erstellen und deren Ressourcen-ID an das Bereitstellungssystem übergeben. Sie können einen privaten Cluster erstellen, wenn Sie Terraform mit Azure, Bicep, ARM-Vorlagen, Azure CLI, ein Azure PowerShell-Modul oder die Azure-REST-API verwenden, um den Cluster zu erstellen.

Sie können während der Bereitstellung einen öffentlichen FQDN für den API-Server aktivieren oder indem Sie den Befehl az aks update mit dem Parameter --enable-public-fqdn auf vorhandenen Clustern verwenden. Wenn Sie den öffentlichen FQDN aktivieren, muss sich jede VM, die auf den Server zugreift, z. B. ein selbstgehosteter Azure DevOps-Agent oder ein selbstgehosteter GitHub Actions-Runner, im selben virtuellen Netzwerk befinden, in dem der Cluster gehostet wird, oder in einem Netzwerk, das über Peering virtueller Netzwerke oder ein Site-to-Site-VPN verbunden ist.

Für einen privaten AKS-Cluster deaktivieren Sie den öffentlichen FQDN des API-Servers. Um mit der privaten Steuerungsebene zu kommunizieren, muss sich eine VM im selben virtuellen Netzwerk befinden oder in einem gepeerten virtuellen Netzwerk mit einer virtuellen Netzwerkverbindung mit der privaten DNS-Zone. Der A-Eintrag in der privaten DNS-Zone löst den FQDN des API-Servers zur IP-Adresse des privaten Endpunkts auf, die mit der zugrunde liegenden Steuerungsebene kommuniziert. Weitere Informationen finden Sie unter Erstellen eines privaten Azure Kubernetes Service-Clusters.

Optionen für die Bereitstellung privater Cluster

Der AKS-Ressourcenanbieter macht die folgenden Parameter zur Anpassung der Bereitstellung privater AKS-Cluster verfügbar:

• authorizedIpRanges (string; Zeichenfolge) gibt zulässige IP-Adressbereiche im CIDR-Format an.
• disableRunCommand (Boolesch) gibt an, ob der Befehl run für den Cluster deaktiviert werden soll oder nicht.
• enablePrivateCluster (Boolesch) gibt an, ob der Cluster als „privat“ erstellt werden soll oder nicht.
• enablePrivateClusterPublicFQDN (Boolesch) gibt an, ob ein anderer, öffentlicher FQDN für den privaten Cluster erstellt werden soll oder nicht.
• privateDnsZone (string; Zeichenfolge) gibt eine private DNS-Zone in der Knotenressourcengruppe an. Wenn Sie keinen Wert angeben, erstellt der Ressourcenanbieter die Zone. Sie können folgende Werte angeben:
  • Der Standardwert lautet System.
  • Die Standardeinstellung von None ist „öffentliches DNS“, sodass AKS keine private DNS-Zone erstellt.
  • <Your own private DNS zone resource ID> verwendet eine private DNS-Zone, die Sie im Format privatelink.<region>.azmk8s.io oder <subzone>.privatelink.<region>.azmk8s.io. erstellen.

Die folgende Tabelle zeigt die DNS-Konfigurationsoptionen für die Bereitstellung eines privaten AKS-Clusters:

Konnektivität und Verwaltung privater Cluster

In einem privaten AKS-Cluster verfügt der API-Serverendpunkt über keine öffentliche IP-Adresse. Es gibt mehrere Optionen zum Einrichten der Netzwerkkonnektivität mit dem privaten Cluster:

1. Erstellen Sie einen virtuellen Computer im selben virtuellen Netzwerk wie der AKS-Cluster mithilfe des Befehls az vm create mit dem --vnet-name-Flag.
2. Verwenden Sie einen virtuellen Computer in einem separaten virtuellen Netzwerk, und richten Sie virtuellen Netzwerk-Peering mit dem virtuellen AKS-Clusternetzwerk ein.
3. Konfigurieren Sie eine Azure ExpressRoute- oder VPN-, um eine Verbindung mit dem virtuellen Clusternetzwerk herzustellen.
4. Erstellen Sie eine Azure Private Endpoint Verbindung innerhalb eines anderen virtuellen Netzwerks.
5. Verwenden Sie eine Cloud Shell Instanz, die in einem Subnetz bereitgestellt wird, das mit dem API-Server für den Cluster verbunden ist.

Mithilfe der Azure CLI können Sie den Befehl "azks" verwenden, um auf private Cluster zuzugreifen, ohne dass eine VPN- oder Expressroute konfiguriert werden muss. Mit diesem Befehl können Sie Befehle wie kubectl und helmremote auf Ihrem privaten Cluster über die Azure-API aufrufen, ohne eine direkte Verbindung mit dem Cluster herstellen zu müssen. Um command invokezu verwenden, müssen Sie über die erforderlichen Berechtigungen für die Microsoft.ContainerService/managedClusters/runcommand/action und Microsoft.ContainerService/managedclusters/commandResults/read Aktionen verfügen.

Im Azure-Portal können Sie das feature Run command verwenden, um Befehle auf Ihrem privaten Cluster auszuführen. Dieses Feature verwendet tatsächlich die command invoke Funktionalität zum Ausführen von Befehlen auf Ihrem Cluster. Der vom feature Run command erstellte Pod stellt kubectl und helm Tools zum Verwalten Ihres Clusters bereit. Darüber hinaus unterstützt es Bash mit Tools wie jq, xargs, grepund awk verfügbar.

Sie können Azure Bastion- im selben virtuellen Netzwerk oder einem peered virtual network verwenden, um eine Verbindung mit einem virtuellen Jump Box-Verwaltungscomputer herzustellen. Azure Bastion ist eine vollständig verwaltete Platform-as-a-Service (PaaS), mit der Sie eine Verbindung mit einer VM herstellen können, indem Sie Ihren Browser und das Azure-Portal verwenden. Azure Bastion bietet über das Remotedesktopprotokoll (RDP) oder die Secure Shell (SSH) sichere und nahtlose VM-Konnektivität mittels Transport Layer Security (TLS) direkt über das Azure-Portal. Beim Herstellen einer Verbindung über Azure Bastion benötigen VMs keine öffentliche IP-Adresse, keinen Agent und keine spezielle Clientsoftware.

API-Server-VNet-Integration

Ein Azure Kubernetes Service (AKS)-Cluster, der mit API Server VNet Integration konfiguriert ist, den API-Serverendpunkt direkt in ein delegiertes Subnetz im VNet projiziert, in dem AKS bereitgestellt wird. Die API-Server-VNet-Integration ermöglicht die Netzwerkkommunikation zwischen dem API-Server und den Clusterknoten, ohne dass eine private Verbindung oder ein Tunnel erforderlich ist. Der API-Server steht hinter einer internen LASTENausgleichs-VIP im delegierten Subnetz zur Verfügung, die für die Verwendung der Knoten konfiguriert sind. Mithilfe der API-Server-VNet-Integration können Sie sicherstellen, dass der Netzwerkdatenverkehr zwischen Ihrem API-Server und Ihren Knotenpools nur im privaten Netzwerk verbleibt.

Die Steuerebene oder der API-Server befindet sich in einem AKS-verwalteten Azure-Abonnement. Ihr Cluster- oder Knotenpool befindet sich in Ihrem Azure-Abonnement. Der Server und die virtuellen Computer, aus denen die Clusterknoten bestehen, können über die VIP- und Pod-IPs des API-Servers miteinander kommunizieren, die in das delegierte Subnetz projiziert werden.

Die VNet-Integration des API-Servers wird für öffentliche oder private Cluster unterstützt. Sie können nach der Clusterbereitstellung den öffentlichen Zugriff hinzufügen oder entfernen. Im Gegensatz zu nicht-VNet integrierten Clustern kommunizieren die Agentknoten immer direkt mit der privaten IP-Adresse des internen LASTENausgleichs -IP (ILB) des API-Servers, ohne DNS zu verwenden. Der gesamte Knoten zum API-Serverdatenverkehr wird in privaten Netzwerken beibehalten, und es ist kein Tunnel erforderlich, damit der API-Server die Knotenkonnektivität herstellen kann. Out-of-Cluster-Clients, die mit dem API-Server kommunizieren müssen, können dies normalerweise tun, wenn der Zugriff auf öffentliche Netzwerke aktiviert ist. Wenn der Zugriff auf öffentliche Netzwerke deaktiviert ist, sollten Sie die gleiche private DNS-Einrichtungsmethode wie standard privaten Clusterbefolgen. Weitere Informationen finden Sie unter Erstellen eines Azure Kubernetes-Dienstclusters mit API Server VNet Integration.

Autorisierte IP-Adressbereiche

Die zweite Option, um die Clustersicherheit zu verbessern und Angriffe auf den API-Server zu minimieren, besteht darin, autorisierte IP-Adressbereiche zu verwenden. Autorisierte IPs schränken den Zugriff auf die Steuerungsebene eines öffentlichen AKS-Clusters auf eine bekannte Liste von IP-Adressen und CIDRs ein. Wenn Sie diese Option verwenden, ist der API-Server weiterhin öffentlich verfügbar, doch der Zugriff ist eingeschränkt. Weitere Informationen finden Sie unter Sicherer Zugriff auf den API-Server mit autorisierten IP-Adressbereichen in Azure Kubernetes Service (AKS).

Der folgende Azure CLI-Befehl az aks update autorisiert IP-Bereiche:

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

Überlegungen zur AKS-Konnektivität

Wenn Sie die AKS-Konnektivität in Betracht ziehen, müssen Sie einige wichtige Überlegungen berücksichtigen. Hier sind einige wichtige Punkte zu beachten:

• Ein privater AKS-Cluster bietet eine verbesserte Sicherheit und Isolation im Vergleich zu autorisierten IPs. Es ist jedoch nicht möglich, einen vorhandenen öffentlichen AKS-Cluster in einen privaten Cluster zu konvertieren. Stattdessen können autorisierte IPs für jeden vorhandenen AKS-Cluster aktiviert werden.
• Autorisierte IP-Bereiche können nicht auf einen privaten API-Serverendpunkt angewendet werden. Sie gelten nur für den öffentlichen API-Server.
• Private Cluster unterstützen keine von Azure DevOps gehosteten Agents. Es wird empfohlen, stattdessen selbst gehostete Agents zu verwenden.
• Damit azure Container Registry mit einem privaten AKS-Cluster funktioniert, muss ein privater Link für die Containerregistrierung im virtuellen Clusternetzwerk eingerichtet werden. Alternativ kann Peering zwischen dem virtuellen Containerregistrierungsnetzwerk und dem virtuellen Netzwerk des privaten Clusters hergestellt werden.
• Die Einschränkungen des Azure Private Link-Diensts gelten für private Cluster.
• Wenn der private Endpunkt im Kundensubnetz eines privaten Clusters gelöscht oder geändert wird, funktioniert der Cluster nicht mehr.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Paolo Salvatori | Principal Service Engineer
• Martin Gjoshevski | Senior Service Engineer
• Laura Nicolas | Senior Cloud Solution Architect

Andere Mitwirkende:

• Chad Kittel | Principal Software Engineer
• Ed Price | Senior Content Program Manager
• Theano Petersen | Technical Writer

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• AKS für Amazon EKS-Experten
• Kubernetes-Identitäts- und Zugriffsverwaltung
• Kubernetes-Überwachung und -Protokollierung
• Speicheroptionen für einen Kubernetes-Cluster
• Kostenmanagement für Kubernetes
• Kubernetes-Knoten- und -Knotenpoolverwaltung
• Clustergovernance

Zugehörige Ressourcen

Die folgenden Referenzen bieten Links zu Dokumentationen und Automatisierungsbeispielen zum Bereitstellen von AKS-Clustern mit einer gesicherten API:

• Erstellen eines privaten AKS-Clusters mit einer öffentlichen DNS-Zone
• Erstellen eines privaten Azure Kubernetes Service-Clusters mithilfe von Terraform und Azure DevOps
• Erstellen eines öffentlichen oder privaten Azure Kubernetes Service-Clusters mit Azure NAT Gateway und Azure Application Gateway
• Verwenden privater Endpunkte mit einem privaten AKS-Cluster
• Einführung in Azure Private Link
• Einführung in die sicheres Netzwerkinfrastruktur mit der Azure-Netzwerksicherheit